I'm trying to move my binary log files onto a different drive than our main data drive
to get a little performance boost.
the drives are set up like so:
drive 1 (sda):
swap
/boot
/usr
drive 2 (sdb):
/
mysql is installed in /usr/local/mysql and its data directory is /usr/local/mysql/var
I
I found the solution to my own problem...
the log-bin option is a specific filename. so when you set:
log-bin=/logging
mysql must have ownership of the / folder, as it is trying to create /logging.001 and
/logging.index
easily fixed by adding the file-name to the path...
Use PURGE {MASTER|BINARY} LOGS TO 'log_name' instead of RESET
MASTER.
From the manual:
Deletes all the binary logs listed in the log index that are strictly
prior to the specified log or date. The logs also are removed from this
list recorded in the log index file, so that the given log now
Diana Soares wrote:
Use PURGE {MASTER|BINARY} LOGS TO 'log_name' instead of RESET
MASTER.
From the manual:
Deletes all the binary logs listed in the log index that are strictly
prior to the specified log or date. The logs also are removed from this
list recorded in the log index file, so that
On Tue, 9 Dec 2003, Mayuran Yogarajah wrote:
Diana Soares wrote:
Use PURGE {MASTER|BINARY} LOGS TO 'log_name' instead of RESET
MASTER.
From the manual:
Deletes all the binary logs listed in the log index that are strictly
prior to the specified log or date. The logs also are removed
We are running MySQL 3.23 in production, and have replication
setup in the following manner: There are two machines (m1 and m2).
Replication is setup in a circular way. Both machines are master and
slave, more specifically, m1 is master to m2 and m2 is master to m1.
I checked today and saw that
In 3.23.x versions of MySQL the actual binary log file sizes stayed
fairly consistent. An 'empty' log file for instance on 3.23.53a is 73
bytes. I have a situation where I'm doing a roll-your-own replication
from many sites to one central server where the remote sites are on
everything from dialup
