Galera Cluster and MariaDB MySQL Replication

Explore database replication by copying data from one node to many, enabling load balancing and dedicated backup and reporting nodes while keeping data consistent across all servers.

Explain the acid model of the database and how replication must guarantee atomicity, consistency, isolation, and durability, ensuring transactions commit or roll back and the database maintains durability.

Learn master-slave and multi-master replication in Galera Cluster, where a master logs updates to a binary log, slaves apply them, and reads scale on slaves while writes go to master.

Explore the differences between synchronous, semi synchronous, and asynchronous replication in MariaDB MySQL with Galera cluster, focusing on data consistency, commit semantics, and propagation delays.

compare statement-based and row-based replication in Galera cluster and MariaDB MySQL replication, highlighting that statement-based replicates SQL statements for speed, while row-based replication transfers actual data changes for safety.

Explore certification based replication in the Galera cluster to build a synchronous environment, focusing on group communication, write sets, transaction reordering, and the database state machine.

Explore how Galera certification validates right sets across a three-node cluster, using optimistic updates, right sets, version numbers, and a group communication toolkit to commit or rollback transactions.

Explore isolation types in the Galera cluster, covering read uncommitted, read committed, repeatable read, and serializable, including their definitions, tradeoffs, and mode-specific support.

Explore the lost update problem in Galera clusters under repeatable read, and learn how snapshot isolation, certification, and innodb select for update prevent conflicting writes.

Compare state snapshot transfer and incremental state transfer in a Galera cluster for provisioning new nodes. Use logical (mysql dump) or physical file copy (rsync) for snapshot transfer.

Learn Galera cluster limitations: InnoDB only, non replication of MyISAM writes, DDL statements replicate, primary keys required for deletes, and row-order changes without keys, plus transaction size constraints.

Prepare three CentOS 7 nodes with at least 1 GHz CPU and 512 MB RAM for a Galera cluster, configure host names and hosts file, and ensure internet connectivity.

Install MariaDB 10.1 from MariaDB repositories on three CentOS nodes by creating and distributing the repository file, then configure the gpg key check and install server, client, and common packages.

On a single node, start MariaDB and run mysql_secure_installation to set the root password, remove anonymous users, disallow remote root login, remove the test database, and reload privileges.

Configure a three-node Galera cluster by editing the Galera section in server.conf, enabling write set replication, group communication addresses, row-based binary logging, and rsync-based snapshot transfer.

Start a galera cluster across three nodes, start MariaDB on each node, and verify the cluster size as it grows from one to three to confirm all nodes join replication.

Check replication across the Galera cluster by creating the test100 database and T1 table (A int, InnoDB), inserting records on multiple nodes, and confirming all nodes replicate the data.

See how to gracefully shut down Galera cluster nodes, observe cluster size changes, and verify that data replicates across remaining nodes during outages and after recovery.

Poweroff test in a three-node Galera cluster demonstrates cluster size changes, quorum requirements, and how data replicates across nodes during recovery.

Stop all cluster nodes, restart them, and verify MariaDB status and cluster size. If boot issues occur, modify state.dat to bootstrap from 0 to 1 on a server.

Join a new node to a four-node Galera cluster by installing MariaDB, updating the Galera config on all nodes, and restarting services to replicate the test database.

Explain weighted quorum in Galera cluster and how split brain occurs in multi-master replication, where two nodes update the same row while each thinks the other is down.

Explore how weighted quorum uses cluster size and votes to determine majority decisions, guiding primary and non-primary states and helping avoid split brain with weighted nodes.