彻底解决数据库单点故障！Keepalived+LVS(DR)+MariaDB主主高可用架构实战

彻底解决数据库单点故障！Keepalived+LVS(DR)+MariaDB主主高可用架构实战

一、项目背景

1.1 业务场景与数据库核心诉求

在企业级应用中，数据库作为业务数据的“核心载体”，其高可用性、读写性能、数据一致性直接决定业务能否稳定运行。无论是电商交易系统（订单生成、库存扣减）、金融支付平台（交易对账、资金流转），还是政务管理系统（数据上报、业务审批），均对数据库提出以下刚性需求：

（1）无间断服务（高可用）

数据库需实现24×7小时不间断运行，避免因单点故障（如数据库服务器宕机、磁盘损坏、网络中断）导致业务中断。例如：电商平台秒杀活动中，若数据库不可用，将直接导致订单无法生成，每中断1分钟可能造成数万元营收损失；金融系统中，数据库故障可能引发交易对账异常，甚至触发合规风险。

（2）高并发承载（读写性能）

随着用户规模增长，数据库面临的读写请求呈指数级上升（如日均SQL执行量从100万次增至1亿次）。单台数据库服务器的CPU、内存、IO能力易成为瓶颈：读请求过多会导致查询延迟（如用户查询订单列表超时），写请求集中会造成事务阻塞（如多用户同时提交订单导致库存更新排队）。

（3）数据零丢失（可靠性）

业务数据需具备“抗丢失”能力，即使遭遇硬件故障或软件异常，也需保证数据不损坏、不丢失。例如：用户充值记录、订单信息若因数据库故障丢失，将直接引发用户投诉与信任危机；同时，多节点间的数据需实时同步，避免出现“主库数据已更新，从库仍展示旧数据”的一致性问题。

（4）灵活扩展（可扩展性）

业务增长过程中，需支持“按需扩展”数据库能力：读压力增大时可快速新增读节点，写压力上升时可优化写分发策略，避免因架构僵化导致“业务倒逼重构”的被动局面。

1.2 传统数据库架构的痛点与局限

在采用《Keepalived + LVS（DR）+ MariaDB 主主》方案前，多数企业曾使用“单节点数据库”或“简单主从架构”，但面临以下难以突破的瓶颈：

（1）单节点数据库：单点故障风险致命

问题核心：数据库仅部署在一台服务器上，一旦服务器硬件故障（如电源损坏、磁盘坏道）或软件崩溃（如MariaDB进程异常退出），将导致全量业务中断。

恢复效率低：依赖人工干预恢复（如更换服务器、重建数据库、恢复备份），平均恢复时间（MTTR）通常超过30分钟，远无法满足“秒级切换”的业务需求；若备份数据不完整，还可能导致部分业务数据永久丢失。

（2）简单主从架构（一主一从）：读写瓶颈与切换缺陷

读性能局限：虽然通过“主库写、从库读”分摊读压力，但从库仅能扩展读能力，无法缓解主库的写压力（如大量订单写入仍集中在主库）；且从库数量增多时，缺乏统一的读请求分发机制，易导致部分从库过载（如某台从库承担80%读请求）、部分从库空闲。

高可用缺陷：主库故障时，需手动将从库提升为新主库，再修改业务系统的数据库连接地址，切换过程耗时且易出错（如忘记同步从库未应用的binlog导致数据不一致）；同时，从库仅作为“备用节点”，写请求始终依赖主库，主库写瓶颈无法突破。

（3）无负载均衡：请求分发混乱

部分企业尝试用“业务层硬编码连接地址”实现读写分离（如读请求连从库IP，写请求连主库IP），但存在两大问题：

① 缺乏故障检测机制：若某台从库宕机，业务层无法实时感知，仍会将读请求分发至故障节点，导致部分读业务失败；

② 扩展性差：新增读节点时，需修改业务代码中的连接地址列表，重启服务才能生效，不符合“无感知扩展”的运维需求。

（4）数据同步与一致性风险

传统主从架构依赖MariaDB原生的binlog同步，若网络延迟或主库binlog丢失，会导致从库数据滞后或同步失败；且主库故障时，若从库未完全同步主库数据，强制切换会造成“数据断层”（如主库已提交的订单，从库未记录）。

1.3 技术方案选型逻辑

针对上述传统架构痛点，本次采用 Keepalived + LVS(DR) + MariaDB主主 企业级高可用组合，各组件分工明确、互补适配，彻底解决单点故障、读写瓶颈、数据不一致、扩容困难等问题。

