----- Original Message ----- > From: "Brent Clark" <brentgclarkl...@gmail.com> > > '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 > exercised. > 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 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
