在Kubernetes中实现双MariaDB实例共用持久存储及数据同步的问询

Hey there! Let's sort out how to get your two MariaDB Pods in sync while keeping both accessible. First, a critical note: sharing a single PersistentVolumeClaim (PVC) between two MariaDB instances is extremely risky. MariaDB (like most relational databases) isn't built to handle simultaneous read/write operations on the same underlying storage—this will almost certainly lead to data corruption or loss. So we need to fix that with proper replication setups instead.

Below are two proven solutions depending on your exact needs:

Option 1: Master-Slave Replication (One Write, Multiple Reads) #

This is the simplest setup if you only need one instance to handle writes, and both instances can serve reads.

Step 1: Configure the Master Instance (mariadb-instance-1) #

1. Mount a custom my.cnf via ConfigMap to enable binary logging:

   [mysqld]
   server-id=1  # Unique ID for the master
   log-bin=mysql-bin
   binlog-format=ROW  # Ensures reliable replication
   expire_logs_days=7  # Clean up old logs automatically
   

2. Create a replication user once the master is running:

   CREATE USER 'repl_user'@'%' IDENTIFIED BY 'your_secure_repl_password';
   GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
   FLUSH PRIVILEGES;
   

3. Lock tables temporarily to get the master state (don't close this session until you unlock):

   FLUSH TABLES WITH READ LOCK;
   SHOW MASTER STATUS;
   

   Note down the File (e.g., mysql-bin.000001) and Position (e.g., 154) values, then unlock tables:

   UNLOCK TABLES;
   

Step 2: Configure the Slave Instance (mariadb-instance-2) #

1. Mount its own custom my.cnf (with a unique server ID):

   [mysqld]
   server-id=2  # Must be different from the master
   read-only=1  # Optional but recommended to prevent accidental writes
   

2. Connect to the slave and start replication using the master's details:

   CHANGE MASTER TO
   MASTER_HOST='mariadb-instance-1',  # Use the master's Pod DNS name or a Headless Service name
   MASTER_USER='repl_user',
   MASTER_PASSWORD='your_secure_repl_password',
   MASTER_LOG_FILE='mysql-bin.000001',  # The File value from master status
   MASTER_LOG_POS=154;  # The Position value from master status
   
   START SLAVE;
   

3. Verify replication is working:

   SHOW SLAVE STATUS\G
   

   Check that Slave_IO_Running and Slave_SQL_Running both show Yes.

Kubernetes Tips for This Setup #

• Use a Headless Service to give both Pods stable DNS names so they can reliably communicate.
• Store the replication password in a Kubernetes Secret instead of hardcoding it.
• Use init containers or mount SQL scripts to /docker-entrypoint-initdb.d/ to automate user creation and replication setup on first run.

Option 2: Galera Cluster (Multi-Master, All Nodes Read/Write) #

If you need both instances to accept write operations and stay in sync, use MariaDB Galera Cluster. This uses synchronous replication across nodes, so changes on one node are immediately propagated to others.

Key Note for Galera #

Unlike your initial setup, each Galera node needs its own PVC. Galera replicates data over the network—sharing storage is not required (and not supported).

Step 1: Prepare Galera Configuration (Per Node) #

Create a ConfigMap with a base my.cnf, then adjust per node:

[mysqld]
server-id=1  # Unique ID for each node (1 for instance-1, 2 for instance-2)
binlog-format=ROW
default-storage-engine=InnoDB
innodb-autoinc-lock-mode=2  # Required for Galera
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so  # Path varies by image
wsrep_cluster_name='mariadb-galera-cluster'
wsrep_cluster_address='gcomm://mariadb-instance-1,mariadb-instance-2'  # List all node DNS names
wsrep_node_name='mariadb-instance-1'  # Match the current node's name
wsrep_node_address='mariadb-instance-1'  # Match the current node's DNS name
wsrep_sst_method=rsync  # Fast initial sync method

Step 2: Bootstrap the Cluster #

1. Start the first node (mariadb-instance-1) with the bootstrap flag to initialize the cluster:

   mysqld --wsrep-new-cluster
   

2. Start the second node normally—it will automatically detect and join the cluster.

Kubernetes Tips for Galera #

• Use a StatefulSet instead of individual Pods. StatefulSets provide stable, predictable names (e.g., mariadb-galera-0, mariadb-galera-1) which are critical for cluster discovery.
• Use a Headless Service to enable DNS-based node discovery.
• Set up readiness/liveness probes to check cluster health (e.g., query SHOW STATUS LIKE 'wsrep_cluster_size'; to confirm the node is part of the cluster).

Final Reminders #

• Never share a single PVC between multiple MariaDB instances—this is a recipe for data loss.
• Choose the setup that matches your workload: Master-Slave is simpler for read-heavy workloads, while Galera is for true multi-write scenarios.
• Always test replication setups with dummy data before using them in production to ensure sync works as expected.

内容的提问来源于stack exchange，提问作者Chandan Ghosh