----- Original Message -----
> From: "Brent Clark" <brentgclarklist@stripped>
> 'Statement may not be safe to log'
Heh. Some of those statements weren't particularly safe in previous versions, either, but
they didn't whine :-p
Roughly, what it comes down to is that statements that contain things that may be
different on master and slave at the respective time of execution might replicate
differently. For some things (like date() calls) this is solved by replacing them with a
constant before they get logged (now() is replaced with the actual timestamp, for
example), while for other things (unORDERed selects) it may not be a simple.
Row logging is another take on it: instead of logging the statement, it logs the actual
changes, thereby neatly sidestepping the problem. This brings other issues, though.
> The question I would like to ask is. Is it safe to just change the binlog format? Or
> is a preprocedure that needs to first be
> And then lastly, if the change is made, and something goes wrong. Is there a role
> back procedure, or can I just change the binlog
> format back to STATEMENT.
AFAIK, the log format is automatically detected by the slave, so there should be no
problem in switching between the two (well, three) forms. The very existence of Mixed
format logging is actually proof of that, in a sense :-)
If "something goes wrong", however, it's a reasonable assumption that your replication got
messed up, so it's highly recommended to reinitialize the slave at that point, as wel as
changing back to statement-based logs.
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel