【MySQL InnoDB 内核】主从切换与数据恢复：PITR 与 xtrabackup 边界
内容提要
本文介绍MySQL主从切换与数据恢复的边界，重点涵盖PITR（基于全量备份+binlog）、XtraBackup物理备份、GTID failover约束及误删表恢复。强调物理备份+binlog是标准组合，RESET MASTER有毁灭性，需定期演练恢复，并对比PG的WAL与timeline机制。
延伸解读
备份选型：逻辑与物理的权衡
文章对比了mysqldump与xtrabackup：逻辑备份简单且跨版本，但大库慢且一致性依赖选项；物理备份热备、恢复快，但工具链与版本耦合。实际选择需根据数据量、恢复时间目标（RTO）和运维复杂度权衡，没有绝对优劣。
PITR的边界条件
PITR并非万能：依赖全量备份点与连续binlog，若binlog被PURGE或存在未记录的非InnoDB引擎变更，则无法恢复到更早时刻。这提醒我们，binlog的保留策略和备份频率直接决定可恢复的时间窗口。
GTID与RESET MASTER的风险
GTID环境下failover必须保证executed gtid集合单调性，否则从库拒绝启动。RESET MASTER会清空binlog与历史，仅限重建拓扑时使用，日常误操作可能导致数据无法恢复。理解这些约束是避免灾难性失误的关键。
恢复演练的必要性
文章强调恢复演练应按RTO/RPO定期进行。即使有备份和binlog，未经验证的恢复流程可能在真实故障时失败。定期演练能发现工具版本不匹配、路径错误等问题，确保关键时刻可恢复。
Q&A
MySQL误删表后，第一反应应该做什么？
误删表后，第一反应不应该是执行RESET MASTER，而应该利用全量备份和binlog进行恢复。
MySQL PITR（时间点恢复）需要哪些条件？
PITR需要全量备份点加上连续的binlog，通过恢复全量备份并应用binlog到目标时刻来实现。
Percona XtraBackup备份的原理是什么？
XtraBackup通过物理拷贝InnoDB页并记录redo日志，备份结束后记录binlog位点/GTID，恢复时使用--prepare应用redo到一致点。
GTID环境下主从切换需要注意什么？
GTID环境下，提升从库为主库时要避免回退到更小GTID集合的实例，否则从库会拒绝启动。
RESET MASTER命令有什么风险？
RESET MASTER会清空binlog和executed GTID历史，具有毁灭性，仅在明确重建拓扑时使用，不是日常操作。
MySQL和PostgreSQL在PITR实现上有何区别？
MySQL使用binlog逻辑事件进行PITR，而PostgreSQL使用WAL归档和recovery_target；位点方面MySQL用GTID或file+pos，PG用LSN和timeline。
如何恢复误删的表？
如果有binlog和备份，可以生成反向事件或恢复到临时实例导出；如果没有binlog，数据不可恢复。闪回工具依赖row binlog和完整行镜像。
为什么说物理备份+binlog是PITR的标准组合？
物理备份（如XtraBackup）提供快速恢复的全量数据，binlog提供连续的逻辑变更，两者结合可以恢复到任意时间点，是PITR的标准组合。
