Hi! The spec looks good! One thing I might add on there is support for multi-master subscription for a single server, rather than only being able to pull replication queries from just one server. This is probably not useful for a general case, but I can think of a few applications where this could be useful (especially in cloud environments). Any type of data that is either deterministic regardless of ordering or where data does not always need to be consistent (statistical applications or eventual consistency schemas).
I'm guessing this isn't something that would happen for the first basic implementation, but it might be good to keep in mind during the queue and connection manager reworking (I_S tables for connected slaves and masters possibly). -Eric On Wed, Aug 20, 2008 at 05:51:43PM +0200, Mats Kindahl wrote: > Hi all! > > I have added a stub for a specification of a very simple statement-based > replication implementation on the Drizzle wiki under > > http://drizzle.wikia.com/wiki/Simple_Replication > > In there, we have a sample specification of the binary log messages that > are needed to support the implementation. The intention is to have > something small and simple up and running in a relatively short time. To > do this, we are specifying the message format in Protobuf, but to handle > the message transport, a separate module will be used to handle > "framing" of the messages for transport to the slave. > > The goals are: > > * Simple replication implementation > * Separate module > * Supporting slave fail-over to other master (something that MySQL > Replication does not support well currently) > * Moderate message integrity checking using simple CRC-32 checksum > (mainly aimed to ensure that the correct size of messages are read). > * Support for adding digest/hash for more extensive integrity checks > > Some open issues are: > * Timestamps are currently down to nanosecond precision, but I question > if this is needed. It requires 8 bytes, which is almost half of the > header, so if we can reduce this for the common scenarios and maybe > have a timestamp where it is necessary, I think that would be a good > thing. > * Do we need to support encryption/compression of the individual events? > * There is no support for LOAD DATA INFILE yet. We could use a similar > technique as is used in MySQL Replication, but there might be > alternatives. > > Other ideas are welcome! > > Just my few cents, > Mats Kindahl > -- > 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 _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
