azure mysql 实时同步_Azure Database for MySQL 多云容灾

大家好，今天以此小文来说一说 Azure Database for MySQL 的多云容灾。作为任何一家云的 RDS PaaS 服务所有的可用性都是用白纸黑字的 SLA 支撑的，无论是4个9还是 n 个9 都意味着有 outage 的可能性, Everything fails all the time. 对于 RDS 数据库服务，如果服务实现 outage 意味着有可能存在不可预期的 RTO。原因很简单，对于 PaaS 服务属于沙箱式的服务，当初出现故障所需的故障恢复时间由云服务商决定，对于用户只能在一边默默祈祷早日恢复。对于任何一个业务应用，从业务重要性角度出发，会提出不同的 SLA 的要求，从而转化为系统架构时需求。对于 Mission Critical 的业务应用，用户应该从最初的架构设计角度考虑所采用的产品、技术栈及其可能对 SLA 带来的影响因素。对于 Azure Database for MySQL 而言一样存在着极端情况下无法使用的情况，那我们如何来实现高可用架构，更好的应对 Mission Critical 业务应用对可用性的要求。下面我们来假设 Azure Database for MySQL 在极端条件下整个 PaaS 服务在 Azure 内的所有 Region 都无法使用了，或者当前所使用的 Azure Database for MySQL 所在 Region 内该服务不可用了，如何保证数据服务以及业务应用的可用性？鸡蛋不要放在一个篮子里，1. 可否在非 PaaS 服务内有一份备份可用的数据服务，2. 可否在其它云平台有一份备份可用的数据服务。Azure Database for MySQL 是以社区版本 MySQL 为基础开发的 PaaS 服务，其原生同样支持 Binlog 的同步机制，后面我们来介绍一下如何在 Azure Database for MySQL 上开启 Binlog，并在其它 MySQL 部署中与其进行同步。

1. 开启 Azure Database for MySQL 的 Binlog

默认  Azure Database for MySQL 在无 Replica 副本情况下 Binlog 是关闭的，可以通过添加 Replica 副本的方式来间接开启 Binlog，开启完毕后将 Replica 服务删除。

登入 Azure Database for MySQL 查看 Binlog 状态

mysql> show master status;

+------------------+----------+--------------+------------------+-------------------+

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |

+------------------+----------+--------------+------------------+-------------------+

| mysql-bin.000001 | 2981 | | | |

+------------------+----------+--------------+------------------+-------------------+

1 row in set (0.02 sec)

mysql> show binary logs;

+------------------+-----------+

| Log_name | File