Mysql的数据备份和高可用
一、导出命令（备份）
1. mysqldump 逻辑备份（常用）
| 命令示例 | 作用 | 覆盖风险（导出时无影响，仅备份） |
|---|---|---|
mysqldump -u用户名 -p 数据库名 > 备份文件.sql | 导出单个数据库的结构 + 数据 | 导出操作不影响原数据库，仅生成备份文件 |
mysqldump -u用户名 -p --databases 库1 库2 > 备份文件.sql | 导出多个数据库（含 CREATE DATABASE 和 USE 语句） | 同上，仅备份，不影响原数据 |
mysqldump -u用户名 -p --all-databases > 全量备份.sql | 导出所有数据库 | 同上 |
mysqldump -u用户名 -p -d 数据库名 表名 > 结构备份.sql | 仅导出表结构（-d 参数） | 仅备份结构，不影响原数据 |
mysqldump -u用户名 -p -t 数据库名 表名 > 数据备份.sql | 仅导出表数据（-t 参数） | 仅备份数据，不影响原数据 |
2. mysqlbinlog 导出二进制日志（增量备份）
| 命令示例 | 作用 | 覆盖风险 |
|---|---|---|
mysqlbinlog 二进制日志文件 > 增量备份.sql | 导出指定 binlog 中的操作日志 | 仅导出日志，不影响原数据 |
二、导入命令（恢复）
1. 从 SQL 文件导入
| 命令示例 | 作用 | 对原有表结构和数据的影响 |
|---|---|---|
mysql -u用户名 -p 目标数据库名 < 备份文件.sql | 导入 SQL 文件到指定数据库 | ① 若备份含表结构：- 同名表会被覆盖（默认先 DROP TABLE 再重建，结构和数据全替换）；- 新表会被创建。② 若仅含数据（-t 导出）：- 同名表会执行 INSERT，可能因主键冲突报错（不会删除原有数据，需手动处理）。 |
mysql -u用户名 -p < 含CREATE DATABASE的备份.sql（如 -B 导出的文件） | 导入时自动创建数据库并对应导入 | ① 若数据库已存在：不新建库，但库内同名表被覆盖，其他表保留；② 若数据库不存在：新建库并导入所有表。 |
注意区别
| 对比项 | 加 --databases（-B） | 不加 --databases |
|---|---|---|
| 备份文件内容 | 包含 CREATE DATABASE IF NOT EXISTS 库1 语句，以及每个库的 USE 库1; 语句。 | 不包含 CREATE DATABASE 和 USE 语句，仅包含两个库中所有表的 CREATE TABLE 和数据（INSERT）。 |
| 导出的 “范围” | 明确以 “数据库” 为单位导出，保留库级别的元信息。 | 相当于 “导出库 1 和库 2 中的所有表”，但不保留库本身的创建信息。 |
| 导入时的目标 | 导入时无需指定目标库，会自动创建库 1、库 2（若不存在），并将表导入对应库中。 | 导入时必须手动指定一个目标库（如 mysql -u用户名 -p 目标库 < 备份文件.sql），否则会报错或导入到默认库（如 test）。 |
| 对原有库的影响 | 若库 1 / 库 2 已存在，导入时会覆盖同名表，不影响其他表。 | 所有表会被导入到指定的 “目标库” 中，若目标库中存在同名表，会被覆盖；原库 1 / 库 2 本身不受影响（除非目标库就是库 1 / 库 2）。 |
2. 二进制日志增量导入
| 命令示例 | 作用 | 影响 |
|---|---|---|
mysql -u用户名 -p < 增量备份.sql | 执行 binlog 中的操作（如 INSERT/UPDATE/DELETE） | 重复执行日志中的操作，可能导致数据重复或覆盖（需严格按顺序导入，避免重复）。 |
3. source 命令（MySQL 客户端内执行）
| 命令示例 | 作用 | 影响 |
|---|---|---|
mysql> use 目标库;mysql> source /路径/备份文件.sql; | 同文件导入，适合客户端内操作 | 与 mysql -u -p 目标库 < 文件 效果一致，同名表覆盖，新表创建。 |
三、关键结论
导出操作：所有备份命令仅读取数据生成文件，不会修改原数据库，无覆盖风险。
导入操作：
- 若备份含表结构（
CREATE TABLE）：同名表会被彻底覆盖（结构和数据全替换），新表会新增。 - 若仅导入数据（无结构，如
-t导出）：不会删除原有数据，但可能因主键冲突报错（需手动处理重复数据）。 - 若导入前手动删除原表 / 库：则会完全重建，等同于 “全量覆盖”。
- 若备份含表结构（
避免误覆盖的建议：
- 导入前备份原数据库；
- 对仅需新增数据的场景，用
-t导出数据，导入时先处理重复键（如INSERT IGNORE或REPLACE）； - 生产环境建议先在测试库验证导入效果。
xtrabackup 是 Percona 推出的一款高性能 MySQL 物理备份工具（支持 MySQL、MariaDB、Percona Server），相比 mysqldump 逻辑备份，它更适合大数据库，支持热备份（不锁表），且备份 / 恢复速度更快。以下是其备份、恢复命令及对数据的影响总结：
一、xtrabackup 核心特点
- 物理备份：直接复制数据文件（如
.ibd、frm等），而非 SQL 语句，备份与恢复效率更高。 - 支持热备：备份时不阻塞读写操作（InnoDB 表），MyISAM 表仍需锁表。
- 支持全量 / 增量备份：增量备份仅备份变化的数据页，节省空间和时间。
二、备份命令（全量 / 增量）
1. 全量备份
# 基本语法
xtrabackup --user=用户名 --password=密码 --backup --target-dir=备份目录# 示例：备份所有数据库到 /backup/full_20251026
xtrabackup --user=root --password=123456 --backup --target-dir=/backup/full_20251026# 注意：如果mysql是自定义安装的情况下
xtrabackup --defaults-file=/usr/local/mysql/my.cnf --user=root --password='admin123' --backup --target-dir=/backup/full_20251026# 远程备份
xtrabackup --defaults-file=/usr/local/mysql/etc/my.cnf --user=root --password='root' --host=127.0.0.1 --compress-threads=8 --backup --stream=xbstream --parallel=4 | ssh 10.0.0.73 "gzip > /test/mysqlback.xb.gz"- 作用：备份 MySQL 所有数据文件（含表结构、数据、索引等），生成完整的物理副本。
- 对原数据影响：仅读取数据，不修改原库，无覆盖风险。
2. 增量备份（基于全量备份）
# 第一次增量备份（基于全量备份）
xtrabackup --user=root --password=123456 --backup \
--target-dir=/backup/inc_20251027 \
--incremental-basedir=/backup/full_20251026 # 指定全量备份目录# 第二次增量备份（基于上一次增量备份）
xtrabackup --user=root --password=123456 --backup \
--target-dir=/backup/inc_20251028 \
--incremental-basedir=/backup/inc_20251027 # 指定上一次增量备份目录
- 作用：仅备份自
--incremental-basedir对应备份后变化的数据页。 - 对原数据影响：无影响，仅读取变化数据。
三、恢复命令（全量 / 增量）
恢复前需先 “准备” 备份文件（合并增量备份、同步日志等），再复制到数据库目录。
1. 全量恢复步骤
步骤 1：准备全量备份（确保数据一致性）
xtrabackup --prepare --target-dir=/backup/full_20251026
- 作用：将备份中的未提交事务回滚，已提交事务应用到数据文件，生成可恢复的一致性备份。
步骤 2：停止 MySQL 并清空原数据目录
systemctl stop mysqld # 停止服务
rm -rf /var/lib/mysql/* # 清空原数据（谨慎！确保备份有效）
步骤 3：复制备份文件到数据目录
xtrabackup --copy-back --target-dir=/backup/full_20251026
- 作用：将准备好的全量备份文件复制到 MySQL 数据目录（默认
/var/lib/mysql）。
步骤 4：修复权限并启动服务
chown -R mysql:mysql /var/lib/mysql # 恢复数据目录权限
systemctl start mysqld
2. 增量恢复步骤（基于全量 + 增量备份）
步骤 1：准备全量备份（--apply-log-only 避免回滚未提交事务，留待增量合并）
xtrabackup --prepare --apply-log-only --target-dir=/backup/full_20251026
步骤 2：合并第一次增量备份到全量备份
xtrabackup --prepare --apply-log-only --target-dir=/backup/full_20251026 \
--incremental-dir=/backup/inc_20251027
步骤 3：合并第二次增量备份（最后一次增量无需 --apply-log-only）
xtrabackup --prepare --target-dir=/backup/full_20251026 \
--incremental-dir=/backup/inc_20251028
步骤 4：后续步骤同全量恢复
停止 MySQL → 清空原数据目录 → 复制合并后的全量备份 → 修复权限 → 启动服务。
四、恢复时对原有数据的影响
全量恢复：
- 若按上述步骤执行（清空原数据目录后复制备份），原有数据库会被完全覆盖（所有表结构和数据替换为备份内容）。
- 若未清空原目录直接复制，可能因文件冲突导致恢复失败（建议严格按步骤操作）。
增量恢复：
- 最终恢复结果是 “全量备份 + 所有增量备份” 的合并状态，原有数据会被完全覆盖（等同于恢复到最后一次增量备份的时刻）。
注意：xtrabackup 恢复是物理替换数据文件，一旦执行，原数据无法保留（除非提前备份），务必在恢复前确认备份有效性，并停止数据库服务。
总结
- 备份：全量 / 增量备份均不影响原数据，仅生成物理副本。
- 恢复：会完全覆盖原有数据库（基于备份内容重建），适合需要彻底恢复到某一时刻的场景。
- 优势：速度快、支持热备，适合 TB 级大库；缺点：恢复操作较复杂，且必须停止数据库服务才能完成恢复。
在数据库复制技术中，异步复制是指主库执行事务并提交后，无需等待从库确认接收或执行该事务，即可继续处理后续请求的复制模式。以下是对异步复制及其他复制类型的详细说明：
五、复制方式
一、异步复制（Asynchronous Replication）
- 核心特点：主库事务提交后立即返回，不等待从库响应；从库异步拉取主库的二进制日志并执行。
- 优势：主库性能损耗小，响应速度快。
- 劣势：主库故障时，可能存在部分事务未同步到从库，导致数据不一致。
- 典型场景：MySQL 传统主从复制默认采用异步复制。
二、其他复制类型
| 复制类型 | 核心原理 | 优势 | 劣势 | 典型场景 |
|---|---|---|---|---|
| 半同步复制（Semi-Synchronous Replication） | 主库提交事务后，需等待至少一个从库确认接收（但不要求从库执行），才向客户端返回提交成功。 | 数据一致性优于异步复制，主库故障时丢失数据风险降低。 | 主库响应速度比异步慢，依赖从库网络和性能。 | 对数据一致性要求较高的业务（如金融交易）。 |
| 同步复制（Synchronous Replication） | 主库提交事务后，需等待所有从库执行并提交事务，才向客户端返回提交成功。 | 数据一致性最强，主从数据完全实时一致。 | 主库性能损耗极大，响应速度极慢，从库故障会阻塞主库。 | 对数据一致性要求极高的核心业务（如银行核心系统）。 |
| 延迟复制（Delayed Replication） | 从库故意延迟一定时间（如几小时）执行主库的事务，用于数据恢复（如误操作后回滚）。 | 可应对主库误操作，提供数据回滚的时间窗口。 | 从库数据实时性差，无法用于读写分离。 | 数据备份、误操作恢复场景。 |
| 多源复制（Multi-Source Replication） | 一个从库同时从多个主库同步数据（MySQL 8.0 及以上支持）。 | 可集中多个主库的数据，简化数据整合。 | 配置和管理复杂，对从库性能要求高。 | 数据仓库、多业务系统数据汇总场景。 |
三、补充说明
- 实际应用中，半同步复制是异步和同步的折中方案，被广泛用于对一致性和性能平衡要求较高的场景。
- MySQL 的 组复制（Group Replication） 属于同步复制的一种，基于 Paxos 协议实现多节点间的强一致性，常用于高可用集群（如 MGR）。