Koa McCullough wrote: > Mats, > > Thanks for the clarification. A few additional thoughts below: > > On Mon, 2008-08-04 at 22:37 +0200, Mats Kindahl wrote: > > >> AFAICT, all of the "editing" cases I can envision can be solved by a >> proper API to the replication log (but if you have some cases, real or >> imaginary, that you think can pose a problem I would be happy to hear >> them). > > The one place where it is useful being able to see the statements is > when we get a call from a customer saying that we deleted customer id > 11236. We can just grep through the log for that id to find the > transaction id it is associated with then skip it. Usually we don't > know the trans_id. Do you have plans to address a case like this?
Well... the plans are to build a good foundation for building tools on top of, like binlog grep utilities, and other tools. >> The format I am considering is basically a combined redo-undo log. This >> would mean that it would be possible to run the log both backwards and >> forwards, so the situation you describe could easily be solved by >> running the log backwards and then start replication from a different >> position, effectively skipping a set of events. > > This sounds like a really cool idea. Will a user be able to play > binlogs to a different database? Basically, yes. > Our standard procedure here is to leave > the site on-line while the restore is going on to different db. Then > get the binlog that happened while the restore was going on and play > them back. This process is repeated a couple of times so the database > we are restoring to is usually only a few seconds behind production. > The site is then off-lined and the DBs are swapped. Will this kind of > thing be possible? Of course. These kinds of scenarios is exactly what I'm aiming at providing support for. The basis is that the topology (how replication is connected) is dynamic and in constant flux. If that is assumed, one have to build the system to handle the situation. >> As tools support, I am considering libraries to allow "playing" >> replication logs in a controlled manner using scripts, with scripting >> language either being Lua or Perl (or maybe both, it depends on where I >> put the scripting support). > > This is a great idea. Can you keep me updated on this API so I port it > to python? Sure, but it will be some time before that... I have a day-job at MySQL, you know, and vacation is up next week. :) Best wishes, Mats Kindahl > > --Koa > > -- Mats Kindahl Lead Software Developer Replication Team MySQL AB, www.mysql.com
begin:vcard fn:Mats Kindahl n:Kindahl;Mats org:Sun Microsystems adr;quoted-printable:;;Tegv=C3=A4gen 3;Storvreta;SE;74334;Sweden email;internet:[EMAIL PROTECTED] title:Lead Replication Software Developer x-mozilla-html:FALSE version:2.1 end:vcard
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
