Part01-基础概念与理论知识
1.1 灾备概述
灾备（灾难备份与恢复）是指为了应对自然灾害、人为失误、硬件故障等导致的系统中断或数据丢失，而采取的一系列预防和恢复措施。MySQL灾备是确保MySQL数据库在灾难发生时能够快速恢复的重要手段。风哥教程参考MySQL官方文档Backup and Recovery部分的相关内容。更多视频教程www.fgedu.net.cn
灾备是指通过建立和维护备用系统，确保在主系统发生灾难时，能够快速切换到备用系统，保证业务的连续性。
# 灾备的目标
1. 减少数据丢失：确保在灾难发生时，数据丢失量最小化
2. 缩短恢复时间：确保在灾难发生后，系统能够快速恢复
3. 保证业务连续性：确保在灾难发生后，业务能够持续运行
4. 降低灾难影响：减少灾难对业务的影响范围和程度
1.2 灾备的重要性
灾备的重要性在于确保在灾难发生时，系统能够快速恢复，保证业务的连续性，减少数据丢失和业务中断带来的损失。学习交流加群风哥微信: itpux-com
1.3 灾备的等级
根据恢复时间目标（RTO）和恢复点目标（RPO）的不同，灾备可以分为不同的等级。学习交流加群风哥QQ113257174
1. 等级0：无灾备方案，数据完全依赖备份恢复
2. 等级1：本地备份，通过备份恢复数据
3. 等级2：本地热备份，主备系统在同一机房
4. 等级3：异地热备份，主备系统在不同机房
5. 等级4：异地多活，主备系统同时运行，数据实时同步
# 各等级的RTO和RPO
– 等级0：RTO > 24小时，RPO > 24小时
– 等级1：RTO 12-24小时，RPO 1-12小时
– 等级2：RTO 1-6小时，RPO 0-30分钟
– 等级3：RTO 30分钟-1小时，RPO 0-15分钟
– 等级4：RTO < 30分钟，RPO = 0
Part02-生产环境规划与建议
2.1 灾备策略设计
设计合理的灾备策略是确保灾备效果的关键，以下是灾备策略的设计要点。风哥提示：生产环境中应根据业务的重要性和数据量，设计不同的灾备策略。
2.2 灾备架构设计
合理的灾备架构设计是确保灾备效果的基础，以下是灾备架构的设计要点。更多学习教程公众号风哥教程itpux_com
1. 单机房灾备：主备系统在同一机房，适用于等级2的灾备需求
2. 跨机房灾备：主备系统在不同机房，适用于等级3的灾备需求
3. 异地灾备：主备系统在不同城市，适用于等级3或4的灾备需求
4. 多活架构：多个数据中心同时运行，适用于等级4的灾备需求
# 灾备架构选择因素
– 业务重要性：核心业务需要更高等级的灾备
– 数据量：数据量大的系统需要更高效的灾备方案
– 预算：不同等级的灾备方案成本不同
– 地理因素：考虑自然灾害的影响范围
– 合规要求：某些行业有特定的灾备要求
2.3 灾备演练计划
定期进行灾备演练是确保灾备方案有效性的关键，以下是灾备演练的计划要点。from MySQL:www.itpux.com
1. 演练频率：
– 单机房灾备：每季度演练一次
– 跨机房灾备：每半年演练一次
– 异地灾备：每年演练一次
2. 演练内容：
– 故障模拟：模拟主系统故障
– 切换测试：测试从主系统切换到备用系统
– 恢复测试：测试从备用系统恢复到主系统
– 性能测试：测试备用系统的性能
3. 演练流程：
– 准备阶段：制定演练计划，准备测试环境
– 执行阶段：执行演练步骤，记录结果
– 评估阶段：评估演练结果，分析问题
– 改进阶段：根据演练结果，改进灾备方案
4. 演练文档：
– 演练计划
– 演练脚本
– 演练结果报告
– 改进计划
Part03-生产环境项目实施方案
3.1 主从复制配置
主从复制是MySQL灾备的基础，以下是主从复制的配置步骤。
# 主服务器配置
# vi /etc/my.cnf
[mysqld]
# 服务器ID
server_id = 1
# 启用二进制日志
log_bin = /mysql/logs/binlog
# 二进制日志格式
binlog_format = ROW
# 自动清理二进制日志
expire_logs_days = 7
# 同步复制
rpl_semi_sync_master_enabled = 1
# 重启主服务器
systemctl restart mysqld
# 创建复制用户
mysql> CREATE USER ‘repl’@’%’ IDENTIFIED BY ‘StrongPassword123!’;
mysql> GRANT REPLICATION SLAVE ON *.* TO ‘repl’@’%’;
mysql> FLUSH PRIVILEGES;
# 获取主服务器状态
mysql> SHOW MASTER STATUS;
+—————+———-+————–+——————+——————-+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+—————+———-+————–+——————+——————-+
| binlog.000001 | 123456 | | | |
+—————+———-+————–+——————+——————-+
1 row in set (0.00 sec)
# 从服务器配置
# vi /etc/my.cnf
[mysqld]
# 服务器ID
server_id = 2
# 启用中继日志
relay_log = /mysql/logs/relay-bin
# 只读模式
read_only = 1
# 同步复制
rpl_semi_sync_slave_enabled = 1
# 重启从服务器
systemctl restart mysqld
# 配置从服务器连接主服务器
mysql> CHANGE MASTER TO
-> MASTER_HOST=’192.168.1.100′,
-> MASTER_PORT=3306,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’StrongPassword123!’,
-> MASTER_LOG_FILE=’binlog.000001′,
-> MASTER_LOG_POS=123456;
# 启动从服务器复制
mysql> START SLAVE;
# 检查从服务器状态
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.100
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000001
Read_Master_Log_Pos: 123456
Relay_Log_File: relay-bin.000001
Relay_Log_Pos: 123456
Relay_Master_Log_File: binlog.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 123456
Relay_Log_Space: 123456
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 12345678-1234-1234-1234-1234567890ab
Master_Info_File: /mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
3.2 主主复制配置
主主复制是一种高可用性的灾备方案，以下是主主复制的配置步骤。
# 服务器1配置
# vi /etc/my.cnf
[mysqld]
# 服务器ID
server_id = 1
# 启用二进制日志
log_bin = /mysql/logs/binlog
# 二进制日志格式
binlog_format = ROW
# 自动清理二进制日志
expire_logs_days = 7
# 同步复制
rpl_semi_sync_master_enabled = 1
# 自增ID偏移
auto_increment_offset = 1
auto_increment_increment = 2
# 服务器2配置
# vi /etc/my.cnf
[mysqld]
# 服务器ID
server_id = 2
# 启用二进制日志
log_bin = /mysql/logs/binlog
# 二进制日志格式
binlog_format = ROW
# 自动清理二进制日志
expire_logs_days = 7
# 同步复制
rpl_semi_sync_master_enabled = 1
# 自增ID偏移
auto_increment_offset = 2
auto_increment_increment = 2
# 重启两台服务器
systemctl restart mysqld
# 在服务器1上创建复制用户
mysql> CREATE USER ‘repl’@’%’ IDENTIFIED BY ‘StrongPassword123!’;
mysql> GRANT REPLICATION SLAVE ON *.* TO ‘repl’@’%’;
mysql> FLUSH PRIVILEGES;
# 在服务器2上创建复制用户
mysql> CREATE USER ‘repl’@’%’ IDENTIFIED BY ‘StrongPassword123!’;
mysql> GRANT REPLICATION SLAVE ON *.* TO ‘repl’@’%’;
mysql> FLUSH PRIVILEGES;
# 获取服务器1的状态
mysql> SHOW MASTER STATUS;
+—————+———-+————–+——————+——————-+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+—————+———-+————–+——————+——————-+
| binlog.000001 | 123456 | | | |
+—————+———-+————–+——————+——————-+
1 row in set (0.00 sec)
# 获取服务器2的状态
mysql> SHOW MASTER STATUS;
+—————+———-+————–+——————+——————-+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+—————+———-+————–+——————+——————-+
| binlog.000001 | 234567 | | | |
+—————+———-+————–+——————+——————-+
1 row in set (0.00 sec)
# 配置服务器2连接服务器1
mysql> CHANGE MASTER TO
-> MASTER_HOST=’192.168.1.100′,
-> MASTER_PORT=3306,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’StrongPassword123!’,
-> MASTER_LOG_FILE=’binlog.000001′,
-> MASTER_LOG_POS=123456;
mysql> START SLAVE;
# 配置服务器1连接服务器2
mysql> CHANGE MASTER TO
-> MASTER_HOST=’192.168.1.101′,
-> MASTER_PORT=3306,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’StrongPassword123!’,
-> MASTER_LOG_FILE=’binlog.000001′,
-> MASTER_LOG_POS=234567;
mysql> START SLAVE;
# 检查两台服务器的状态
mysql> SHOW SLAVE STATUS\G;
# 确认Slave_IO_Running和Slave_SQL_Running都为Yes
3.3 灾备监控配置
配置灾备监控是确保灾备系统正常运行的关键，以下是灾备监控的配置步骤。
# 1. 配置MySQL监控
# vi /mysql/scripts/monitor_replication.sh
#!/bin/bash
# monitor_replication.sh
# from:www.itpux.com.qq113257174.wx:itpux-com
# web: http://www.fgedu.net.cn
LOG_FILE=”/mysql/logs/replication_monitor.log”
DB_USER=”fgedu_admin”
DB_PASS=”StrongPassword123!”
# 检查主从复制状态
SLAVE_STATUS=$(mysql -u $DB_USER -p$DB_PASS -e “SHOW SLAVE STATUS\G”)
# 检查Slave_IO_Running状态
IO_RUNNING=$(echo “$SLAVE_STATUS” | grep “Slave_IO_Running” | awk ‘{print $2}’)
if [ “$IO_RUNNING” != “Yes” ]; then
echo “[$(date +%Y-%m-%d%H:%M:%S)] Slave_IO_Running is $IO_RUNNING!” >> $LOG_FILE
# 发送告警邮件
mail -s “MySQL Replication Alert” admin@example.com < $LOG_FILE
fi
# 检查Slave_SQL_Running状态
SQL_RUNNING=$(echo "$SLAVE_STATUS" | grep "Slave_SQL_Running" | awk '{print $2}')
if [ "$SQL_RUNNING" != "Yes" ]; then
echo "[$(date +%Y-%m-%d%H:%M:%S)] Slave_SQL_Running is $SQL_RUNNING!" >> $LOG_FILE
# 发送告警邮件
mail -s “MySQL Replication Alert” admin@example.com < $LOG_FILE
fi
# 检查复制延迟
SECONDS_BEHIND=$(echo "$SLAVE_STATUS" | grep "Seconds_Behind_Master" | awk '{print $2}')
if [ "$SECONDS_BEHIND" -gt 60 ]; then
echo "[$(date +%Y-%m-%d%H:%M:%S)] Replication delay is $SECONDS_BEHIND seconds!" >> $LOG_FILE
# 发送告警邮件
mail -s “MySQL Replication Alert” admin@example.com < $LOG_FILE
fi
# 2. 配置服务器监控
# vi /mysql/scripts/monitor_server.sh
#!/bin/bash
# monitor_server.sh
LOG_FILE="/mysql/logs/server_monitor.log"
# 检查服务器负载
LOAD=$(uptime | awk '{print $10}')
if (( $(echo "$LOAD > 8.0″ | bc -l) )); then
echo “[$(date +%Y-%m-%d%H:%M:%S)] Server load is $LOAD!” >> $LOG_FILE
# 发送告警邮件
mail -s “Server Load Alert” admin@example.com < $LOG_FILE
fi
# 检查磁盘空间
DISK_USAGE=$(df -h /mysql | grep /mysql | awk '{print $5}' | sed 's/%//')
if [ "$DISK_USAGE" -gt 80 ]; then
echo "[$(date +%Y-%m-%d%H:%M:%S)] Disk usage is $DISK_USAGE%!" >> $LOG_FILE
# 发送告警邮件
mail -s “Disk Usage Alert” admin@example.com < $LOG_FILE
fi
# 检查内存使用
MEMORY_USAGE=$(free -m | grep Mem | awk '{print $3/$2 * 100}')
if (( $(echo "$MEMORY_USAGE > 80″ | bc -l) )); then
echo “[$(date +%Y-%m-%d%H:%M:%S)] Memory usage is $MEMORY_USAGE%!” >> $LOG_FILE
# 发送告警邮件
mail -s “Memory Usage Alert” admin@example.com < $LOG_FILE
fi
# 3. 设置定时任务
# crontab -e
*/5 * * * * /mysql/scripts/monitor_replication.sh
*/10 * * * * /mysql/scripts/monitor_server.sh
Part04-生产案例与实战讲解
4.1 单机房灾备方案
单机房灾备方案适用于对RTO和RPO要求不高的场景，以下是具体的实施方案。
# 架构：主服务器 + 从服务器（同一机房）
# 配置步骤
1. 配置主从复制（参考3.1节）
2. 配置监控（参考3.3节）
3. 制定灾备切换流程
# 灾备切换流程
# 步骤1：检查主服务器状态
# ping 192.168.1.100
# 步骤2：停止从服务器的复制
mysql> STOP SLAVE;
# 步骤3：将从服务器设置为可写
mysql> SET GLOBAL read_only = 0;
# 步骤4：更新应用连接配置，指向从服务器
# 例如，修改应用的数据库连接字符串
# 步骤5：验证从服务器的状态
mysql> SHOW DATABASES;
mysql> SELECT COUNT(*) FROM fgedudb.fgedu_users;
# 步骤6：处理主服务器故障
# 修复主服务器故障
# 步骤7：将主服务器设置为从服务器
mysql> CHANGE MASTER TO
-> MASTER_HOST=’192.168.1.101′,
-> MASTER_PORT=3306,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’StrongPassword123!’,
-> MASTER_LOG_FILE=’binlog.000001′,
-> MASTER_LOG_POS=123456;
mysql> START SLAVE;
# 步骤8：验证复制状态
mysql> SHOW SLAVE STATUS\G;
# 步骤9：根据需要，将主服务器切换回主角色
4.2 跨机房灾备方案
跨机房灾备方案适用于对RTO和RPO要求较高的场景，以下是具体的实施方案。
# 架构：主服务器（机房A） + 从服务器（机房B）
# 配置步骤
1. 配置主从复制（参考3.1节）
2. 配置监控（参考3.3节）
3. 制定灾备切换流程
# 灾备切换流程
# 步骤1：检查主服务器状态
# ping 192.168.1.100
# 步骤2：停止从服务器的复制
mysql> STOP SLAVE;
# 步骤3：将从服务器设置为可写
mysql> SET GLOBAL read_only = 0;
# 步骤4：更新应用连接配置，指向从服务器
# 例如，修改应用的数据库连接字符串或更新DNS记录
# 步骤5：验证从服务器的状态
mysql> SHOW DATABASES;
mysql> SELECT COUNT(*) FROM fgedudb.fgedu_users;
# 步骤6：处理主服务器故障
# 修复主服务器故障
# 步骤7：将主服务器设置为从服务器
mysql> CHANGE MASTER TO
-> MASTER_HOST=’192.168.2.100′,
-> MASTER_PORT=3306,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’StrongPassword123!’,
-> MASTER_LOG_FILE=’binlog.000001′,
-> MASTER_LOG_POS=123456;
mysql> START SLAVE;
# 步骤8：验证复制状态
mysql> SHOW SLAVE STATUS\G;
# 步骤9：根据需要，将主服务器切换回主角色
4.3 异地灾备方案
异地灾备方案适用于对RTO和RPO要求很高的场景，以下是具体的实施方案。
# 架构：主服务器（城市A） + 从服务器（城市B）
# 配置步骤
1. 配置主从复制（参考3.1节）
2. 配置监控（参考3.3节）
3. 制定灾备切换流程
4. 配置网络连接，确保两个城市之间的网络稳定
# 灾备切换流程
# 步骤1：检查主服务器状态
# ping 10.0.0.100
# 步骤2：停止从服务器的复制
mysql> STOP SLAVE;
# 步骤3：将从服务器设置为可写
mysql> SET GLOBAL read_only = 0;
# 步骤4：更新应用连接配置，指向从服务器
# 例如，修改应用的数据库连接字符串或更新DNS记录
# 步骤5：验证从服务器的状态
mysql> SHOW DATABASES;
mysql> SELECT COUNT(*) FROM fgedudb.fgedu_users;
# 步骤6：处理主服务器故障
# 修复主服务器故障
# 步骤7：将主服务器设置为从服务器
mysql> CHANGE MASTER TO
-> MASTER_HOST=’10.0.1.100′,
-> MASTER_PORT=3306,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’StrongPassword123!’,
-> MASTER_LOG_FILE=’binlog.000001′,
-> MASTER_LOG_POS=123456;
mysql> START SLAVE;
# 步骤8：验证复制状态
mysql> SHOW SLAVE STATUS\G;
# 步骤9：根据需要，将主服务器切换回主角色
4.4 灾备切换实战
灾备切换是灾备方案的核心，以下是灾备切换的实战案例。
# 场景：主服务器发生故障，需要切换到备用服务器
# 步骤1：确认主服务器故障
# ping 192.168.1.100
PING 192.168.1.100 (192.168.1.100) 56(84) bytes of data.
From 192.168.1.101 icmp_seq=1 Destination Host Unreachable
# 步骤2：登录备用服务器，检查复制状态
mysql> SHOW SLAVE STATUS\G;
*************************** 1. row ***************************
Slave_IO_State: Connecting to master
Master_Host: 192.168.1.100
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: binlog.000001
Read_Master_Log_Pos: 123456
Relay_Log_File: relay-bin.000001
Relay_Log_Pos: 123456
Relay_Master_Log_File: binlog.000001
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 123456
Relay_Log_Space: 123456
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 2003
Last_IO_Error: error connecting to master ‘repl@192.168.1.100:3306’ – retry-time: 60 maximum-retries: 86400 message: Can’t connect to MySQL server on ‘192.168.1.100’ (111)
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: 12345678-1234-1234-1234-1234567890ab
Master_Info_File: /mysql/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 260401 10:00:00
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
# 步骤3：停止复制
mysql> STOP SLAVE;
Query OK, 0 rows affected (0.00 sec)
# 步骤4：将备用服务器设置为可写
mysql> SET GLOBAL read_only = 0;
Query OK, 0 rows affected (0.00 sec)
# 步骤5：更新应用连接配置，指向备用服务器
# 例如，修改应用的数据库连接字符串
# vi /app/config/database.yml
# 将host从192.168.1.100改为192.168.1.101
# 步骤6：验证备用服务器的状态
mysql> SHOW DATABASES;
+——————–+
| Database |
+——————–+
| information_schema |
| fgedudb |
| mysql |
| performance_schema |
| sys |
+——————–+
5 rows in set (0.00 sec)
mysql> SELECT COUNT(*) FROM fgedudb.fgedu_users;
+———-+
| COUNT(*) |
+———-+
| 1000 |
+———-+
1 row in set (0.00 sec)
# 步骤7：通知相关人员，灾备切换完成
# 发送邮件或短信通知
# 步骤8：修复主服务器故障
# 例如，重启MySQL服务或修复硬件故障
# 步骤9：将主服务器设置为备用服务器
# 待主服务器修复后，配置其作为备用服务器
mysql> CHANGE MASTER TO
-> MASTER_HOST=’192.168.1.101′,
-> MASTER_PORT=3306,
-> MASTER_USER=’repl’,
-> MASTER_PASSWORD=’StrongPassword123!’,
-> MASTER_LOG_FILE=’binlog.000001′,
-> MASTER_LOG_POS=123456;
mysql> START SLAVE;
# 步骤10：验证复制状态
mysql> SHOW SLAVE STATUS\G;
# 确认Slave_IO_Running和Slave_SQL_Running都为Yes
Part05-风哥经验总结与分享
通过多年的MySQL数据库管理经验，我总结了以下关于灾备的关键点：
1. 灾备策略：根据业务的重要性和数据量，设计合适的灾备策略，确定RTO和RPO目标。
2. 灾备架构：选择合适的灾备架构，如单机房、跨机房或异地灾备，确保在灾难发生时能够快速恢复。
3. 主从复制：配置主从复制是灾备的基础，确保数据能够实时同步到备用服务器。
4. 监控配置：配置完善的监控系统，及时发现和处理灾备系统的问题。
5. 灾备演练：定期进行灾备演练，验证灾备方案的有效性，确保在灾难发生时能够快速响应。
6. 切换流程：制定详细的灾备切换流程，确保在灾难发生时能够快速、有序地切换到备用系统。
7. 持续改进：根据灾备演练的结果，持续改进灾备方案，提高灾备系统的可靠性。
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
联系我们
在线咨询：
微信号：itpux-com
工作日：9:30-18:30，节假日休息
