On the results from the replication poll

Written by Written by knielsen Leave a comment on On the results from the replication poll

Here are the results of a recent poll on LinkedIn and mariadb.org about the popularity of a few of the major replication features (I aggregated the results from the two sites):

What is your favorite MariaDB replication feature?
  • 36% Parallel replication
  • 27% Multi-source replication
  • 23% Global transaction ID (GTID)
  • 14% Semi-synchronous replication

I want to share some reasons why the poll results match my own thoughts on the relative importance of these features:

1. Parallel replication

Parallel replication brings a much needed performance boost to replication. This is not only useful for the big sites where slaves would otherwise struggle to even keep up with the master. It can also be very helpful on smaller sites with less DBA resources available, eg. to allow a slave to catch up quickly after accidentally being stopped for 5 days.

The great thing about optimistic parallel replication is that it “just works” without requiring changes on the application side (like partitioning the data), nor putting constraints on the database configuration side (like e.g. row-based binlog format).

2. Multi-source replication

Multi-source replication is the ability to replicate different data simultaneously from two (or more) master servers, and is perhaps a somewhat underrated feature of MariaDB replication. The ability to provide this kind of flexibility when it is needed is I feel at the very core of MariaDB’s success. Logical replication is the architectural foundation of this great flexibility, and while it causes a lot of complexity in the code, it provides functionality that is not available from replication architectures based on e.g. physical replication.

3. Global transaction ID (GTID)

GTID allows replication to seamlessly stop replicating from one master server and continue the replication from another. This seems obviously how things should be, but traditionally was not available in MariaDB (or MySQL) replication for a number of years.

The strength of MariaDB GTID lies to a large extent in the details of its implementation in the server code. At the core is the notion of a set of replication streams, each identified by a DBA-configured domain ID, and each containing a list of strictly ordered transactions to replicate. This allows to present the replication state in a simple way to the DBA (a single transaction ID in the simplest case), while still providing the full flexibility to support multi-source, ring, and other advanced replication topologies. And it provides the foundation that makes Optimistic Parallel Replication possible.

4. Semi-synchronous replication

Semi-synchroneous replication can be sometimes useful, but I believe is not as easy to setup efficiently as it is perhaps often perceived. It does not magically turn a MariaDB replication topology into a fully synchronous replication cluster. All it really does is delay transaction commit somewhat.

It is up to the application to fully and robustly handle any errors, which includes not only re-trying a failed transaction commit, but also the ability to correctly determine if a transaction actually succeeded despite commit returning error. I may have more to say on this at the MariaDB Day Brussels.