目录
mysql之备份
| 备份方式 |
定义 |
工具/方法 |
优点 |
缺点 |
| 物理备份 |
直接复制数据库的数据文件和日志文件。 |
mysqldump（不推荐），文件系统级别复制 |
备份速度快，恢复迅速；可以备份整个数据库。 |
需要停机或使用锁定机制；备份文件较大，恢复可能较复杂。 |
| 逻辑备份 |
导出数据库的数据和结构为文本文件（如 SQL 文件）。 |
mysqldump、mysqlpump |
备份文件易于管理和恢复；支持选择性备份特定表或数据。 |
备份和恢复速度较慢；大数据量备份文件可能非常大。 |
| 增量备份 |
仅备份自上次备份以来发生更改的数据。 |
mysqlbinlog（解析二进制日志） |
节省存储空间和备份时间；备份体积小。 |
需要定期进行全备份；恢复过程复杂。 |
| 差异备份 |
备份自上次全备份以来发生更改的数据。 |
mysqlbinlog（结合全备份使用） |
恢复时只需最后一个全备份和最近的差异备份；备份文件较小。 |
差异备份文件逐渐增大；恢复过程可能较复杂。 |
| 快照备份 |
利用操作系统或存储系统提供的快照功能记录数据库状态。 |
LVM 快照、ZFS 快照、存储设备快照 |
快速备份和恢复；无需停机；支持恢复到快照创建时的状态。 |
快照管理可能复杂；可能需要特定的存储系统支持。 |
|
|
|
|
|
- 物理备份 适合需要快速备份和恢复的场景，但需要处理大文件。
- 逻辑备份 更适合需要迁移和选择性备份的场景，但备份和恢复速度较慢。
- 增量备份 和 差异备份 适合需要节省存储和时间的场景，但恢复过程可能较为复杂。
- 快照备份 提供快速备份和恢复的能力，但可能需要特定的存储系统支持。
增量和差异备份的区别：
要恢复数据库，增量备份需要一次全量+前面每次增量备份；差异备份需要一次全量+一次差异备份。
热备和冷备的区别：
热备不需要停机
定时备份：可以用cron定时运行备份语句脚本来实现定时备份
mysqldump
mysqldump是mysql自带的备份工具，常用于逻辑备份。
备份的格式有两种：
常用参数：
- 连接参数，如
-u指定连接用户
- 指定备份范围，如
--all-databases导出所有数据库
- 指定备份内容，如
--no-data只导出表结构
- 个性化设定，如
--default-character-set指定字符集
- 性能参数，如
--single-transaction 在事务中导出数据，避免锁定表，适合 InnoDB 存储引擎。此参数会保证导出过程中一直是以最开始的数据来导出的
命令格式举例：
- 将数据库database1和database2备份到backup.sql
mysqldump -u root -p -B database1 database2 > backup.sql
- 将备份文件导入到数据库（恢复备份）
mysql -u root -p database_name < backup.sql
物理备份
XtraBackup 和 innobackupex 是常用的开源物理备份工具，专门用于 MySQL、MariaDB 和 Percona Server。
- XtraBackup：Percona 提供的开源工具，主要用于热备份（不需要停机）。它可以备份 InnoDB 和 XtraDB 引擎的表。
- innobackupex：基于 XtraBackup 的一个脚本，封装了 XtraBackup 的核心功能，支持更多选项，如备份 MyISAM 表、系统文件等。该脚本已经被 Percona 放弃，但在早期版本中依然广泛使用。
mysql主从复制
实现过程
- 启动binlog，是支持主从复制的前提
- 创建复制的用户，并赋权
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'%';
- 从库启用中继日志，设置主库信息
- 从库启动复制进程
start slave
- 检查复制状态
show slave status\G，需要需要 SUPER或 REPLICATION CLIENT权限才能查看
大致是：
binlog（主库）-> relaylog（从库） -> 数据变更到数据库（从库）
show slave status
|
|
|
|
| Slave_IO_State |
当前从服务器 I/O 线程的状态 |
Waiting for master to send event |
Connecting to master、Failed |
|
|
|
|
| Master_Host |
主服务器的主机名或 IP 地址 |
正确的主机名或 IP 地址 |
错误的主机名或 IP 地址 |
|
|
|
|
| Master_User |
用于连接主服务器的用户名 |
正确的用户名 |
错误的用户名 |
|
|
|
|
| Master_Port |
主服务器的端口号 |
正确的端口号（通常是 3306） |
错误的端口号 |
|
|
|
|
| Connect_Retry |
从服务器在尝试重新连接主服务器时的等待时间（秒） |
正常的重试时间（如 60 秒） |
重试时间异常或不合理（如 0 秒） |
|
|
|
|
| Master_Log_File |
主服务器当前使用的二进制日志文件名 |
正确的日志文件名 |
文件名不匹配或文件丢失 |
|
|
|
|
| Read_Master_Log_Pos |
从服务器读取主服务器二进制日志的当前位置 |
正确的日志位置 |
错误的日志位置 |
|
|
|
|
| Relay_Log_File |
从服务器的当前中继日志文件名 |
正确的中继日志文件名 |
文件名不匹配或文件丢失 |
|
|
|
|
| Relay_Log_Pos |
从服务器中继日志的当前位置 |
正确的位置 |
错误的位置 |
|
|
|
|
| Relay_Master_Log_File |
从服务器正在处理的主服务器二进制日志文件名 |
与 Master_Log_File 一致 |
不一致或文件丢失 |
|
|
|
|
| Relay_Master_Log_Pos |
从服务器已应用的主服务器日志的位置 |
正确的位置 |
不一致或位置丢失 |
|
|
|
|
| Slave_IO_Running |
从服务器 I/O 线程的状态 |
Yes |
No |
|
|
|
|
| Slave_SQL_Running |
从服务器 SQL 线程的状态 |
Yes |
No |
|
|
|
|
| Last_Errno |
最后一次错误的错误号 |
0 |
非零错误号 |
|
|
|
|
| Last_Error |
最后一次错误的详细信息 |
NULL |
错误信息描述 |
|
|
|
|
| Skip_Counter |
当前跳过的事件计数器 |
0 |
大于 0，表示跳过事件 |
|
|
|
|
| Exec_Master_Log_Pos |
从服务器已应用到本地的主服务器二进制日志的位置 |
正确的位置 |
不一致或位置丢失 |
|
|
|
|
| Relay_Log_Space |
中继日志的总大小（字节） |
合理的日志大小（如 1 MB、10 MB） |
过大或过小 |
|
|
|
|
| Until_Condition |
用于定义复制停止条件的设置 |
NONE |
非正常值 |
|
|
|
|
| Until_Log_File |
当 Until_Condition 设置为 MASTER_LOG_FILE 时的日志文件名 |
正确的日志文件名 |
错误的文件名 |
|
|
|
|
| Until_Log_Pos |
当 Until_Condition 设置为 MASTER_LOG_POS 时的位置 |
正确的位置 |
错误的位置 |
|
|
|
|
| Master_SSL_Allowed |
是否允许 SSL 加密连接到主服务器 |
Yes |
No |
|
|
|
|
| Master_SSL_CA_File |
用于 SSL 连接的 CA 证书文件 |
正确的 CA 证书文件路径 |
错误的文件路径 |
|
|
|
|
| Master_SSL_CA_Path |
用于 SSL 连接的 CA 证书目录 |
正确的 CA 证书目录路径 |
错误的目录路径 |
|
|
|
|
| Master_SSL_Cert |
用于 SSL 连接的证书文件 |
正确的证书文件路径 |
错误的证书文件路径 |
|
|
|
|
| Master_SSL_Crl |
用于 SSL 连接的证书撤销列表文件 |
正确的证书撤销列表文件路径 |
错误的证书撤销列表文件路径 |
|
|
|
|
| Master_SSL_Crl_Path |
用于 SSL 连接的证书撤销列表目录 |
正确的证书撤销列表目录路径 |
错误的目录路径 |
|
|
|
|
| Master_SSL_Key |
用于 SSL 连接的密钥文件 |
正确的密钥文件路径 |
错误的密钥文件路径 |
|
|
|
|
| Seconds_Behind_Master |
从服务器落后于主服务器的时间（秒） |
0 或小于预期延迟时间 |
较大的延迟时间，或 NULL 表示无法读取 |
解读
- Slave_IO_Running 和 Slave_SQL_Running 都为 “Yes” 表示复制正常运行。如果任一线程为 “No”，需要检查相关日志以确定原因。
- Master_Log_File 和 Read_Master_Log_Pos 显示了从服务器当前读取主服务器日志的位置。确保这些位置不断前进而不是停滞不前。
- Seconds_Behind_Master 显示从服务器相对于主服务器的延迟。如果这个值过大，可能意味着从服务器处理数据的速度较慢或者网络延迟较高。
- Last_Errno 和 Last_Error 用于诊断复制过程中出现的问题。任何错误信息都应该被调查和修复。
读写分离
和主从复制有关联的一个概念是：读写分离。
简单来说，就是倾向于将增删改操作由主库执行，由从库执行读操作。然后数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。主要目的是提供数据库的并发能力。
但是读写分离的能力不是mysql自身提供的，一般需要通过技术手段实现，如中间件（位于客户端和服务端之间，如mysql-proxy, Atlas, Amoeba, Mycat）或代码层实现读写语句分发到不同的数据库。
GTID复制
另一个和主从复制有关的概念：GTID (global transaction identifier) 全局事务标识，是 MySQL 5.6 版本引入的一种用于标识事务的机制。相当于给每个事务加了一个全局唯一（在主库和从库中都是唯一的）的身份证号，方便识别和追踪。有了GTID复制机制，进化了普通的主从复制，可以简化主从复制的管理和提高数据一致性。
GTID的格式：
一般是source_id:transaction_id，source_id一般是主库的server_uuid，transaction_id是已提交事务的一个序列号（从1开始自增，由GTID_NEXT控制下一个GTID）。GTID存储在mysql的 gtid_executed的表中。
使用GTID的主从复制过程：
- 主库开启GTID机制
SET GLOBAL gtid_mode = ON; SET GLOBAL enforce_gtid_consistency = ON;
- 每个提交的事务都会被标记上唯一的GTID，事务和GTID都会被写入binlog
- binlog传输到slave，并存储到slave的relaylog后，读取这个GTID的这个值设置gtid_next变量，即告诉Slave，下一个要执行的GTID值。
- sql线程从relay log中获取GTID，然后对比slave端的binlog是否有该GTID，如果有说明该GTID的事务已经执行，slave会忽略。如果没有记录，slave会执行该GTID的事务，在执行前会检查其他session持有该GTID，确保该GTID的事务不会被重复执行，并记录该GTID到自身的binlog。
因此：通过 GTID，主从复制不再依赖于具体的 binlog 文件名和位置点，而是通过全局唯一的 GTID 来标识和追踪事务