（1）MariaDB 主主双活架构

摒弃传统“单主写、多从读”架构，采用双节点双向互为主从，两台数据库均支持读写接入。一方面突破单主写入性能瓶颈，写并发能力翻倍；另一方面双节点实时binlog双向同步，任意节点宕机均无数据丢失，天然实现数据库层双活容灾。

（2）LVS-DR 四层负载均衡

LVS工作在四层传输层，基于IP+端口转发请求，转发性能、并发承载能力远超Nginx等七层负载均衡，单机可支撑10万+并发连接。DR直接路由模式核心优势：请求经过LVS调度转发，后端数据库响应流量直接回包客户端，不经过LVS回程，无带宽瓶颈，转发效率接近物理直连。同时自带实时节点健康检查，自动剔除故障数据库节点。

（3）Keepalived 高可用调度

解决LVS调度器自身单点故障问题，基于VRRP协议实现LVS主备节点秒级故障转移。主节点故障后，备节点1-3秒自动接管VIP虚拟IP，业务无感知、无需人工干预，实现负载均衡层100%高可用。

1.4 项目价值与预期目标

通过整套架构落地，实现技术、运维、业务全方位升级：

1. 高可用升级：数据库服务可用性从99.9%提升至99.99%，年均故障中断时间大幅缩减，核心业务实现秒级容灾；

2. 性能大幅提升：突破单主写入瓶颈，双主写TPS翻倍，读节点可无限横向扩容，SQL查询响应延迟大幅降低；

3. 数据安全可靠：双主双向实时同步，规避数据断层、数据丢失问题，故障自动转移，全程自动化容灾；

4. 运维极简高效：新增数据库节点仅需接入LVS集群，无需修改业务代码、无需重启业务服务，实现无感扩容。

二、MariaDB 主从/主主同步核心原理

2.1 核心组件说明

MariaDB主从复制基于binlog日志实现，核心依赖日志文件与专属同步线程：

1. binlog（主库二进制日志）：数据库核心日志，记录所有增删改、表结构变更等数据变更操作，是数据同步的唯一数据源；

2. relay log（从库中继日志）：从库本地临时日志，用于缓存从主库拉取的binlog数据，避免网络波动导致数据同步中断、丢失；

3. 核心同步线程：主库binlog dump线程（推送日志）、从库IO线程（拉取日志）、从库SQL线程（回放日志）。

2.2 标准主从同步流程

1. 主库执行数据增删改操作，事务提交后，有序将操作事件写入binlog日志；

2. 从库IO线程主动连接主库，携带日志文件名、同步点位，请求增量日志数据；

3. 主库binlog dump线程响应请求，推送对应增量binlog事件至从库；

4. 从库IO线程接收日志，写入本地relay中继日志，并更新同步点位记录；

5. 从库SQL线程实时读取中继日志，顺序回放SQL事件，完成数据同步，最终实现主从数据一致。

2.3 主主复制实现原理

主主复制本质是双向主从复制：将两台数据库节点互相配置为对方的主库和从库，db1同步db2日志、db2同步db1日志，双向实时同步数据，最终实现双节点数据完全一致、均可读写接入。

三、项目实验环境

本次部署所有主机统一网段规划、角色明确，适配企业测试/生产模拟环境：

四、全局基础环境配置

4.1 所有节点主机名与IP配置

统一配置各节点静态IP、主机名、网关与DNS，保证内网互通：

# client1 配置
hostnamectl set-hostname client1.fb.cloud
nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.21/24 ipv4.gateway 10.1.8.20 ipv4.dns 223.5.5.5 autoconnect yes
nmcli connection up ens33

# client2 配置
hostnamectl set-hostname client2.fb.cloud
nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.1.21/24 ipv4.gateway 10.1.1.20 ipv4.dns 223.5.5.5 autoconnect yes
nmcli connection up ens33

# router:
hostnamectl set-hostname router.fb.cloud
nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.20/24 ipv4.gateway 10.1.8.2 ipv4.dns 223.5.5.5 autoconnect yes
nmcli connection up ens33
nmcli connection add type ethernet con-name ens36 ifname ens36 ipv4.method manual ipv4.addresses 10.1.1.20/24 autoconnect yes
nmcli connection up ens36

# ha1 配置
hostnamectl set-hostname ha1.fb.cloud
nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.13/24 ipv4.gateway 10.1.8.20 ipv4.dns 223.5.5.5 autoconnect yes
nmcli connection up ens33

