第五部分：数据库高可用与复制 —— 让系统永不掉线
单机数据库存在单点故障风险。生产环境必须配置高可用方案，常见的有主从复制、集群和分布式数据库。
5.1 主从复制（Replication）
主从复制是最基础的冗余方案：主库处理写请求，一个或多个从库异步或半同步复制主库的数据变更，从库处理读请求（读写分离）。
5.1.1 MySQL 复制原理
主库将数据变更写入二进制日志（Binary Log, binlog）。
从库的 I/O 线程连接到主库，请求 binlog 并保存到本地的中继日志（Relay Log）。
从库的 SQL 线程读取中继日志，重放 SQL 操作。
复制模式：
异步复制：主库不等待从库确认，性能好但可能丢数据（主库宕机时未发送的日志丢失）。
半同步复制：主库至少等待一个从库确认收到 binlog 才返回提交成功，降低丢失风险，但增加延迟。
全同步复制：所有从库确认后才提交，基本无数据丢失，但性能极差，极少使用。
5.1.2 搭建简单的 MySQL 主从（步骤概要）
-- 主库配置 my.cnf
[mysqld]
log-bin=mysql-bin
server-id=1
binlog-do-db=mydb
-- 创建复制账号
CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
-- 从库配置
server-id=2
-- 从库执行
CHANGE MASTER TO
MASTER_HOST='master_host',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=0;
START SLAVE;
5.1.3 主从延迟问题与解决
主从延迟（Seconds_Behind_Master）过大时，从库读到旧数据，影响读写分离的正确性。
延迟原因：
从库硬件较差。
主库写并发高，从库 SQL 线程单线程重放（MySQL 5.6 后支持多线程复制，需配置 slave_parallel_workers）。
大事务（如一次删除百万行）导致 binlog 生成慢且重放慢。
从库上有耗时的读查询（锁冲突）。
对策：
提升从库硬件，使用 SSD。
拆分大事务。
开启并行复制。
读写分离时，对于要求强一致性的读，强制走主库。
5.2 高可用切换与故障转移
当主库故障时，需要将一个从库提升为新主库。手动切换慢且易错，通常使用自动化工具：
MHA（MySQL Master High Availability）
Orchestrator
ProxySQL + 自动探测
现代数据库如 Galera Cluster（MySQL 多主同步集群）提供强一致性高可用，但写冲突需要处理。PostgreSQL 有 Patroni + etcd 实现自动故障转移。
5.3 读写分离架构
在应用层实现读写分离：写操作走主库，读操作走从库池（负载均衡）。需要注意：
从库延迟导致刚写入的数据读不到。可以采取“写后读主”策略（关键读走主库）。
使用中间件如 ShardingSphere-Proxy、Mycat、MaxScale 对应用透明。
第六部分：数据库监控与调优 —— 持续的战斗力
即使初期设计和索引都合理，随着数据量和访问模式变化，性能也会逐渐下降。建立监控和持续调优机制至关重要。
6.1 关键性能指标（KPI）
QPS/TPS：每秒查询数/事务数，衡量吞吐量。
慢查询数量：超过阈值的 SQL 数量，慢查询日志分析的基础。
InnoDB 缓冲池命中率：SHOW ENGINE INNODB STATUS 中 Buffer pool hit rate，低于 95% 说明内存不足或热数据太大。
锁等待与死锁：Innodb_row_lock_waits、Innodb_deadlocks。
复制延迟：Seconds_Behind_Master。
连接数使用率：接近 max_connections 时需要扩容或优化连接池。
6.2 慢查询日志与分析
开启慢查询日志（MySQL）：
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 2; -- 超过2秒记录
SET GLOBAL log_queries_not_using_indexes = ON; -- 记录未使用索引的查询
使用 pt-query-digest（Percona Toolkit）分析慢日志，它会把相似的 SQL 聚合，按时间、锁等排序，输出最耗时的查询。
6.3 数据库配置调优
不同数据库的配置差异很大，以下是一些通用原则：
注意：修改参数前必须基准测试；在云数据库（RDS）上，许多参数是默认优化好的。
6.4 使用 Explain 进行持续审查
建立 SQL 审核机制：所有上线 SQL 必须经过 Explain 检查，避免全表扫描、无索引排序等。
来源：
https://rvtst.cn/
