We just upgraded to MySQL 4.0.20 (binary), and we use replication to a
slave running the same. We're having some difficulty deleting the relay
log files the slave creates. I'm fairly confused, as the manual clearly
says we shouldn't be having this problem:
According to the MySQL manual:
"""
Relay logs have the same format as binary logs, so you can use
mysqlbinlog to read them. A relay log is automatically deleted by the
SQL thread as soon as it has executed all its events and no longer needs
it). There is no explicit mechanism for deleting relay logs, because the
SQL thread takes care of doing so. However, from MySQL 4.0.14, FLUSH
LOGS rotates relay logs, which will influence when the SQL thread
deletes them.
"""
So, I've run Flush Logs on the slave, and it's created the next log file
in the sequence. But the old ones still stay around indefinitely. Even
after issuing stop slave/start slave. I cannot find a command similar
to PURGE MASTER LOGS for the slave to purge logs on the slave. Show
slave status shows the slave "Relay_log_space" increasing steadily even
after rotation. The "Exec_master_log_pos" is in sync with the master,
meaning the old relay files are nolonger needed.
There is a feature in 4.1.1:
--relay-log-purge={0|1}
Disables or enables automatic purging of relay logs as soon as they are
not needed any more. The default value is 1 (enabled). This is a global
variable that can be changed dynamically with SET GLOBAL
relay_log_purge. This option is available as of MySQL 4.1.1.
Does that mean that log purging doesn't exist until 4.1.1, or that the
'option to turn it off' isn't available until 4.1.1? If log purging
isn't available until the next major mysql release, how can I delete
these log files now? Even if I delete them off disk, they are still
referenced in the 'relay-bin.index' file. Presumably I'm not allowed to
update that file on a live slave...
Ideas?
-Joe
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
