Azur和MySQL高级分析数据库

数据是整个IT系统中必不可少的服务之一，其高可用性是系统设计过程中主要考虑的因素。在评估MySQL数据库高可用性时，主要考虑两个方面：

1. 如果数据库出现故障，比如宕机、网络中断等意外情况导致数据库服务不可用，可用性如何。数据服务能尽快恢复吗？尽可能减少停机时间，保证业务连续性，即RTO（容错率）。
2. 副本数据库作为备节点进行高故障切换时，其数据内容应与主数据库一致；如何保证上述数据库故障转移变更后不出现数据丢失或不一致的情况？这就是 RPO（数据丢失容忍度）。

Azur e Database for MySQL 灵活服务器这两方面如何实现？

为了充分理解Azur和MySQL的高层设计原理，我们先从Azur e MySQL数据库服务的架构开始。

以上图中的单服务器安装为例，Azur e MySQL 采用存储与计算分离的架构。存储层采用Azure Premium Storage，用于存储数据文件、事务日志、MySQL服务器日志等。这将备份三个本地副本以确保数据持久性。本地下行内存存储（LRS）用于在这三个副本之间进行复制，对它们的写请求同时发生，这意味着在写入返回之前必须将数据写入所有三个副本。 。

此外，MySQL会自动创建服务器备份（Backups）并将其存储在本地冗余备份存储中，本地冗余或非本地。这些备份文件可用于 Azur Restoration 和 MySQL 服务器。

在讨论MySQL高层逻辑之前，我们先看一下原生MySQL主从复制是如何完成的。

如上图所示，第一个MySQL数据库服务器会将数据变化写入Binlog日志中。当从库连接到主库服务器并指定读取Binlog文件的起点时，主库和从库会分别创建一个Dump线程和一个I/O线程并建立连接。通过这个连接，从库向主库发送Binlog读取请求，主库根据请求的内容向从库发送Binlog日志。从库的I/O线程收到Binlog日志后，会将其写入到自己的Relay日志中，并创建SQL线程将自己的内容返回到Relay日志中，以匹配从库中的数据。主图书馆。持续的。

这个MySQL原生的主从复制机制默认是异步的。主数据库执行完客户端提交的事务后，将其写入到自己的Binlog日志文件中，然后立即返回成功响应给客户端。由于Binlog同步过程与从库是异步的，主库并不知道Binlog文件是否已经成功上传到从站。因此，如果在从库收到主库发来的Binlog日志之前主库出现故障，就会导致服务中断，从而可能导致主从库冲突。

避免这种情况的常见解决方案是使用半同步复制，这也是MySQL集群最简单的解决方案之一。依靠半同步复制，主库等待从库接收到Binlog日志并写入Relay日志后，才向客户端返回事务成功的反馈，从而保证了主从库之间数据的奇偶性。另一方面，图书馆。性别。

但同时，半同步复制也会带来几个问题。一是导致主库写入出现明显延迟，影响数据库服务的性能；另一方面，如果从服务器出现故障，主数据库必须等待从服务器恢复才能完成写入；或者指定一段时间销毁策略恢复为异步复制，不保证数据一致性。因此，对于高层架构，目前使用的最好的解决方案是两通道复制、共享存储等。 MySQL数据库实现自动故障转移，确保提交的数据永远不会因为服务器故障而丢失。

这里以Azure地区的两个可用区（AZ）安装主数据库和备份数据库为例。

如上图所示，在高分辨率系统中，放置在Azure Premium Storage中的日志文件通过异地冗余存储（ZRS）提供的级别同步复制功能存储复制到备用服务器上，与前面介绍的LRS同步复制类似。 当主节点故障、服务不可用时，主数据存储层的逻辑文件仍然可以被备库访问。这意味着备用数据库仍然可以接收来自主数据库存储层的Binlog日志来完成Replay，从而使Azur eMySQL在故障转移过程中不会丢失任何数据（RPO=0）。

我们来看看下一个RTO。根据第二部分原生从复制的原理，我们很快可以看出，RTO时间中最重要的部分是备份节点根据日志Relay需要多长时间来恢复，即高度依赖于发生故障转移时的事务负载和对主服务器的写入压力。在Azur和MySQL的自动故障转移过程中，RTO时间还包括后台监控系统检测到主节点故障的时间和DNS解析时间，因为它与Azur和MySQL是FQDN有关。后台监控系统会定期检测服务器的状态，包括底层VM的状态和MySQL服务进程的状态。当检测到数据库服务器故障时，自动故障转移过程立即启动。同时，故障切换过程中会重新确认主服务器的状态，确认是否需要重启，避免网络瞬时中断造成误判。一般来说，总故障转移时间通常在 60 秒到 120 秒之间。对于高价服务器（特别是高性能SKU），通过进一步优化存储层，RTO时间为30秒。最长 60 秒。