![](https://secure.gravatar.com/avatar/e116f298afc14b2ee30632c823110d84.jpg?s=120&d=mm&r=g)
On Tue, 23 Mar 2010 13:03:34 +0200, Henrik Ingo
On Tue, Mar 23, 2010 at 10:40 AM,
wrote: 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
High-priority here means that this transaction can abort any other that stands in its way. Actually this is a requirement only to have Galera working in multi-master mode. And it does not look like an engine requirement, rather a lock manager feature (rather useful though - on slave it guarantees that transactions received from master will never deadlock with local transactions). So I think the server may or may not provide such a feature, it should not really affect the redundancy API. I'd say that it belongs to the integration layer. Alex