MySQL Slave Crash-Safe Feature Analysis
The article examines MySQL 5.6’s crash‑safe slave replication, explaining how earlier versions’ unsafe relay‑log handling could corrupt position data, describing the atomic update of mysql.slave_relay_log_info via table‑based relay‑log info and transaction coordination, and covering configuration options, recovery behavior, GTID implications, performance trade‑offs, and implementation guidance.
This article provides a comprehensive analysis of MySQL's slave crash-safe feature introduced in version 5.6. It begins by explaining the problem of crash-unsafe behavior in previous versions, where system crashes could lead to inaccurate relay_log.info position information.
The article then details how MySQL 5.6 addresses this issue through atomic operations, storing position information in the mysql.slave_relay_log_info table and combining it with normal transactions to ensure atomicity between applying binlog transactions and updating relay info.
Key aspects covered include: the recovery mechanism when relay_log_recovery is enabled, GTID mode crash-safe behavior, configuration parameters (relay_log_info_repository=TABLE, relay_log_recovery=ON), and potential issues with enabling this feature such as increased IO pressure on master nodes and dependency on binlog availability.
The article provides detailed code examples, visual diagrams, and practical configuration guidance for implementing crash-safe replication in MySQL environments.
Youzan Coder
Official Youzan tech channel, delivering technical insights and occasional daily updates from the Youzan tech team.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.