# ha2 配置
hostnamectl set-hostname ha2.fb.cloud
nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.14/24 ipv4.gateway 10.1.8.20 ipv4.dns 223.5.5.5 autoconnect yes
nmcli connection up ens33

# db1 配置
hostnamectl set-hostname db1.fb.cloud
nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.11/24 ipv4.gateway 10.1.8.20 ipv4.dns 223.5.5.5 autoconnect yes
nmcli connection up ens33

# db2 配置
hostnamectl set-hostname db2.fb.cloud
nmcli connection modify ens33 ipv4.method manual ipv4.addresses 10.1.8.12/24 ipv4.gateway 10.1.8.20 ipv4.dns 223.5.5.5 autoconnect yes
nmcli connection up ens33

4.2 路由网关转发配置

路由节点开启内核转发、配置防火墙伪装，实现跨网段互通：

# 开启内核IP转发
[root@router ~ 22:08:06]# echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
[root@router ~ 22:08:58]# sysctl -p
net.ipv4.ip_forward = 1

# 防火墙配置，放行所有流量，且开启NAT地址伪装功能
[root@router ~ 22:09:51]# systemctl enable firewalld.service –now
[root@router ~ 22:10:19]# firewall-cmd –set-default-zone=trusted
[root@router ~ 22:10:49]# firewall-cmd –add-masquerade
[root@router ~ 22:11:01]# firewall-cmd –add-masquerade –permanent

五、MariaDB 安装、初始化与主主同步部署

5.1 db1、db2 安装数据库

# 安装服务
[root@db1-2 ~ 22:03:05]# yum -y install mariadb-server

# 启动服务，并设置开机自启
[root@db1-2 ~ 22:13:29]# systemctl enable mariadb –now

# 查看状态
[root@db1-2 ~ 22:13:48]# systemctl status mariadb

# 关闭防火墙
[root@db1-2 ~ 22:14:23]# systemctl disable firewalld –now

5.2 数据库配置文件修改

db1 配置 /etc/my.cnf.d/server.cnf

[root@db1 ~ 22:14:03]# vim /etc/my.cnf.d/server.cnf
# 在下面新增3行
[mysqld]
server-id=1
log_bin=mysql-bin
relay_log=mysql-relay-bin

db2 配置 /etc/my.cnf.d/server.cnf

[root@db2 ~ 22:18:09]# vim /etc/my.cnf.d/server.cnf
# 在下面新增3行
[mysqld]
server-id=2
log_bin=mysql-bin
relay_log=mysql-relay-bin

配置完成重启服务：

[root@db1-2 ~ 22:18:15]# systemctl restart mariadb

5.3 数据库安全初始化（双节点一致）

[root@db1-2 ~ 22:19:09]# mysql_secure_installation

交互流程：默认回车无密码登录 – 设置密码为 huawei – 全程回车默认删除匿名用户、禁止远程root登录、删除test库、刷新权限。

5.4 搭建双向主主同步

5.4.1 db1授权同步用户、查看主库状态

# # 1、创建复制用户repl，仅允许从10.1.8.12连接，密码huawei，2、授予复制从库、复制客户端权限，*.*对全部库表生效
[root@db1 ~ 22:21:31]# mysql -uroot -phuawei -e "grant replication slave, replication client on *.* to 'repl'@'10.1.8.12' identified by 'huawei';"

# 刷新权限
[root@db1 ~ 22:26:46]# mysql -uroot -phuawei -e "flush privileges;"

# 输出File(日志文件名)、Position(日志偏移位置)，用于从库配置复制起点
[root@db1 ~ 22:28:10]# mysql -uroot -phuawei -e "show master status;"
+——————+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000001 | 1728 | | |
+——————+———-+————–+——————+

5.4.2 db2配置同步指向db1

mysql -uroot -phuawei << EOF
change master to
master_host='10.1.8.11', # 主库IP地址(db1.fb.cloud)
master_user='repl', # 主库授权的复制账号
master_password='huawei', # 复制账号repl的密码
master_port=3306, # 主库MySQL服务端口，默认3306
master_log_file='mysql-bin.000001', # 主库show master status获取的binlog日志文件名
master_log_pos=1728, # binlog日志偏移位置，从该点位开始同步数据
master_connect_retry=30; # 连接主库失败后，间隔30秒重试连接
start slave; # 启动从库IO线程、SQL线程，开启主从复制
EOF

