maria-developers team mailing list archive

[Alex Yurchenko <alexey.yurchenko@xxxxxxxxxxxxx>]

On Tue, 23 Mar 2010 13:03:34 +0200, Henrik Ingo
<henrik.ingo@xxxxxxxxxxxxx>
wrote:
> On Tue, Mar 23, 2010 at 10:40 AM,  <seppo.jaakola@xxxxxxxxxxxxx> 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