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 s
> To: Carlos Proal
> Cc: 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
*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 wrote:
>
> The issue is that replication relies on
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.
Cia
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 sla
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" wrote:
I got an alert that one of the drives was filling up (3% free).