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 目标库 < 文件 效果一致，同名表覆盖，新表创建。

三、关键结论

1. 导出操作 ：所有备份命令仅读取数据生成文件，不会修改原数据库，无覆盖风险。

2. 导入操作：

   • 若备份含表结构（CREATE TABLE）：同名表会被彻底覆盖（结构和数据全替换），新表会新增。
   • 若仅导入数据（无结构，如 -t 导出）：不会删除原有数据，但可能因主键冲突报错（需手动处理重复数据）。
   • 若导入前手动删除原表 / 库：则会完全重建，等同于 "全量覆盖"。

3. 避免误覆盖的建议：

   • 导入前备份原数据库；
   • 对仅需新增数据的场景，用 -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 → 清空原数据目录 → 复制合并后的全量备份 → 修复权限 → 启动服务。

四、恢复时对原有数据的影响

1. 全量恢复：

   • 若按上述步骤执行（清空原数据目录后复制备份），原有数据库会被完全覆盖（所有表结构和数据替换为备份内容）。
   • 若未清空原目录直接复制，可能因文件冲突导致恢复失败（建议严格按步骤操作）。

2. 增量恢复：

   • 最终恢复结果是 "全量备份 + 所有增量备份" 的合并状态，原有数据会被完全覆盖（等同于恢复到最后一次增量备份的时刻）。

3. 注意 ：xtrabackup 恢复是物理替换数据文件，一旦执行，原数据无法保留（除非提前备份），务必在恢复前确认备份有效性，并停止数据库服务。

总结

• 备份：全量 / 增量备份均不影响原数据，仅生成物理副本。
• 恢复 ：会完全覆盖原有数据库（基于备份内容重建），适合需要彻底恢复到某一时刻的场景。
• 优势：速度快、支持热备，适合 TB 级大库；缺点：恢复操作较复杂，且必须停止数据库服务才能完成恢复。

在数据库复制技术中，异步复制是指主库执行事务并提交后，无需等待从库确认接收或执行该事务，即可继续处理后续请求的复制模式。以下是对异步复制及其他复制类型的详细说明：

五、复制方式

一、异步复制（Asynchronous Replication）

• 核心特点：主库事务提交后立即返回，不等待从库响应；从库异步拉取主库的二进制日志并执行。
• 优势：主库性能损耗小，响应速度快。
• 劣势：主库故障时，可能存在部分事务未同步到从库，导致数据不一致。
• 典型场景：MySQL 传统主从复制默认采用异步复制。

二、其他复制类型

复制类型	核心原理	优势	劣势	典型场景
半同步复制（Semi-Synchronous Replication）	主库提交事务后，需等待至少一个从库确认接收（但不要求从库执行），才向客户端返回提交成功。	数据一致性优于异步复制，主库故障时丢失数据风险降低。	主库响应速度比异步慢，依赖从库网络和性能。	对数据一致性要求较高的业务（如金融交易）。
同步复制（Synchronous Replication）	主库提交事务后，需等待所有从库执行并提交事务，才向客户端返回提交成功。	数据一致性最强，主从数据完全实时一致。	主库性能损耗极大，响应速度极慢，从库故障会阻塞主库。	对数据一致性要求极高的核心业务（如银行核心系统）。
延迟复制（Delayed Replication）	从库故意延迟一定时间（如几小时）执行主库的事务，用于数据恢复（如误操作后回滚）。	可应对主库误操作，提供数据回滚的时间窗口。	从库数据实时性差，无法用于读写分离。	数据备份、误操作恢复场景。
多源复制（Multi-Source Replication）	一个从库同时从多个主库同步数据（MySQL 8.0 及以上支持）。	可集中多个主库的数据，简化数据整合。	配置和管理复杂，对从库性能要求高。	数据仓库、多业务系统数据汇总场景。

三、补充说明

• 实际应用中，半同步复制是异步和同步的折中方案，被广泛用于对一致性和性能平衡要求较高的场景。
• MySQL 的 组复制（Group Replication） 属于同步复制的一种，基于 Paxos 协议实现多节点间的强一致性，常用于高可用集群（如 MGR）。