Ian P. Christian wrote:
Ofer Inbar wrote:
Assuming your slave is not usable by client programs now anyway and
you don't mind it being unusable for a while longer, you can restart
the slaving from scratch:
This is exactly what I'm trying to avoid doing, it means 2 days downtime
whilst the data
On Tue, 12 Jun 2007, Ian P. Christian wrote:
> Ian P. Christian wrote:
> > I upgraded my slave server a few weeks ago, and the slave failed, with
> > an error similar to the one shown below.
>
>
> I have figured out what happened here now - and I'm part of the way
> though fixing it.
>
> It
Ofer Inbar wrote:
> Assuming your slave is not usable by client programs now anyway and
> you don't mind it being unusable for a while longer, you can restart
> the slaving from scratch:
This is exactly what I'm trying to avoid doing, it means 2 days downtime
whilst the data is re-inserted.
I hav
"Ian P. Christian" <[EMAIL PROTECTED]> wrote:
> In theory, I should be able to find out where the slave was up to in the
> old logs, extract them manually and replay them on the slave, and then
> reset the slave to use the new logs - however i'm not sure how reliable
> that's going to be - or even
Just to clarify - are you asking for suggestions regarding avoiding
re-seeding the slave or regarding what is likely to have gone wrong?
Generally, a newer slave can cope with an older master, but not the other
way around. If you updated the master while slave was out of date, you may
be out of
Ian P. Christian wrote:
> I upgraded my slave server a few weeks ago, and the slave failed, with
> an error similar to the one shown below.
I have figured out what happened here now - and I'm part of the way
though fixing it.
It turned out the defaults had changed somewhere, and rather then
