Eric Day wrote: > 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 agree with you and I have designed the mechanisms for keeping track of the position with this in mind. I have added a section for items that need to be clarified so that it is clear what form of extensions we are planning for in the future. > 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). Yes, we need those features as well. Best wishes, Mats Kindahl > > -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 > -- 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