# 竖行展示输出，重点看 Slave_IO_Running、Slave_SQL_Running 均为 Yes
[root@db2 ~ 22:39:10]# mysql -uroot -phuawei -e "show slave status\\G;"

# 注意如果从库有旧复制残留，执行下面命令，停止并清空旧复制配置
mysql -uroot -phuawei -e "stop slave;reset slave all;" # 停止并清空旧复制配置

校验：Slave_IO_Running=Yes、Slave_SQL_Running=Yes即为正常。

5.4.3 db2授权同步用户、查看主库状态

[root@db2 ~ 22:40:05]# mysql -uroot -phuawei -e "grant replication slave, replication client on *.* to 'repl'@'10.1.8.11' identified by 'huawei';"
[root@db2 ~ 22:45:41]# mysql -uroot -phuawei -e "flush privileges;"
[root@db2 ~ 22:45:59]# mysql -uroot -phuawei -e "show master status"
+——————+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000001 | 1728 | | |
+——————+———-+————–+——————+

5.4.4 db1配置同步指向db2

mysql -uroot -phuawei << EOF
change master to
master_host='10.1.8.12',
master_user='repl',
master_password='huawei',
master_port=3306,
master_log_file='mysql-bin.000001',
master_log_pos=1728,
master_connect_retry=30;
start slave;
EOF

# 竖行展示输出，重点看 Slave_IO_Running、Slave_SQL_Running 均为 Yes
[root@db1 ~ 22:48:28]# mysql -uroot -phuawei -e "show slave status\\G;"

5.5 主主同步数据验证

db1创建测试库表写入数据：

# db1创建
mysql -uroot -phuawei << EOF
create database test;
use test;
create table linux(username varchar(15) not null,password varchar(15) not null);
insert into linux values ('fb1', 'huawei'),('fb2', 'huawei'),('fb3', 'huawei');
commit;
EOF

# db2查看
[root@db2 ~ 22:47:28]# mysql -uroot -phuawei -e "show databases;"
+——————–+
| Database |
+——————–+
| information_schema |
| mysql |
| performance_schema |
| test |
+——————–+

db2查询可正常同步数据；反向在db2创建库表，db1同样可同步，双向主主搭建完成。

六、LVS-DR 后端数据库节点配置（db1/db2）

DR模式核心配置：两台DB节点均需绑定VIP至本地虚拟网卡，关闭ARP解析，防止IP冲突、回包异常。

# 搭建虚拟网卡承载VIP（掩码为32位），并查看是否生成
[root@db1 ~ 22:49:56]# nmcli connection add type dummy ifname dummy con-name dummy ipv4.method manual ipv4.addresses 10.1.8.100/32 autoconnect yes
[root@db1 ~ 22:55:51]# nmcli connection up dummy
[root@db1 ~ 22:56:01]# ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
ens33 UP 10.1.8.11/24 fe80::504c:83ce:f971:1b56/64 fe80::274b:8373:f96a:1c30/64 fe80::2a57:8681:577b:52f8/64
dummy0 DOWN
dummy UNKNOWN 10.1.8.100/32 fe80::376e:1fb1:af89:a20c/64

# 关闭ARP解析冲突
cat >> /etc/sysctl.conf << EOF
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.dummy.arp_ignore = 1
net.ipv4.conf.dummy.arp_announce = 2
EOF

# 生效配置
[root@db1 ~ 23:01:25]# sysctl -p
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.dummy.arp_ignore = 1
net.ipv4.conf.dummy.arp_announce = 2

七、Keepalived+LVS 调度层部署（ha1/ha2）

7.1 安装依赖组件

# 安装软件
[root@ha1-2 ~ 22:03:05]# yum -y install keepalived ipvsadm

# 备份配置文件
[root@ha1-2 ~ 23:04:08]# cp /etc/keepalived/keepalived.conf{,.ori}

7.2 ha1 主节点配置

[root@ha1 ~ 23:05:36]# vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
router_id ha1 # 设备唯一标识，主节点写ha1，备节点ha2
}

vrrp_instance db { # 定义VRRP实例，实例名称自定义为db
state MASTER # 节点角色，MASTER主节点；备节点要改成BACKUP
interface ens33 # 绑定网卡，VIP漂移到这块网卡上
virtual_router_id 51 # VRRP组ID，主备节点必须完全一致(0‑255)
priority 110 # 优先级，数值越大优先级越高；备节点设置小于110，例100
advert_int 1 # VRRP通告报文发送间隔，单位秒，每秒发一次心跳
authentication { # VRRP通信认证，主备密码必须相同
auth_type PASS # 认证类型：密码明文认证
auth_pass 1111 # VRRP组密码，主备节点必须一模一样
}
virtual_ipaddress { # 配置VIP虚拟IP地址
10.1.8.100/24 # VIP地址，24位子网掩码，会漂移在主备节点之间
}
}

