Mysql--基础知识点--101--在线扩容

MySQL 不停机扩容增加从库完整方案核心目标在不停机的前提下为现有主库增加一个或多个从库以分担读压力或提供高可用。关键路径获得一致性备份 → 恢复到新从库 →配置并启动主从复制→ 验证同步状态。以下分别介绍使用mysqldump和Percona XtraBackup两种方式的完整操作并说明各自适用场景。一、使用mysqldump的逻辑备份方案✅ 适用场景数据量较小建议 50 GB备份时间可接受。环境简单不想安装额外工具MySQL 自带。跨版本、跨平台迁移SQL 兼容性好。以 InnoDB 表为主--single-transaction依赖事务。 完整操作步骤1. 主库创建复制账号CREATEUSERrepl%IDENTIFIEDBYstrong_password;GRANTREPLICATIONSLAVEON*.*TOrepl%;FLUSHPRIVILEGES;2. 获取一致性快照不停机mysqldump --single-transaction --master-data2-uroot-p\--all-databases--triggers--routines--eventsbackup.sql--master-data2在备份文件注释中记录 binlog 文件名和位置稍后用于主从复制。3. 传输备份文件到新从库scpbackup.sql usernew_slave:/tmp/4. 在新从库上恢复数据mysql-uroot-p/tmp/backup.sql5. 配置从库并启动主从复制关键步骤编辑从库my.cnf设置唯一server-idserver-id 2 # 不能与主库或其他从库重复 read_only 1 # 从库只读防止写操作重启 MySQL 使配置生效。进入从库 MySQL执行-- 从 backup.sql 文件头部找到类似这样的注释-- CHANGE MASTER TO MASTER_LOG_FILEmysql-bin.000123, MASTER_LOG_POS45678;CHANGE MASTERTOMASTER_HOST主库IP,MASTER_USERrepl,MASTER_PASSWORDstrong_password,MASTER_LOG_FILEmysql-bin.000123,MASTER_LOG_POS45678;STARTSLAVE;验证复制状态SHOWSLAVESTATUS\G确保Slave_IO_Running和Slave_SQL_Running均为Yes且Seconds_Behind_Master逐渐变为 0。没有主从复制扩容就没有完成—— 从库只是一份静态备份无法实时同步主库的新写入。二、使用 Percona XtraBackup 的物理备份方案✅ 适用场景数据量巨大数百 GB ~ TB 级mysqldump太慢或影响线上。需要快速备份和恢复物理备份速度远快于逻辑备份。需要增量备份、流式备份、压缩等高级功能。绝大多数表为 InnoDB对 MyISAM 支持较弱。 完整操作步骤1. 主库创建复制账号同上2. 执行全量备份不停机xtrabackup--backup--target-dir/data/backup\--userroot--passwordpassword--host主库IP备份完成后/data/backup目录下会生成xtrabackup_binlog_info文件内容如下mysql-bin.000123 45678这个文件记录了备份结束时主库的 binlog 位置是建立主从复制的关键。3. 准备Prepare备份 – 前滚 回滚xtrabackup--prepare--target-dir/data/backup这一步使备份文件达到全局一致性状态相当于mysqldump的快照。4. 传输备份文件到新从库rsync-av/data/backup/ usernew_slave:/data/backup/5. 在新从库上恢复数据systemctl stop mysqlrm-rf/var/lib/mysql/*# 清空原数据目录注意先备份xtrabackup --copy-back --target-dir/data/backupchown-Rmysql:mysql /var/lib/mysql systemctl start mysql6. 配置从库并启动主从复制关键步骤编辑从库my.cnf设置唯一server-id同上。重启 MySQL。进入从库 MySQL执行-- 从 xtrabackup_binlog_info 文件获取 binlog 文件名和位置CHANGE MASTERTOMASTER_HOST主库IP,MASTER_USERrepl,MASTER_PASSWORDstrong_password,MASTER_LOG_FILEmysql-bin.000123,MASTER_LOG_POS45678;STARTSLAVE;验证复制状态SHOW SLAVE STATUS\G确保两个Running线程为Yes。同样必须启动主从复制从库才能持续同步主库的增量数据实现真正的“扩容”。三、两种方式对比与选型总结维度mysqldumpPercona XtraBackup备份原理逻辑导出 SQL物理拷贝数据文件 redo log是否需要前滚/回滚不需要MVCC 直接提供一致快照需要--prepare阶段备份速度慢尤其大表快恢复速度慢重放 SQL快直接拷贝文件对主库影响较轻有查询负载较轻有 IO 负载是否支持增量备份否是额外依赖无需安装 Percona XtraBackup主从复制关键信息从backup.sql头部注释获取 binlog 位置从xtrabackup_binlog_info获取典型数据量 50 GB 200 GB决策建议小数据量、简单环境→mysqldump大数据量、需要快速恢复或增量备份→XtraBackup云 RDS 环境→ 使用云厂商自带的快照 只读实例功能无需手动操作四、重要提醒扩容 ≠ 仅仅拷贝数据很多初次操作的人容易忽略的一点是把备份恢复到新服务器只是第一步如果不配置并启动主从复制这个新实例只是一个静态的历史快照无法分担任何实时读流量也无法作为高可用备机。因此在两种方案的步骤中我们都明确列出了“配置并启动主从复制”这一关键动作并强调必须验证SHOW SLAVE STATUS状态正常。只有这样新增加的从库才能真正融入现有架构实现不停机扩容的目标。四、核心原理回顾结合之前解释mysqldump --single-transaction开启长事务读取一致性快照备份期间的新写入记录在 binlog 中从库从快照位置开始回放。XtraBackup拷贝数据文件时同时拷贝 redo log--prepare阶段执行前滚重放已提交事务和回滚撤销未提交事务使备份文件成为一致性快照。两种方式均实现了不停机扩容区别在于底层机制和性能。问为什么使用mysqldump不需要前滚而使用Percona XtraBackup需要回滚这个问题触及了两种备份工具最核心的设计差异逻辑备份 vs 物理备份以及它们如何解决“不一致”问题。一、为什么mysqldump不需要前滚/回滚mysqldump --single-transaction的工作原理开启一个长事务隔离级别为REPEATABLE READ。利用 InnoDB 的MVCC多版本并发控制该事务读取到的数据是事务开始那一刻的数据库快照。在备份过程中主库的其他写入操作包括已提交和未提交的事务不会影响该事务读取的内容。mysqldump读出的每一行数据都来自快照天然就是一致的、已提交的。最终生成的.sql文件中所有数据都是备份开始时刻已提交的数据没有未提交的事务需要回滚也不需要前滚来追赶后续写入。结论mysqldump通过 MVCC 直接从 InnoDB 的历史版本中获得了“已经是一致”的数据因此不需要额外的前滚或回滚步骤。注意如果表是 MyISAM不支持事务--single-transaction无效此时需要--lock-tables来获得一致备份但那会锁表不是真正的“不停机”。二、为什么Percona XtraBackup需要前滚 回滚XtraBackup 是物理备份直接拷贝 InnoDB 的.ibd数据文件。这个过程会遇到两个问题问题说明后果页面拷贝时间不同数据文件很大拷贝需要时间。页面 A 在 t1 时刻被拷贝页面 B 在 t2 时刻被拷贝。如果 t1 到 t2 之间发生了写入那么 A 和 B 属于不同时间点整个文件不一致。直接启动会看到逻辑错误比如外键不匹配。未完成的事务拷贝某个页面时可能正好有一个事务在修改它页的一部分是新值一部分是旧值或者页面中有未提交事务的修改。数据文件中包含未提交的事务直接启动会读到脏数据。为了得到一致性备份即等同于某个时间点的已提交数据快照XtraBackup 必须拷贝数据文件的同时拷贝 redo log记录备份期间所有修改。备份完成后执行--prepare阶段前滚Roll Forward将 redo log 中所有已提交事务的修改重新应用到数据文件使数据文件“追到”备份结束那一刻。回滚Roll Back将 redo log 中所有未提交事务的修改撤销使数据文件中只保留已提交的修改。最终得到的数据文件与mysqldump快照一样是某个时间点的已提交事务的一致性快照。三、核心差异总结表维度mysqldump --single-transactionPercona XtraBackup备份方式逻辑读取生成 SQL物理拷贝数据文件一致性来源利用 MVCC 直接读取历史快照通过拷贝 redo log 后人工前滚回滚来构造快照是否需要前滚❌ 不需要✅ 需要重放已提交事务是否需要回滚❌ 不需要✅ 需要撤销未提交事务备份期间是否看到未提交数据否MVCC 隔离是直接读文件会读到脏页最终数据是否包含未提交事务否经过回滚后否四、类比理解mysqldump像一个摄影师在某个瞬间按下快门开启事务拍下的照片快照里的人和物都是那个瞬间的样子。即使之后有人走动写入也不会影响这张照片。XtraBackup像一个考古学家把整个遗址的泥土数据文件一块块挖出来但挖的过程可能弄乱地层。然后他根据一张记录日志redo log把挖出来的泥土重新整理把后来堆上去的前滚放回原位把不该出现的临时痕迹回滚清除掉最后还原出遗址在某个时刻的完整状态。五、常见误区澄清“既然 XtraBackup 要回滚那 mysqldump 备份期间如果有未提交的长事务快照里会包含它吗”不会。MVCC 保证--single-transaction只能看到在事务开始时已经提交的数据。备份期间任何未提交甚至后来提交的事务对备份事务都是不可见的。“XtraBackup 的前滚会不会把备份期间新写入的数据弄丢”不会。前滚的目的是把备份文件本身包含的数据更新到最新一致状态而不是去覆盖主库。最终从库会从备份文件记录的 binlog 位置开始同步备份期间的新写入会通过 binlog 重放过来不会丢失。一句话答案mysqldump利用数据库自身的 MVCC 直接获得了已提交的一致性快照所以不需要额外处理而XtraBackup物理拷贝时会包含未提交事务和不同时间点的页面必须通过重放 redo log前滚已提交、回滚未提交来人工构造出一致性快照。