Hi all, I agree with other posters who suggest concentrating on data changes only to start with. The most important use cases for replication are HA and performance scaling. In both cases you want to be able to apply database changes quickly and accurately to slaves. It follows that it is critical to develop a very clean serialization model right from the start.
There are still a lot of choices about what to do beyond just copying rows. Here are three things that seem pretty important. 1.) DDL. It's very difficult to use replicators that don't automatically copy schema schema changes--try using SLONY if you need proof. Drizzle must replicate any statement required to ensure data changes work and to create a logically identical schema, including statements like CREATE INDEX, CREATE FUNCTION, and the rest. 2.) Supplemental logging data necessary to recreate changes fully. This includes keys and good schema map events. The Table map event in MySQL 5.1 is kind of broken because it gives column numbers but not names. It makes event application simpler, faster, and more flexible if everything you need to construct SQL fully is already in the log in serial order. Also there are heterogeneous replication problems where not having the column names is very problematic. 3.) Suppressing replication at the session level (e.g., SET SQL_LOG_BIN=0 or moral equivalents). This was mentioned in other posts. It makes implementing 3rd party replication much easier in a number of cases such as handling circular updates. There are many other use cases beyond this. There's nothing wrong with replicating other commands for practical reasons but given the focus on simplicity espoused by Brian and others it seems to me that the basic data replication with clean serialization should come first. Cheers, Robert On 3/31/09 8:47 PM PDT, "Jay Pipes" <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > All, > > As I was hacking on the new replication code today, I noticed that > Drizzle (and MySQL 6) is passing through REPAIR, OPTIMIZE, and ANALYZE > TABLE statements as-is into the binlog and the replication stream. > > Oddly, CHECK TABLE is not replicated. ?. > > Question: Should any of these statements be replicated or sent to a > binary log? > > I'm currently more concerned with the replication, but the binlog will > be getting re-built based on the replicator so it's relevant. > > As some of you may know, Drizzle only does row-based replication. > > But...what if there are no rows to replicate? :) > > DDL statements such as CREATE TABLE or DROP TABLE and administrative > statements such as OPTIMIZE TABLE don't actually affect *rows*. The way > that MySQL handles this is to simply replicate the SQL statement using > statement-based replication when it sees these statements (with certain > exceptions around temporary tables). > > Should Drizzle replicate any administrative commands at all? > Personally, I don't see the value in replicating them or storing them in > a recovery log either...but...input is always welcome! > > Thanks in advance, > > - -jay > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAknS47gACgkQ2upbWsB4UtHiZwCfbBTYVfDWaT/haWG/m2/X/oaN > R4sAnijKO1c3jYaC0yFrdvDVibI01/P6 > =2PTW > -----END PGP SIGNATURE----- > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > -- Robert Hodges, CTO, Continuent, Inc. Email: [email protected] Mobile: +1-510-501-3728 Skype: hodgesrm _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