virtual_server 10.1.8.100 3306 { # LVS虚拟服务，VIP+端口，对外提供mysql访问
delay_loop 6 # 后端real_server健康检查循环间隔，单位秒，每6秒检查一次
lb_algo rr # 负载均衡调度算法，rr=轮询
lb_kind DR # LVS工作模式，DR直接路由模式
persistence_timeout 50 # 会话保持时间50秒，同一客户端50秒内调度到同一后端
protocol TCP # 负载均衡协议，MySQL使用TCP

real_server 10.1.8.11 3306 { # 后端真实服务器db1，IP+mysql端口
weight 1 # 权重，调度权重，两台权重一样代表均分流量
TCP_CHECK { # 使用TCP方式做后端服务健康检测
connect_timeout 3 # 连接超时时间3秒，连不上判定服务故障
retry 3 # 失败重试次数，最多重试3次
delay_before_retry 3 # 每次重试之间等待间隔3秒
}
}
real_server 10.1.8.12 3306 { # 后端真实服务器db2，IP+mysql端口
weight 1 # 调度权重
TCP_CHECK { # TCP健康检查
connect_timeout 3 # TCP连接超时3秒
retry 3 # 失败重试3次
delay_before_retry 3 # 重试前等待3秒
}
}
}

7.3 ha2 备节点配置

[root@ha2 ~ 23:08:30]# vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived

global_defs {
router_id ha2
}

vrrp_instance db {
state BACKUP
interface ens33
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.1.8.100/24
}
}

virtual_server 10.1.8.100 3306 {
delay_loop 6
lb_algo rr
lb_kind DR
persistence_timeout 50
protocol TCP

real_server 10.1.8.11 3306 {
weight 1
TCP_CHECK {
connect_timeout 3
retry 3
delay_before_retry 3
}
}
real_server 10.1.8.12 3306 {
weight 1
TCP_CHECK {
connect_timeout 3
retry 3
delay_before_retry 3
}
}
}

7.4 启动高可用服务

# ha1和ha2启动服务，并开启开机自启
[root@ha1-2 ~ 23:20:07]# systemctl enable keepalived –now

# ha1和ha2关闭防火墙
[root@ha1-2 ~ 23:20:42]# systemctl disable firewalld –now

# ha1查看生效情况
[root@ha1 ~ 23:20:30]# ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
ens33 UP 10.1.8.13/24 10.1.8.100/24

八、业务测试用户授权与连通性测试

8.1 数据库授权远程测试账号

[root@db1 ~ 23:01:33]# mysql -uroot -phuawei -e "grant ALL PRIVILEGES on *.* to 'fb'@'%' identified by 'huawei';"
[root@db1 ~ 23:31:01]# mysql -uroot -phuawei -e "FLUSH PRIVILEGES;"

8.2 客户端连接测试

# 客户端mariadb工具
[root@client1 ~ 22:03:04]# yum -y install mariadb

# 通过VIP虚拟入口连接数据库集群
[root@client1 ~ 23:32:35]# mysql -ufb -phuawei -h 10.1.8.100
Welcome to the MariaDB monitor. Commands end with ; or \\g.
Your MariaDB connection id is 299
Server version: 5.5.68-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\\h' for help. Type '\\c' to clear the current input statement.

MariaDB [(none)]>

# 当前访问的是db2数据库
MariaDB [(none)]> select @@hostname;
+————–+
| @@hostname |
+————–+
| db2.fb.cloud |
+————–+
1 row in set (0.01 sec)

MariaDB [(none)]>

九、全场景高可用故障模拟测试

验证集群容灾能力，模拟生产常见故障：

9.1 调度器主节点故障转移

# 停止主节点ha1 keepalived
[root@ha1 ~ 23:24:34]# systemctl stop keepalived

# ha2成了主节点
[root@ha2 ~ 23:24:45]# ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
ens33 UP 10.1.8.14/24 10.1.8.100/24

