I recently found that there's now a lot more information on-line about the Emic Application Cluster from Emic Networks. Specifically, they have several PDFs available (overview, architecture, etc) on their Products page.
So I've begun reading them.
It's interesting to see how their technology works and how they position it against other options. In their Overview White Paper, for example, I found this line about MySQL's native replication:
MySQL's native replication approach manages only one copy of the database.
Now I know a fair amount about MySQL's native replication, and I can't figure out what that is supposed to mean--even without taking it out of context. Don't get me wrong. They do a good job of summarizing the other, less vague, downfalls of MySQL's native replication system. I'm just puzzled by what that's supposed to mean. The are numerous ways I can think to interpret it, but they're all pretty misleading.
Anyway, I'll probably write more about Emic, NDB, and Native replication later.
Posted by jzawodn at February 17, 2004 02:20 PM
It's why manuals and courses are no subtitute for practical experience depantsing boys sort of way. I mean all the attempts by one person to get an idea across to another person isn't nearly as good as getting into it and figuring the damned thing out yourself.
Have you started playing with NDB yet? Some of the limitations are a little disappointing... 2GB per node? I hope that gets fixed.
Jeremy,
Why not just wait until MySQL releases there version? I know they bought out some company that does MySQL clustering.
But I haven't heard anything else, except they bought they out...
I looked at the EMIC stuff, but some of the things they say make me wonder how well it works for more complex applications... either their description of how the system works is poor, or it is mainly targeted towards applications that do few writes, but for some reason can't just use mysql replication and have read-only slaves for read queries.
And their silly PDFs are setup to not allow you to cut and paste from them... guess that is what xpdf is for.
The below comments are based on their whitepaper at http://www.emicnetworks.com/download/pdf/eac_mysql_architecture.pdf in addition to some of the other documentation.
- for innodb, "read queries can be executed while the same table is locked by another write query". This seems to imply that one table can only have one write query going on at once, which is a big deal. It may actually mean only one node can be doing write queries at once, but it isn't clear the system has the smarts to distribute writes for that table to one node instead of blocking... some other stuff hints at the fact that maybe it does, but it isn't clear. They say "caveat: replication uses only table level lock algorithm even for innodb tabel type. This approach is quite appropriate when most of the queries are non-consistent read".
- follow on from the previous point; how much of innodb's row level locking do you end up loosing? Can you still have multiple transactions concurrently updating non-overlapping rows in a table? Does any of this interfere with the multiversioning support?
- it does updates by sticking a proxy in the middle that has a SQL parser that figures out what statements modify data, and does its magic stuff with those appropriately. Such things have been somewhat fragile in my experience, and are at a much higher level than I'd like.
- their documentation on how a new node is brought up to speed when it joins (or rejoins) the cluster is a bit... fuzzy. The manual has details that I would have to study more, but it looks like you need 1 node to continue processing queries, 1 node that is joining (eg. a node that was taken down and then brought back up), then 1 node that freezes its state temporarily and gets the joiner up to speed, then they are both brought up to the current time. It isn't clear how long updates are frozen for while this is happening.
- they talk about how what they does is better than a 2 phase commit, but... it isn't clear to me how they actually do that, or if what they are doing is even actually synchronous, or just something that, in the absence of failure, is guaranteed to always succeed without race conditions. The difference is if you are assured a consistent state between databases if the whole cluster goes down in the middle of something.
- they don't yet support "transaction groups" (which look just like transactions to me... "scheduled for next major release") or "kill" (umh... hmm, maybe you can still kill readonly queries by connecting to the mysql instance directly) and "timestamp" in read operations only (does that include time functions like now(), or just the timestamp column type?)
Heh, I remember attending the first part of the Emic session at last year's user conference but I wound up walking out after ten minutes because they spoke like they write. It was just too hard to glean real information from their presentation.
That being said I am also interested in seeing what the Alzato acquisition produces.
