help understanding galera consistency (certification-based replication)

Question

Galera uses a certification-based replication to achieve strong consistency.

While doing a transaction after doing a COMMIT the other nodes will certify it and if is ok it will be successfully committed.

But what happens in the case of losing a node that certified the commit but still fetching the data, for example when writing a big blob?

From my understanding the certification process is synchronous but the data transfer is asynchronous, meaning that the client/user may think his data is stored on all the nodes after running successfully a COMMIT but while in reality is happening in the backend is that data may be still synchronizing among the nodes and in case of a network outage and depending on the type of transaction the node could be in a conflict, correct?

If this is the case, how could the cluster be configured to self-heal from possible conflicts or wondering if there is a way to achieve strong consistency even if it would impact the return time for every COMMIT since it should only be successful after the data been full transmitted on all nodes.

Answer 1

But what happens in the case of losing a node that certified the commit but still fetching the data, for example when writing a big blob?

This is no different to losing any other node. If the node crashes, it will try to re-join the cluster next time it comes up. A donor node will be found, and preferably IST (incremental state transfer) or alternatively SST (state snapshot transfer) will bring the node to the right state.

From my understanding the certification process is synchronous but the data transfer is asynchronous, meaning that the client/user may think his data is stored on all the nodes after running successfully a COMMIT but while in reality is happening in the backend is that data may be still synchronizing among the nodes and in case of a network outage and depending on the type of transaction the node could be in a conflict, correct?

You are right that the data transfer is asynchronous and there is a short time while the node state is not identical. This isn't exactly a conflict, just that the other nodes are behind. They will catch up soon enough.

If this is the case, how could the cluster be configured to self-heal from possible conflicts or wondering if there is a way to achieve strong consistency even if it would impact the return time for every COMMIT since it should only be successful after the data been full transmitted on all nodes.

Yes, it does self-heal through ISTs and SSTs.

There are two ways to be sure that you're reading the most up-to-date version of the data: If you always write to only one node (e.g. because of using a DB proxy with a read-write splitter), then you can make sure to also read from that same node. The other option is to set the session variable wsrep_sync_wait=1 - see Achieving Read-After-Write Semantics With Galera.