I got an alert that one of the drives was filling up (3% free). So I
figured out that a large chunk was from /var/log/mysql
r...@pse10:~# find / -type d -print0 | xargs -0 -n1 du -sk | sort -rn |
head -n20 ~/dir-sizes.txt
r...@pse10:~# cat ~/dir-sizes.txt
159121012 /
70442396 /var
70127764
That was a wrong operation to do.
Anyway, issue a show master status, and set the replucation again on the
slave with the new values. Next time look for 'purge binary logs'!
Ciao
Claudio
On 23 dec 2009 21:21, Daevid Vincent dae...@daevid.com wrote:
I got an alert that one of the drives was
The issue is that replication relies on this logs !!!, so when you
deleted them .
Generally speaking you have to:
stop the slave
sync the master with the slave (there are several ways to do this and
depending how busy is your master)
grab the master status (position)
change the slave
In this case it should not be needed to sync the slave,
Resetting the master basically broke the 'pipe' but events are still on the
new binary logs, it might have lost some event in some unfortunate case, but
anyway it is probably for now to put slave back on track, check and
eventually resync.
*Next time look for 'purge binary logs'!*
Purge may also cause problem , before doing purge make sure slave is in sync
with master or at least cross check slave currently which bin file getting
sync.
On Thu, Dec 24, 2009 at 2:05 AM, Carlos Proal carlos.pr...@gmail.comwrote:
The issue is that
: mysql@lists.mysql.com
Subject: Re: HELP! RESET MASTER hosed replication
*Next time look for 'purge binary logs'!*
Purge may also cause problem , before doing purge make sure
slave is in sync
with master or at least cross check slave currently which bin
file getting
sync.
On Thu, Dec
Yep, It might not be needed to sync, but its better to double check ;).
Carlos
On 12/23/2009 2:44 PM, Claudio Nanni wrote:
In this case it should not be needed to sync the slave,
Resetting the master basically broke the 'pipe' but events are still
on the new binary logs, it might have lost
