Comprehensive Guide to Database Horizontal Scaling, Smooth 2N Expansion, and Keepalived High‑Availability Configuration

The article addresses the challenge of expanding a sharded database when user growth makes the original three‑node setup insufficient, illustrating the need to add a fourth node and adjust the uid%N sharding rule.

It outlines five practical expansion schemes: (1) a full shutdown migration, (2) a write‑stop migration, (3) a log‑based migration, (4) a dual‑write (canal/MQ) migration for medium data volumes, and (5) a smooth 2N migration for large data sets that avoids full data movement.

Shutdown scheme: announce the maintenance window, stop the service, split and redistribute data offline, verify data integrity, update the sharding configuration, restart the service, and prepare rollback plans for each step.

Write‑stop scheme: announce the upgrade, set the service to read‑only, copy data to the new node, verify the copy, switch the sharding rule, restore write capability, and define rollback procedures.

Log‑based scheme: keep the old database online, record data‑modification logs (table, primary key, operation type), migrate data, apply incremental log replay, verify consistency, and finally switch traffic, noting the complexity of continuous log replay.

Dual‑write scheme: use Canal or MQ to replicate writes to the new node in real time, migrate existing data, handle incremental sync, switch traffic via Nginx, and perform data validation, with higher operational cost.

Smooth 2N scheme: add replica nodes (A0, B0), promote them to masters, adjust sharding to uid%4, and only clean redundant data, achieving near‑zero downtime.

Implementation details include installing MariaDB on CentOS 7:

yum -y install wget
mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
wget -P /etc/yum.repos.d/ http://mirrors.aliyun.com/repo/epel-7.repo
yum clean all
yum makecache
yum -y install mariadb mariadb-server MariaDB-client MariaDB-common

Master‑master replication is configured by editing /etc/my.cnf on each server (e.g., server1 and server2) with unique server-id , binlog settings, auto‑increment offsets, and then creating a replica user and executing CHANGE MASTER TO … followed by START SLAVE . Verification is done via SHOW SLAVE STATUS\\G .

High‑availability is achieved with Keepalived. A sample keepalived.conf defines a global_defs block, a vrrp_instance with state BACKUP , priority , authentication, and a virtual_ipaddress . The virtual_server section configures health checks and failover scripts (e.g., pkill keepalived ).

For application‑level dynamic scaling, the guide introduces ShardingJDBC (part of ShardingSphere). It shows Maven dependencies, application.yml rule configuration, and Java code to add a new DruidDataSource at runtime, update the ShardingRule, and trigger a DataSourceChangedEvent for seamless expansion.

Overall, the guide provides step‑by‑step commands, configuration snippets, and best‑practice recommendations for safely expanding a sharded database cluster while maintaining service availability.