# 客户端可以正常访问
[root@client1 ~ 23:36:27]# mysql -ufb -phuawei -h 10.1.8.100
Welcome to the MariaDB monitor. Commands end with ; or \\g.
Your MariaDB connection id is 357
Server version: 5.5.68-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\\h' for help. Type '\\c' to clear the current input statement.

MariaDB [(none)]>

现象：VIP自动漂移至ha2备节点，客户端数据库连接无中断、无报错，业务正常运行。

9.2 后端数据库节点故障剔除

# 停止db2数据库服务
[root@db2 ~ 23:01:33]# systemctl stop mariadb

# 客户端访问正常，访问的是db1数据库
MariaDB [(none)]> select @@hostname;
+————–+
| @@hostname |
+————–+
| db1.fb.cloud |
+————–+
1 row in set (0.01 sec)

MariaDB [(none)]>

现象：LVS健康检查检测节点失效，自动剔除db1，所有请求自动调度至db2，业务读写正常。

9.3 故障节点恢复自愈

# 重启故障节点服务
[root@db2 ~ 23:37:56]# systemctl start mariadb
[root@ha1 ~ 23:34:32]# systemctl start keepalived
[root@ha1 ~ 23:41:56]# ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
ens33 UP 10.1.8.13/24 10.1.8.100/24

现象：节点恢复后，LVS自动重新纳入集群，重新参与负载均衡调度，集群自愈完成。

十、生产核心注意事项（避坑指南）

10.1 LVS配置硬性限制

Keepalived 的 real_server仅支持IP地址，不支持域名。因为LVS工作在四层传输层，无DNS解析能力，填写域名会直接报错启动失败，生产环境必须写死后端真实IP。

10.2 DR模式必配项

所有后端RS节点必须配置虚拟网卡绑定VIP、关闭ARP解析，否则会出现IP地址冲突、回包路由异常，导致数据库连接时通时断。

10.3 主主复制生产优化

测试环境无主键冲突问题，生产环境必须配置自增ID偏移，避免双主同时写入产生主键重复、数据写入失败。

10.4 健康检查优化

默认仅检测3306端口存活，无法判断数据库真实读写状态。生产建议自定义shell脚本，检测数据库查询、写入可用性，实现精准故障剔除。

10.5 权限与安全加固

测试环境全权限开放，生产需严格收紧数据库远程权限、禁用不必要账号、修改默认密码、开启防火墙端口白名单，规避安全风险。

十一、架构总结

Keepalived+LVS(DR)+MariaDB主主 是中小企业性价比极高的数据库高可用解决方案，彻底解决传统架构四大痛点：

1. 彻底消除单点故障：调度层主备漂移、数据库层双活冗余，全程自动容灾；

2. 性能大幅提升：四层LVS高并发转发、双主分担写入压力，突破单库性能瓶颈；

3. 数据安全可控：双向实时同步，规避数据延迟、丢失、断层问题；

4. 运维极简：统一VIP入口、无感扩容、自动故障转移，大幅降低运维成本。

整套架构稳定可靠、可直接落地生产，适合电商、金融、政务等核心业务数据库高可用场景部署。
启动失败，生产环境必须写死后端真实IP。

10.2 DR模式必配项

所有后端RS节点必须配置虚拟网卡绑定VIP、关闭ARP解析，否则会出现IP地址冲突、回包路由异常，导致数据库连接时通时断。

10.3 主主复制生产优化

测试环境无主键冲突问题，生产环境必须配置自增ID偏移，避免双主同时写入产生主键重复、数据写入失败。

10.4 健康检查优化

默认仅检测3306端口存活，无法判断数据库真实读写状态。生产建议自定义shell脚本，检测数据库查询、写入可用性，实现精准故障剔除。

10.5 权限与安全加固

测试环境全权限开放，生产需严格收紧数据库远程权限、禁用不必要账号、修改默认密码、开启防火墙端口白名单，规避安全风险。

十一、架构总结

Keepalived+LVS(DR)+MariaDB主主 是中小企业性价比极高的数据库高可用解决方案，彻底解决传统架构四大痛点：

1. 彻底消除单点故障：调度层主备漂移、数据库层双活冗余，全程自动容灾；

2. 性能大幅提升：四层LVS高并发转发、双主分担写入压力，突破单库性能瓶颈；

3. 数据安全可控：双向实时同步，规避数据延迟、丢失、断层问题；

4. 运维极简：统一VIP入口、无感扩容、自动故障转移，大幅降低运维成本。

整套架构稳定可靠、可直接落地生产，适合电商、金融、政务等核心业务数据库高可用场景部署。