Le 19 mars 2012 à 06:53, David Shrewsbury a écrit : > On Mar 18, 2012, at 11:43 AM, Daniel Nichter wrote: > >> Let me add re: #2 (and #3): it seems we have two evils to choose from. The >> first, the old docs, is having two systems of replication: streams and >> slave. It would be nice if we had only streams and everything was pure and >> simple, but slave wasn't built that way. That's a problem because slave is, >> I highly suspect, the very first thing people will turn to. It is, after >> all, Drizzle's "native" system of replication, yet it's also not. > > Why is it not "native"?
It's not native because the original docs lead one to believe that replicator-applier is the native system, yet slave doesn't use this purely. Related to your next point... >> The second is having one system of replication with a fudged, oddball >> premier member: slave. A very astute reader of the docs will immediately >> notice (before Details) that slave doesn't truly fit the paradigm, but I >> hope my literary prowess was clever enough to keep the user dreaming of >> their super awesome slave-based Drizzle replication system before they >> realized the truth or read Details. >> >> I favor the second evil because I think, going forward, maybe/hopefully >> someday Drizzle will have a native replication system that's pure >> replication stream. If yes, then we won't have to disrupt the established >> paradigm. If no, then the true nature of the slave plugin will remain a >> hacker's delight and maybe a Drizzle DBA certification question: "Explain >> why the slave plugin is not a true TransactionApplier." > > The whole Replicator/Applier was around before we had a reliable > transaction log, which we now have in the InnoDB replication log. > Personally, I'd like to kill off the Replicator/Applier pattern since it > does not have the guarantee that events received have been safely > committed on the master (long discussion on that is beyond the > scope of this email). Also, I find it slightly awkward, though I do > understand the concept behind it. > > If it were up to me, I'd promote that future plugins follow the style > of the slave plugin and read from the InnoDB replication log which > DOES have this guarantee. > > Having the two paradigms, though flexible, is confusing, I think. > But again, that's beyond the scope of this discussion. I hadn't though of this: the (un)reliability of slave if it were a real replicator-applier plugin. Since slave is the (more/most) reliable solution, then I agree with you: we should make it _the_ paradigm and (like my alternative #3 in a previous email) re-purpose the replicator-applier paradigm. I think the replicator-applier system is useful to users as an easy way to access committed transactions, so it should be kept, but if it's not the future of true/real/pure Drizzle-to-Drizzle replication going forward, then we shouldn't promote it as such. It would be relatively easy in the docs to make this split: say "slave is _the_ native system of replication (because it's reliable etc. etc.)" but also, "Drizzle also has a system called replicator-applier which allows plugins to access the same committed transactions and do whatever they want with them". That's probably what the original docs wanted but failed to communicate. Does that ^ sound better? What do other developers think? Brian? Monty? Mark? Stewart? Henrik? Olaf? Vijay? Jay? etc. -Daniel _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : drizzle-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
