![](https://secure.gravatar.com/avatar/769f0fd707751e8755eb9b5dd837ab63.jpg?s=120&d=mm&r=g)
On Tue, Mar 23, 2010 at 10:40 AM,
At least the application of replicated transactions certainly should not be part of each storage engine. From the engine point of view, applying a set of replicated transactions should be "just another transaction". For the engine it should not matter if a transaction comes from the application, mysqldump, or a redundancy service. (There may be small details: when the application does a transaction, we need a new global txn id, but when applying a replicated transaction, the id is already there.)
yes, but no. .e.g. Galera replication has this strange need to use prioritized transactions for applying. DBMS should have the responsibility to provide high priority sessions for replication appliers.
So Galera only works with the engines you have hacked to support it? (Which I fear is InnoDB only?) Like I said, we can still list a set of details the engine needs to support, but in general of course we should be able to replicate from any table/engine into any table/engine without having "replication support" in each engine separately. But on the face of it, your requirement does make sense for synchronous replication. (And for the traditional asynchronous replication, users generally want the lag to be a small as possible too.) henrik -- email: henrik.ingo@avoinelama.fi tel: +358-40-5697354 www: www.avoinelama.fi/~hingo book: www.openlife.cc