IIt is great to use Master/Slave replication for failover. However, it is just one particular approach to scaleout rarely used outside of MySQL universe.
Consider a general case. Imagine a pool of 100,000 servers instances with Drizzle in a cloud. Some server instances are Windows, some - Linux, and some are Solaris. 10,000 of these servers are provisioned for a user, multiple masters and multiple slaves. There are several distributed databases, replication for failover only, several levels of map-reduce blended with SQL query processing, etc. What is wrong with having a pool of 10,000 Drizzle servers all capable of SQL processing in read-write mode? The database itself can also be distributed on a similar scale. Many of us worked on MPP databases and massively parallel distributed query processing. It is sometimes challenging, requires solving a number of problems, but still very realistic. There is a lot of excellent database research on the subject. Incidentally, at her VoiceCon keynote address on March 31, 2009, Padmasree Warrior, CTO of Cisco Systems, predicted that - COLLABORATION NETWORKS will be to enterprises what social networks are to consumers. - Information Technology will evolve into “INFORMATION FABRIC” Thanks. Regards, Alex Esterkin On Fri, May 1, 2009 at 11:26 AM, MARK CALLAGHAN <[email protected]> wrote: > On Fri, May 1, 2009 at 7:19 AM, Alex Esterkin <[email protected]> wrote: > > I have several architectural comments. > > > > Use GUIDs > > > > Session ID collisions may cause all sorts of problems. Perhaps, it makes > > sense to use globally unique identifiers? GUIDs are 16 bytes long. > > > > Global TransactionId (either global scope or transaction domain scope) > > > > Global transaction id implies that there is a global transaction manager > > somewhere capable of committing or aborting distributed global > > transactions. Thus, global transaction IDs have to be generated by such > > global transaction manager or registered with it and have a meaning only > in > > the context of such global transaction manager. As transactions can be > > nested, it may make sense to consider nesting global transaction > managers. > > What may be transaction manager discovery mechanism and how do you encode > > all this information in global transaction IDs? > > In the context of MySQL replication this has nothing to do with > distributed transactions. It (global transaction ID) means there is a > monotonically increasing counter maintained by the master, included in > binlog events and preserved across master failover. > See http://code.google.com/p/google-mysql-tools/wiki/GlobalTransactionIds > > This gets more complicated with multi-master replication and if you > try to replicate multiple masters into one slave. > > > -- > Mark Callaghan > [email protected] >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
