virtually-synchronous replication

[Yos Taj]

How is Galera Cluster different from MariaDB/MySQL's semi-synchronous replication?

Galera Cluster brings virtually synchronous replication to MariaDB/MySQL.
That is, write-sets are once queued to other nodes synchronously,
but they are applied to database files asynchronously.

In other words, it's eventually consistent. I'm afraid we cannot say
'No slave lag', though you say so at http://galeracluster.com/products/.

Then I think they are same as for data consistency between nodes.
But Galera Cluster is much superior with these features like:
- bi-directional replication. We can write to any nodes.
- automatic synch by SST/IST. We can add nodes to cluster easily.

Is my understanding right?

Regards.

[Philip Stoev]

> Galera Cluster brings virtually synchronous replication to MariaDB/MySQL.
> That is, write-sets are once queued to other nodes synchronously,
> but they are applied to database files asynchronously.

> In other words, it's eventually consistent. I'm afraid we cannot say
> 'No slave lag', though you say so at http://galeracluster.com/products/.

Galera has various protections against slave lag:
* In general the slaves are allowed to lag behind the master as a
performance optimization, but only by a small, bounded and configurable
amount of transactions.
* Any sessions, queries or transactions that are sensitive to slave lag can
be configured independently so that they never see slave lag

With MySQL semi-synchronous replication, the slave can lag arbitrarily
behind the master.

Also, with semi-sync replication, the transaction is reported committed as
soon as one slave acknowledges that it has received it. With Galera, all
nodes must acknowledge, and therefore a failure that affects multiple
servers can be handled properly.

> But Galera Cluster is much superior with these features like:
> - bi-directional replication. We can write to any nodes.
> - automatic synch by SST/IST. We can add nodes to cluster easily.

Yes, that is correct.

[Yos Tj]

Hi Philip,

 > * In general the slaves are allowed to lag behind the master as a
 >  performance optimization, but only by a small, bounded and configurable
 >  amount of transactions.

You mean we can control the lag?

 > * Any sessions, queries or transactions that are sensitive to slave lag can
 >   be configured independently so that they never see slave lag

By setting wsrep_sync_wait session variable, right?

Regards.

[Philip Stoev]

> > * In general the slaves are allowed to lag behind the master as a
> > performance optimization, but only by a small, bounded and configurable
> > amount of transactions.

> You mean we can control the lag?

Please check out the gcs.fc_limit provider option:

http://galeracluster.com/documentation-webpages/galeraparameters.html#gcs-fc-limit
http://galeracluster.com/documentation-webpages/galeraparameters.html#gcs-fc-factor

If a slave is more than gcs.fc_limit replication events behind, it will
issue a flow-control message so that the master blocks until the slave has
been able to catch up.

> > * Any sessions, queries or transactions that are sensitive to slave lag
> > can
> > be configured independently so that they never see slave lag

> By setting wsrep_sync_wait session variable, right?

Yes, that is correct.