1. 项目概述为什么需要MariaDB主从配置在任何一个稍有规模的线上业务里数据库都是那个最核心、也最脆弱的“心脏”。我经历过不止一次因为一次意外的服务器宕机、一次错误的批量更新或者仅仅是硬件老化导致整个数据库服务中断业务直接停摆。那种感觉就像看着自己的心血突然休克而你能做的却不多。所以当业务量开始爬坡数据安全性和服务可用性成为必须考虑的问题时数据库的主从复制Master-Slave Replication就成了一个绕不开的基础设施。MariaDB作为MySQL的一个重要分支以其完全开源、性能优异和与MySQL的高度兼容性赢得了大量开发者和企业的青睐。它的主从复制机制本质上就是将一个数据库服务器主库上的数据变更实时地同步到一个或多个其他服务器从库上。这听起来简单但背后的价值巨大读写分离可以大幅提升查询性能数据备份提供了近乎实时的容灾能力高可用架构为故障切换提供了可能。无论是电商平台的订单库、内容管理系统的文章库还是物联网设备的数据汇聚点主从配置都是构建稳健数据层的基石。今天我就以一个老运维的视角带你从头到尾、掰开揉碎地走一遍MariaDB主从配置的全过程。我不会只给你干巴巴的命令我会告诉你每个参数为什么这么设操作中可能会在哪个阴沟里翻船以及如何验证你的配置真的在“干活”。无论你是正在为毕业设计搭建数据库环境的学生还是需要为团队业务部署生产级数据库的工程师这篇内容都能给你一份可以直接“抄作业”的实操指南。2. 核心原理与架构设计拆解在动手敲命令之前我们必须先搞清楚MariaDB主从复制到底是怎么“跑”起来的。理解了这个后面所有的配置和排错都会变得有章可循。2.1 二进制日志Binary Log复制的源头主从复制的核心在于主库的二进制日志binlog。你可以把它想象成数据库的“操作录像机”。每当主库上发生数据变更增、删、改或数据结构变更建表、改表这些事件Event都会被顺序记录到binlog文件中。它记录的不是最终的数据页而是导致数据变化的SQL语句Statement-Based或者行数据的变化Row-Based甚至是两者的混合Mixed。为什么是binlog因为它提供了数据变化的完整流水账。从库只需要拿到这份流水账在自己的数据库上“重放”一遍就能得到和主库一模一样的数据状态。这比直接拷贝数据文件要高效和灵活得多尤其是在需要持续同步的场景下。2.2 复制线程数据搬运工复制过程主要由三个线程协作完成Binlog Dump Thread主库当有从库连接上来时主库会为每个从库创建一个“binlog倾倒”线程。这个线程负责读取主库的binlog事件并将其发送给从库的I/O线程。I/O Thread从库从库的I/O线程负责连接到主库接收主库Binlog Dump Thread发来的binlog事件并将其写入到从库本地的中继日志Relay Log文件中。你可以把它理解成从库的“接收和暂存员”。SQL Thread从库从库的SQL线程负责读取本地的中继日志解析并执行其中记录的SQL事件从而让从库的数据与主库保持一致。它就是最终的“执行者”。这个“接收-存储-执行”的管道机制保证了即使在网络短暂中断时从库已经接收到的数据也不会丢失存储在中继日志里网络恢复后可以继续同步。2.3 复制模式的选择Statement vs. Row vs. Mixed这是配置前必须做的一个关键决策它直接影响复制的准确性、性能和兼容性。复制模式工作原理优点缺点适用场景基于语句 (SBR)记录执行的SQL语句。binlog文件小日志量少易于人工阅读。不确定性高。如UPDATE ... LIMIT 1若无ORDER BY主从可能更新不同行使用非确定性函数如NOW(),RAND()会导致主从不一致。早期版本默认模式现在已不推荐作为主要模式。基于行 (RBR)记录每行数据如何被修改修改前、后的行数据。最安全能保证主从数据的绝对一致性。对非确定性函数免疫。binlog文件体积大特别是批量更新时日志不可读是二进制格式。生产环境推荐模式。尤其适用于金融、交易等对数据一致性要求极高的场景。混合模式 (MIXED)默认使用SBR仅在可能引发不一致时自动切换为RBR。兼顾了文件大小和安全性。仍存在少量边界情况可能不如纯RBR可靠。MariaDB 10.0 的默认模式是一个不错的折中选择。我的经验与建议对于绝大多数生产环境我强烈建议直接使用binlog_format ROW。在存储成本已经非常低廉的今天数据的一致性和可靠性远比节省那点磁盘空间重要。曾经有一次我们因为使用了SBR一个包含RAND()的存储过程导致从库数据大面积错乱排查起来苦不堪言。切换到RBR后这类问题彻底消失。3. 实战部署一步步搭建主从环境理论清楚了我们进入实战环节。假设我们有两台全新的CentOS 7服务器Ubuntu/Debian步骤类似主要是包管理命令不同IP分别为192.168.1.100主和192.168.1.101从。目标是搭建一个一主一从的复制架构。3.1 环境准备与MariaDB安装首先在两台服务器上执行相同的初始化步骤。步骤1添加MariaDB官方仓库并安装CentOS 7自带的MariaDB版本可能较旧建议使用官方最新稳定版。# 在主库和从库服务器上执行 # 1. 安装必要的工具 sudo yum install -y epel-release sudo yum install -y wget # 2. 创建MariaDB的YUM仓库配置文件 sudo tee /etc/yum.repos.d/MariaDB.repo EOF # MariaDB 10.11 Stable Repository [mariadb] name MariaDB baseurl https://mirrors.aliyun.com/mariadb/yum/10.11/centos7-amd64 gpgkeyhttps://mirrors.aliyun.com/mariadb/yum/RPM-GPG-KEY-MariaDB gpgcheck1 EOF # 3. 安装MariaDB服务器和客户端 sudo yum install -y MariaDB-server MariaDB-client # 4. 启动服务并设置开机自启 sudo systemctl start mariadb sudo systemctl enable mariadb步骤2运行安全初始化脚本安装后运行mysql_secure_installation脚本设置root密码移除匿名用户、禁止root远程登录等。这是一个好习惯。sudo mysql_secure_installation按照提示操作即可。这里建议为root设置一个强密码并记住它。注意生产环境中绝对不要使用root账户进行应用连接和日常管理。后续所有操作为了演示清晰我们暂时使用root但在你的实际环境中请务必创建具有最小权限的专属复制账户和应用账户。3.2 主库Master配置详解现在我们开始配置主库192.168.1.100。步骤1编辑主库配置文件MariaDB的主配置文件通常是/etc/my.cnf或/etc/my.cnf.d/server.cnf。我们在这里进行关键配置。sudo vim /etc/my.cnf.d/server.cnf在[mysqld]配置段中添加或修改以下参数[mysqld] # 服务器唯一ID这是主从复制的“身份证”必须唯一 server-id 100 # 启用二进制日志并指定日志文件的前缀 log-bin mysql-bin # 设置二进制日志格式为ROW推荐生产环境使用 binlog_format ROW # 可选指定需要复制的数据库多个库用逗号隔开。不配置则默认复制所有库。 # binlog-do-db your_database_name # 可选指定不需要复制的数据库黑名单。与binlog-do-db二选一。 # binlog-ignore-db mysql, information_schema, performance_schema # 可选设置二进制日志的过期时间防止磁盘被占满单位天 expire_logs_days 7 # 可选控制每个binlog文件的最大大小单位字节达到后会自动滚动 max_binlog_size 100M关键参数解读server-id100我习惯用IP地址的最后一段作为ID只要保证主从不同即可。log-binmysql-bin开启了binlog文件将以mysql-bin.000001这样的序列命名。binlog_formatROW这是我们之前讨论后做的选择确保数据一致性。步骤2重启MariaDB服务使配置生效sudo systemctl restart mariadb步骤3创建用于复制的专属用户从库需要使用一个账户来连接主库并拉取binlog。我们创建一个权限明确的复制账号。登录MariaDB控制台sudo mysql -u root -p执行以下SQL语句-- 创建一个用户名为‘repl’允许从‘192.168.1.101’从库IP登录的用户 -- 密码请替换为强密码例如‘Repl123Secure’ CREATE USER repl192.168.1.101 IDENTIFIED BY YourStrongPassword123!; -- 授予该用户REPLICATION SLAVE权限。这个权限很小只能用于复制很安全。 GRANT REPLICATION SLAVE ON *.* TO repl192.168.1.101; -- 刷新权限使其立即生效 FLUSH PRIVILEGES;步骤4锁定数据库并查看主库状态为了获取一个一致的复制起点我们需要暂时阻止新的数据写入。-- 1. 锁定所有表为只读状态 FLUSH TABLES WITH READ LOCK; -- 2. 查看主库当前状态记录下File和Position的值从库连接时需要 SHOW MASTER STATUS;执行SHOW MASTER STATUS;后你会看到类似下面的输出------------------------------------------------------------ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | ------------------------------------------------------------ | mysql-bin.000001 | 328 | | | ------------------------------------------------------------请务必记下File(mysql-bin.000001) 和Position(328) 这两个值它们是复制的“坐标”。现在保持这个终端窗口打开不要退出也不要执行UNLOCK TABLES。我们快速去从库进行初始数据同步。3.3 从库Slave配置与初始同步切换到从库服务器192.168.1.101。步骤1编辑从库配置文件sudo vim /etc/my.cnf.d/server.cnf添加或修改以下参数[mysqld] # 服务器唯一ID必须与主库不同 server-id 101 # 可选启用中继日志 relay-log mysql-relay-bin # 可选防止从库被意外写入除非你明确需要级联复制 read_only 1read_only1会让从库处于只读模式超级用户如root除外这是一个重要的安全措施防止应用误操作写入了从库导致主从不一致。步骤2重启从库服务sudo systemctl restart mariadb步骤3进行主库数据全量备份与恢复这是搭建主从的关键一步让从库在开始增量同步前拥有和主库完全一致的数据快照。方法有很多最常用的是mysqldump。我们回到主库服务器打开另一个新的终端因为之前的终端还锁着表。在主库的新终端执行备份# 使用之前记录的root密码 mysqldump -u root -p --all-databases --master-data --single-transaction --flush-logs /tmp/full_backup.sql--all-databases备份所有库。--master-data2这个参数会在备份文件中以注释的形式记录下备份时刻主库的binlog文件和位置就是我们之前SHOW MASTER STATUS看到的信息。2表示以注释形式记录不会自动执行CHANGE MASTER。--single-transaction对InnoDB表进行一致性备份不会锁表对于MyISAM表无效。--flush-logs备份完成后滚动binlog方便后续定位。将备份文件传到从库scp /tmp/full_backup.sql root192.168.1.101:/tmp/现在回到从库服务器导入备份sudo mysql -u root -p /tmp/full_backup.sql步骤4解锁主库数据备份并传输完成后回到主库那个一直锁着表的终端解锁表允许主库继续正常写入。UNLOCK TABLES;步骤5配置从库连接主库登录从库的MariaDB控制台sudo mysql -u root -p执行CHANGE MASTER TO命令告诉从库主库在哪里用什么账号连接以及从哪个位置开始同步。STOP SLAVE; -- 先停止旧的复制进程如果是全新配置可忽略 CHANGE MASTER TO MASTER_HOST192.168.1.100, -- 主库IP MASTER_USERrepl, -- 刚才创建的复制账号 MASTER_PASSWORDYourStrongPassword123!, -- 复制账号密码 MASTER_PORT3306, -- 主库端口默认3306 MASTER_LOG_FILEmysql-bin.000001, -- 主库状态中的File MASTER_LOG_POS328, -- 主库状态中的Position MASTER_CONNECT_RETRY10; -- 连接失败后的重试间隔秒步骤6启动复制并检查状态START SLAVE; -- 启动复制进程检查从库复制状态SHOW SLAVE STATUS\G使用\G代替分号可以让结果以垂直格式显示更易读。3.4 验证与监控确保复制健康运行执行SHOW SLAVE STATUS\G后你需要重点关注以下几行Slave_IO_State: 显示当前I/O线程的状态Waiting for master to send event是正常状态。Slave_IO_Running:必须为Yes。表示I/O线程正在运行能从主库接收日志。Slave_SQL_Running:必须为Yes。表示SQL线程正在运行能执行中继日志。Seconds_Behind_Master:主从延迟秒数。理想情况下是0。如果是一个较小的正整数表示有轻微延迟如果是NULL通常表示复制进程有问题。Last_IO_Error/Last_SQL_Error: 显示最近的错误信息。正常应为空。如果Slave_IO_Running和Slave_SQL_Running都是Yes且Seconds_Behind_Master为0或一个稳定的小数值那么恭喜你主从复制已经成功搭建进行一次快速验证在主库上创建一个测试数据库和表并插入数据。CREATE DATABASE replication_test; USE replication_test; CREATE TABLE test_table (id INT, name VARCHAR(20)); INSERT INTO test_table VALUES (1, Master);在从库上查询看数据是否同步过来。USE replication_test; SELECT * FROM test_table;如果能查询到(1, ‘Master’)这条记录说明复制功能完全正常。4. 深度运维问题排查与性能调优配置成功只是第一步让主从复制长期稳定、高效地运行才是真正的挑战。下面分享一些我踩过坑后总结的运维经验。4.1 常见问题排查实录当SHOW SLAVE STATUS\G显示异常时不要慌按以下思路排查。问题1Slave_IO_Running Connecting 或 No这通常是网络或权限问题。检查网络在从库上ping 192.168.1.100telnet 192.168.1.100 3306。检查主库防火墙确保主库3306端口对从库IP开放。检查复制用户权限在主库上确认repl192.168.1.101用户存在且具有REPLICATION SLAVE权限。检查密码确认CHANGE MASTER TO中密码是否正确。查看错误信息SHOW SLAVE STATUS\G中的Last_IO_Error字段会给出具体错误。问题2Slave_SQL_Running No这通常是SQL线程执行中继日志中的事件时出错比如在主库上删除了一个不存在的表或者在从库上执行INSERT时发生了主键冲突。查看具体错误Last_SQL_Error字段会告诉你出错的SQL和原因。经典解决方法——跳过错误STOP SLAVE; SET GLOBAL sql_slave_skip_counter 1; -- 跳过1个事件 START SLAVE;警告sql_slave_skip_counter要谨慎使用它会让从库跳过主库的binlog事件可能导致数据不一致。仅当你知道这个错误可以忽略例如重复创建已存在的数据库时使用。更好的方法是找出不一致的根源并手动修复数据。数据不一致的根治方法如果跳过错误不能解决或者出现了严重不一致最彻底的方法是重建从库停止从库重新做主库的全量备份恢复到从库然后用新的binlog位置重新配置CHANGE MASTER TO。问题3Seconds_Behind_Master 值很大且持续增长这表示从库严重落后于主库。原因1从库服务器性能瓶颈。检查从库的CPU、内存、磁盘I/O使用率。可能是从库硬件配置远低于主库或者从库上运行了其他重负载服务。原因2网络延迟。主从服务器跨地域或网络质量差。原因3大事务。主库执行了一个耗时很长的更新比如不带索引的批量DELETE这个事务在binlog里是一个大事件从库需要同样长的时间来回放。原因4从库的串行回放。默认情况下从库的SQL线程是单线程的如果主库并发很高从库可能跟不上。可以考虑升级到MariaDB 10.0并开启并行复制。4.2 性能优化与高级配置1. 开启并行复制Multi-Threaded Slave对于写入频繁的主库单线程的SQL线程是主要瓶颈。MariaDB 10.0 支持基于组提交group commit的并行复制。在从库配置文件 (my.cnf) 中添加[mysqld] slave_parallel_threads 4 # 设置并行工作线程数通常设置为CPU核心数 slave_parallel_mode optimistic # 或 ‘conservative‘ ‘optimistic’ 模式更激进性能更好重启从库后观察SHOW SLAVE STATUS\G中的Exec_Master_Log_Pos追赶速度是否加快。2. 半同步复制Semi-Synchronous Replication默认的复制是异步的主库提交事务后不等从库确认就返回给客户端。如果主库宕机可能丢失已提交但未同步到任何从库的数据。 半同步复制要求主库提交事务时至少有一个从库确认收到了该事务的binlog事件主库才返回给客户端成功。在主库和从库的配置文件中都添加[mysqld] plugin_load_add semisync_master.so # 主库插件 plugin_load_add semisync_slave.so # 从库插件在主库和从库分别执行-- 主库 INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so’; SET GLOBAL rpl_semi_sync_master_enabled 1; -- 从库 INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so’; SET GLOBAL rpl_semi_sync_slave_enabled 1;然后重启从库的复制进程 (STOP SLAVE; START SLAVE;)。使用SHOW STATUS LIKE ‘Rpl_semi_sync%’;查看状态。3. 定期监控与维护脚本自动化是运维的好朋友。可以写一个简单的Shell脚本定期检查复制状态并报警。#!/bin/bash # check_replication.sh USER“root” PASS“your_password” SLAVE_STATUS$(mysql -u$USER -p$PASS -e “SHOW SLAVE STATUS\G”) IO_RUNNING$(echo “$SLAVE_STATUS” | grep “Slave_IO_Running:” | awk ‘{print $2}’) SQL_RUNNING$(echo “$SLAVE_STATUS” | grep “Slave_SQL_Running:” | awk ‘{print $2}’) SECONDS_BEHIND$(echo “$SLAVE_STATUS” | grep “Seconds_Behind_Master:” | awk ‘{print $2}’) if [[ “$IO_RUNNING” ! “Yes” ]] || [[ “$SQL_RUNNING” ! “Yes” ]]; then echo “CRITICAL: MySQL Replication is broken! IO: $IO_RUNNING, SQL: $SQL_RUNNING” | mail -s “MySQL Replication Alert” adminyourcompany.com fi if [[ $SECONDS_BEHIND -gt 300 ]]; then # 延迟超过5分钟报警 echo “WARNING: MySQL Replication lag is $SECONDS_BEHIND seconds” | mail -s “MySQL Replication Lag Alert” adminyourcompany.com fi将这个脚本加入crontab每5分钟执行一次。5. 生产环境进阶考量与架构延伸一个健壮的生产环境不会只满足于一主一从。随着业务发展你需要考虑更复杂的架构。5.1 一主多从架构这是最常见的扩展模式。一个主库多个从库。所有从库的配置方法都一样只需注意每个从库的server-id必须唯一。这种架构非常适合读多写少的场景可以将大量的查询请求如报表、数据分析、用户查询分摊到多个从库上极大减轻主库压力。负载均衡在应用和数据库之间可以使用HAProxy、LVS或F5等负载均衡器或者使用像MyCat、ShardingSphere这样的中间件来分发读请求到各个从库。5.2 主-主复制双主模式两个库互为主从都能接受写入。这听起来很美好可以实现写负载分担和更高可用性但极其危险除非你非常清楚自己在做什么。致命陷阱——数据冲突如果两个主库同时修改了同一行数据就会产生无法自动解决的冲突导致数据不一致。因此双主模式必须有严格的应用层分片规则例如库A只处理用户ID为偶数的写入库B只处理用户ID为奇数的写入从根源上避免交叉写入。配置要点除了互设server-id和互配复制账号必须在配置文件中开启自增ID偏移防止主键冲突。# 在服务器A上 auto_increment_increment 2 # 自增步长 auto_increment_offset 1 # 起始偏移 # 在服务器B上 auto_increment_increment 2 auto_increment_offset 2这样A库生成的ID是1,3,5,7…B库生成的是2,4,6,8…。5.3 级联复制Master - Slave - Slave当从库数量非常多时全部从主库拉取binlog会给主库带来巨大的网络和I/O压力。这时可以采用级联复制让一部分从库称为“中继从库”从主库同步其他从库再从这些“中继从库”同步。配置方法只需将第三级从库的MASTER_HOST指向第二级从库的IP并在第二级从库上为其创建复制账号即可。同时需要在第二级从库的配置中开启log_slave_updates1让它把从主库接收并执行过的事件也记录到自己的binlog中供下级从库读取。5.4 高可用方案与Keepalived/HAProxy结合主从复制本身不提供自动故障转移。如果主库宕机需要人工介入将一个从库提升为主库并修改应用配置。这个过程可能意味着分钟级别的服务中断。为了实现更高可用性可以引入Keepalived 虚拟IPVIP或HAProxy。Keepalived VIP在两台服务器主库和某个从库上安装Keepalived虚拟出一个VIP如192.168.1.10。应用始终连接这个VIP。Keepalived通过脚本检测主库健康状态一旦主库故障自动将VIP漂移到备库原从库并执行提升备库为主库的脚本。对应用透明切换速度快。HAProxy对于读多写少的场景可以将HAProxy部署在应用和数据库之间。写请求定向到主库读请求负载均衡到多个从库。当HAProxy检测到主库宕机可以配合脚本自动将从库提升为新主并更新HAProxy的配置。这种方式更灵活但应用需要配置读写分离。这些架构的搭建涉及更多组件和更复杂的运维建议在充分测试和理解后再上生产环境。主从复制是基石理解了它这些更高级的架构对你来说就不再是黑盒。
1. 项目概述为什么需要MariaDB主从配置在任何一个稍有规模的线上业务里数据库都是那个最核心、也最脆弱的“心脏”。我经历过不止一次因为一次意外的服务器宕机、一次错误的批量更新或者仅仅是硬件老化导致整个数据库服务中断业务直接停摆。那种感觉就像看着自己的心血突然休克而你能做的却不多。所以当业务量开始爬坡数据安全性和服务可用性成为必须考虑的问题时数据库的主从复制Master-Slave Replication就成了一个绕不开的基础设施。MariaDB作为MySQL的一个重要分支以其完全开源、性能优异和与MySQL的高度兼容性赢得了大量开发者和企业的青睐。它的主从复制机制本质上就是将一个数据库服务器主库上的数据变更实时地同步到一个或多个其他服务器从库上。这听起来简单但背后的价值巨大读写分离可以大幅提升查询性能数据备份提供了近乎实时的容灾能力高可用架构为故障切换提供了可能。无论是电商平台的订单库、内容管理系统的文章库还是物联网设备的数据汇聚点主从配置都是构建稳健数据层的基石。今天我就以一个老运维的视角带你从头到尾、掰开揉碎地走一遍MariaDB主从配置的全过程。我不会只给你干巴巴的命令我会告诉你每个参数为什么这么设操作中可能会在哪个阴沟里翻船以及如何验证你的配置真的在“干活”。无论你是正在为毕业设计搭建数据库环境的学生还是需要为团队业务部署生产级数据库的工程师这篇内容都能给你一份可以直接“抄作业”的实操指南。2. 核心原理与架构设计拆解在动手敲命令之前我们必须先搞清楚MariaDB主从复制到底是怎么“跑”起来的。理解了这个后面所有的配置和排错都会变得有章可循。2.1 二进制日志Binary Log复制的源头主从复制的核心在于主库的二进制日志binlog。你可以把它想象成数据库的“操作录像机”。每当主库上发生数据变更增、删、改或数据结构变更建表、改表这些事件Event都会被顺序记录到binlog文件中。它记录的不是最终的数据页而是导致数据变化的SQL语句Statement-Based或者行数据的变化Row-Based甚至是两者的混合Mixed。为什么是binlog因为它提供了数据变化的完整流水账。从库只需要拿到这份流水账在自己的数据库上“重放”一遍就能得到和主库一模一样的数据状态。这比直接拷贝数据文件要高效和灵活得多尤其是在需要持续同步的场景下。2.2 复制线程数据搬运工复制过程主要由三个线程协作完成Binlog Dump Thread主库当有从库连接上来时主库会为每个从库创建一个“binlog倾倒”线程。这个线程负责读取主库的binlog事件并将其发送给从库的I/O线程。I/O Thread从库从库的I/O线程负责连接到主库接收主库Binlog Dump Thread发来的binlog事件并将其写入到从库本地的中继日志Relay Log文件中。你可以把它理解成从库的“接收和暂存员”。SQL Thread从库从库的SQL线程负责读取本地的中继日志解析并执行其中记录的SQL事件从而让从库的数据与主库保持一致。它就是最终的“执行者”。这个“接收-存储-执行”的管道机制保证了即使在网络短暂中断时从库已经接收到的数据也不会丢失存储在中继日志里网络恢复后可以继续同步。2.3 复制模式的选择Statement vs. Row vs. Mixed这是配置前必须做的一个关键决策它直接影响复制的准确性、性能和兼容性。复制模式工作原理优点缺点适用场景基于语句 (SBR)记录执行的SQL语句。binlog文件小日志量少易于人工阅读。不确定性高。如UPDATE ... LIMIT 1若无ORDER BY主从可能更新不同行使用非确定性函数如NOW(),RAND()会导致主从不一致。早期版本默认模式现在已不推荐作为主要模式。基于行 (RBR)记录每行数据如何被修改修改前、后的行数据。最安全能保证主从数据的绝对一致性。对非确定性函数免疫。binlog文件体积大特别是批量更新时日志不可读是二进制格式。生产环境推荐模式。尤其适用于金融、交易等对数据一致性要求极高的场景。混合模式 (MIXED)默认使用SBR仅在可能引发不一致时自动切换为RBR。兼顾了文件大小和安全性。仍存在少量边界情况可能不如纯RBR可靠。MariaDB 10.0 的默认模式是一个不错的折中选择。我的经验与建议对于绝大多数生产环境我强烈建议直接使用binlog_format ROW。在存储成本已经非常低廉的今天数据的一致性和可靠性远比节省那点磁盘空间重要。曾经有一次我们因为使用了SBR一个包含RAND()的存储过程导致从库数据大面积错乱排查起来苦不堪言。切换到RBR后这类问题彻底消失。3. 实战部署一步步搭建主从环境理论清楚了我们进入实战环节。假设我们有两台全新的CentOS 7服务器Ubuntu/Debian步骤类似主要是包管理命令不同IP分别为192.168.1.100主和192.168.1.101从。目标是搭建一个一主一从的复制架构。3.1 环境准备与MariaDB安装首先在两台服务器上执行相同的初始化步骤。步骤1添加MariaDB官方仓库并安装CentOS 7自带的MariaDB版本可能较旧建议使用官方最新稳定版。# 在主库和从库服务器上执行 # 1. 安装必要的工具 sudo yum install -y epel-release sudo yum install -y wget # 2. 创建MariaDB的YUM仓库配置文件 sudo tee /etc/yum.repos.d/MariaDB.repo EOF # MariaDB 10.11 Stable Repository [mariadb] name MariaDB baseurl https://mirrors.aliyun.com/mariadb/yum/10.11/centos7-amd64 gpgkeyhttps://mirrors.aliyun.com/mariadb/yum/RPM-GPG-KEY-MariaDB gpgcheck1 EOF # 3. 安装MariaDB服务器和客户端 sudo yum install -y MariaDB-server MariaDB-client # 4. 启动服务并设置开机自启 sudo systemctl start mariadb sudo systemctl enable mariadb步骤2运行安全初始化脚本安装后运行mysql_secure_installation脚本设置root密码移除匿名用户、禁止root远程登录等。这是一个好习惯。sudo mysql_secure_installation按照提示操作即可。这里建议为root设置一个强密码并记住它。注意生产环境中绝对不要使用root账户进行应用连接和日常管理。后续所有操作为了演示清晰我们暂时使用root但在你的实际环境中请务必创建具有最小权限的专属复制账户和应用账户。3.2 主库Master配置详解现在我们开始配置主库192.168.1.100。步骤1编辑主库配置文件MariaDB的主配置文件通常是/etc/my.cnf或/etc/my.cnf.d/server.cnf。我们在这里进行关键配置。sudo vim /etc/my.cnf.d/server.cnf在[mysqld]配置段中添加或修改以下参数[mysqld] # 服务器唯一ID这是主从复制的“身份证”必须唯一 server-id 100 # 启用二进制日志并指定日志文件的前缀 log-bin mysql-bin # 设置二进制日志格式为ROW推荐生产环境使用 binlog_format ROW # 可选指定需要复制的数据库多个库用逗号隔开。不配置则默认复制所有库。 # binlog-do-db your_database_name # 可选指定不需要复制的数据库黑名单。与binlog-do-db二选一。 # binlog-ignore-db mysql, information_schema, performance_schema # 可选设置二进制日志的过期时间防止磁盘被占满单位天 expire_logs_days 7 # 可选控制每个binlog文件的最大大小单位字节达到后会自动滚动 max_binlog_size 100M关键参数解读server-id100我习惯用IP地址的最后一段作为ID只要保证主从不同即可。log-binmysql-bin开启了binlog文件将以mysql-bin.000001这样的序列命名。binlog_formatROW这是我们之前讨论后做的选择确保数据一致性。步骤2重启MariaDB服务使配置生效sudo systemctl restart mariadb步骤3创建用于复制的专属用户从库需要使用一个账户来连接主库并拉取binlog。我们创建一个权限明确的复制账号。登录MariaDB控制台sudo mysql -u root -p执行以下SQL语句-- 创建一个用户名为‘repl’允许从‘192.168.1.101’从库IP登录的用户 -- 密码请替换为强密码例如‘Repl123Secure’ CREATE USER repl192.168.1.101 IDENTIFIED BY YourStrongPassword123!; -- 授予该用户REPLICATION SLAVE权限。这个权限很小只能用于复制很安全。 GRANT REPLICATION SLAVE ON *.* TO repl192.168.1.101; -- 刷新权限使其立即生效 FLUSH PRIVILEGES;步骤4锁定数据库并查看主库状态为了获取一个一致的复制起点我们需要暂时阻止新的数据写入。-- 1. 锁定所有表为只读状态 FLUSH TABLES WITH READ LOCK; -- 2. 查看主库当前状态记录下File和Position的值从库连接时需要 SHOW MASTER STATUS;执行SHOW MASTER STATUS;后你会看到类似下面的输出------------------------------------------------------------ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | ------------------------------------------------------------ | mysql-bin.000001 | 328 | | | ------------------------------------------------------------请务必记下File(mysql-bin.000001) 和Position(328) 这两个值它们是复制的“坐标”。现在保持这个终端窗口打开不要退出也不要执行UNLOCK TABLES。我们快速去从库进行初始数据同步。3.3 从库Slave配置与初始同步切换到从库服务器192.168.1.101。步骤1编辑从库配置文件sudo vim /etc/my.cnf.d/server.cnf添加或修改以下参数[mysqld] # 服务器唯一ID必须与主库不同 server-id 101 # 可选启用中继日志 relay-log mysql-relay-bin # 可选防止从库被意外写入除非你明确需要级联复制 read_only 1read_only1会让从库处于只读模式超级用户如root除外这是一个重要的安全措施防止应用误操作写入了从库导致主从不一致。步骤2重启从库服务sudo systemctl restart mariadb步骤3进行主库数据全量备份与恢复这是搭建主从的关键一步让从库在开始增量同步前拥有和主库完全一致的数据快照。方法有很多最常用的是mysqldump。我们回到主库服务器打开另一个新的终端因为之前的终端还锁着表。在主库的新终端执行备份# 使用之前记录的root密码 mysqldump -u root -p --all-databases --master-data --single-transaction --flush-logs /tmp/full_backup.sql--all-databases备份所有库。--master-data2这个参数会在备份文件中以注释的形式记录下备份时刻主库的binlog文件和位置就是我们之前SHOW MASTER STATUS看到的信息。2表示以注释形式记录不会自动执行CHANGE MASTER。--single-transaction对InnoDB表进行一致性备份不会锁表对于MyISAM表无效。--flush-logs备份完成后滚动binlog方便后续定位。将备份文件传到从库scp /tmp/full_backup.sql root192.168.1.101:/tmp/现在回到从库服务器导入备份sudo mysql -u root -p /tmp/full_backup.sql步骤4解锁主库数据备份并传输完成后回到主库那个一直锁着表的终端解锁表允许主库继续正常写入。UNLOCK TABLES;步骤5配置从库连接主库登录从库的MariaDB控制台sudo mysql -u root -p执行CHANGE MASTER TO命令告诉从库主库在哪里用什么账号连接以及从哪个位置开始同步。STOP SLAVE; -- 先停止旧的复制进程如果是全新配置可忽略 CHANGE MASTER TO MASTER_HOST192.168.1.100, -- 主库IP MASTER_USERrepl, -- 刚才创建的复制账号 MASTER_PASSWORDYourStrongPassword123!, -- 复制账号密码 MASTER_PORT3306, -- 主库端口默认3306 MASTER_LOG_FILEmysql-bin.000001, -- 主库状态中的File MASTER_LOG_POS328, -- 主库状态中的Position MASTER_CONNECT_RETRY10; -- 连接失败后的重试间隔秒步骤6启动复制并检查状态START SLAVE; -- 启动复制进程检查从库复制状态SHOW SLAVE STATUS\G使用\G代替分号可以让结果以垂直格式显示更易读。3.4 验证与监控确保复制健康运行执行SHOW SLAVE STATUS\G后你需要重点关注以下几行Slave_IO_State: 显示当前I/O线程的状态Waiting for master to send event是正常状态。Slave_IO_Running:必须为Yes。表示I/O线程正在运行能从主库接收日志。Slave_SQL_Running:必须为Yes。表示SQL线程正在运行能执行中继日志。Seconds_Behind_Master:主从延迟秒数。理想情况下是0。如果是一个较小的正整数表示有轻微延迟如果是NULL通常表示复制进程有问题。Last_IO_Error/Last_SQL_Error: 显示最近的错误信息。正常应为空。如果Slave_IO_Running和Slave_SQL_Running都是Yes且Seconds_Behind_Master为0或一个稳定的小数值那么恭喜你主从复制已经成功搭建进行一次快速验证在主库上创建一个测试数据库和表并插入数据。CREATE DATABASE replication_test; USE replication_test; CREATE TABLE test_table (id INT, name VARCHAR(20)); INSERT INTO test_table VALUES (1, Master);在从库上查询看数据是否同步过来。USE replication_test; SELECT * FROM test_table;如果能查询到(1, ‘Master’)这条记录说明复制功能完全正常。4. 深度运维问题排查与性能调优配置成功只是第一步让主从复制长期稳定、高效地运行才是真正的挑战。下面分享一些我踩过坑后总结的运维经验。4.1 常见问题排查实录当SHOW SLAVE STATUS\G显示异常时不要慌按以下思路排查。问题1Slave_IO_Running Connecting 或 No这通常是网络或权限问题。检查网络在从库上ping 192.168.1.100telnet 192.168.1.100 3306。检查主库防火墙确保主库3306端口对从库IP开放。检查复制用户权限在主库上确认repl192.168.1.101用户存在且具有REPLICATION SLAVE权限。检查密码确认CHANGE MASTER TO中密码是否正确。查看错误信息SHOW SLAVE STATUS\G中的Last_IO_Error字段会给出具体错误。问题2Slave_SQL_Running No这通常是SQL线程执行中继日志中的事件时出错比如在主库上删除了一个不存在的表或者在从库上执行INSERT时发生了主键冲突。查看具体错误Last_SQL_Error字段会告诉你出错的SQL和原因。经典解决方法——跳过错误STOP SLAVE; SET GLOBAL sql_slave_skip_counter 1; -- 跳过1个事件 START SLAVE;警告sql_slave_skip_counter要谨慎使用它会让从库跳过主库的binlog事件可能导致数据不一致。仅当你知道这个错误可以忽略例如重复创建已存在的数据库时使用。更好的方法是找出不一致的根源并手动修复数据。数据不一致的根治方法如果跳过错误不能解决或者出现了严重不一致最彻底的方法是重建从库停止从库重新做主库的全量备份恢复到从库然后用新的binlog位置重新配置CHANGE MASTER TO。问题3Seconds_Behind_Master 值很大且持续增长这表示从库严重落后于主库。原因1从库服务器性能瓶颈。检查从库的CPU、内存、磁盘I/O使用率。可能是从库硬件配置远低于主库或者从库上运行了其他重负载服务。原因2网络延迟。主从服务器跨地域或网络质量差。原因3大事务。主库执行了一个耗时很长的更新比如不带索引的批量DELETE这个事务在binlog里是一个大事件从库需要同样长的时间来回放。原因4从库的串行回放。默认情况下从库的SQL线程是单线程的如果主库并发很高从库可能跟不上。可以考虑升级到MariaDB 10.0并开启并行复制。4.2 性能优化与高级配置1. 开启并行复制Multi-Threaded Slave对于写入频繁的主库单线程的SQL线程是主要瓶颈。MariaDB 10.0 支持基于组提交group commit的并行复制。在从库配置文件 (my.cnf) 中添加[mysqld] slave_parallel_threads 4 # 设置并行工作线程数通常设置为CPU核心数 slave_parallel_mode optimistic # 或 ‘conservative‘ ‘optimistic’ 模式更激进性能更好重启从库后观察SHOW SLAVE STATUS\G中的Exec_Master_Log_Pos追赶速度是否加快。2. 半同步复制Semi-Synchronous Replication默认的复制是异步的主库提交事务后不等从库确认就返回给客户端。如果主库宕机可能丢失已提交但未同步到任何从库的数据。 半同步复制要求主库提交事务时至少有一个从库确认收到了该事务的binlog事件主库才返回给客户端成功。在主库和从库的配置文件中都添加[mysqld] plugin_load_add semisync_master.so # 主库插件 plugin_load_add semisync_slave.so # 从库插件在主库和从库分别执行-- 主库 INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so’; SET GLOBAL rpl_semi_sync_master_enabled 1; -- 从库 INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so’; SET GLOBAL rpl_semi_sync_slave_enabled 1;然后重启从库的复制进程 (STOP SLAVE; START SLAVE;)。使用SHOW STATUS LIKE ‘Rpl_semi_sync%’;查看状态。3. 定期监控与维护脚本自动化是运维的好朋友。可以写一个简单的Shell脚本定期检查复制状态并报警。#!/bin/bash # check_replication.sh USER“root” PASS“your_password” SLAVE_STATUS$(mysql -u$USER -p$PASS -e “SHOW SLAVE STATUS\G”) IO_RUNNING$(echo “$SLAVE_STATUS” | grep “Slave_IO_Running:” | awk ‘{print $2}’) SQL_RUNNING$(echo “$SLAVE_STATUS” | grep “Slave_SQL_Running:” | awk ‘{print $2}’) SECONDS_BEHIND$(echo “$SLAVE_STATUS” | grep “Seconds_Behind_Master:” | awk ‘{print $2}’) if [[ “$IO_RUNNING” ! “Yes” ]] || [[ “$SQL_RUNNING” ! “Yes” ]]; then echo “CRITICAL: MySQL Replication is broken! IO: $IO_RUNNING, SQL: $SQL_RUNNING” | mail -s “MySQL Replication Alert” adminyourcompany.com fi if [[ $SECONDS_BEHIND -gt 300 ]]; then # 延迟超过5分钟报警 echo “WARNING: MySQL Replication lag is $SECONDS_BEHIND seconds” | mail -s “MySQL Replication Lag Alert” adminyourcompany.com fi将这个脚本加入crontab每5分钟执行一次。5. 生产环境进阶考量与架构延伸一个健壮的生产环境不会只满足于一主一从。随着业务发展你需要考虑更复杂的架构。5.1 一主多从架构这是最常见的扩展模式。一个主库多个从库。所有从库的配置方法都一样只需注意每个从库的server-id必须唯一。这种架构非常适合读多写少的场景可以将大量的查询请求如报表、数据分析、用户查询分摊到多个从库上极大减轻主库压力。负载均衡在应用和数据库之间可以使用HAProxy、LVS或F5等负载均衡器或者使用像MyCat、ShardingSphere这样的中间件来分发读请求到各个从库。5.2 主-主复制双主模式两个库互为主从都能接受写入。这听起来很美好可以实现写负载分担和更高可用性但极其危险除非你非常清楚自己在做什么。致命陷阱——数据冲突如果两个主库同时修改了同一行数据就会产生无法自动解决的冲突导致数据不一致。因此双主模式必须有严格的应用层分片规则例如库A只处理用户ID为偶数的写入库B只处理用户ID为奇数的写入从根源上避免交叉写入。配置要点除了互设server-id和互配复制账号必须在配置文件中开启自增ID偏移防止主键冲突。# 在服务器A上 auto_increment_increment 2 # 自增步长 auto_increment_offset 1 # 起始偏移 # 在服务器B上 auto_increment_increment 2 auto_increment_offset 2这样A库生成的ID是1,3,5,7…B库生成的是2,4,6,8…。5.3 级联复制Master - Slave - Slave当从库数量非常多时全部从主库拉取binlog会给主库带来巨大的网络和I/O压力。这时可以采用级联复制让一部分从库称为“中继从库”从主库同步其他从库再从这些“中继从库”同步。配置方法只需将第三级从库的MASTER_HOST指向第二级从库的IP并在第二级从库上为其创建复制账号即可。同时需要在第二级从库的配置中开启log_slave_updates1让它把从主库接收并执行过的事件也记录到自己的binlog中供下级从库读取。5.4 高可用方案与Keepalived/HAProxy结合主从复制本身不提供自动故障转移。如果主库宕机需要人工介入将一个从库提升为主库并修改应用配置。这个过程可能意味着分钟级别的服务中断。为了实现更高可用性可以引入Keepalived 虚拟IPVIP或HAProxy。Keepalived VIP在两台服务器主库和某个从库上安装Keepalived虚拟出一个VIP如192.168.1.10。应用始终连接这个VIP。Keepalived通过脚本检测主库健康状态一旦主库故障自动将VIP漂移到备库原从库并执行提升备库为主库的脚本。对应用透明切换速度快。HAProxy对于读多写少的场景可以将HAProxy部署在应用和数据库之间。写请求定向到主库读请求负载均衡到多个从库。当HAProxy检测到主库宕机可以配合脚本自动将从库提升为新主并更新HAProxy的配置。这种方式更灵活但应用需要配置读写分离。这些架构的搭建涉及更多组件和更复杂的运维建议在充分测试和理解后再上生产环境。主从复制是基石理解了它这些更高级的架构对你来说就不再是黑盒。
)
