MySQL高可用数据库内核深度优化的四重定制
EliBEUM
7年前
<p>作者介绍</p> <p>王松磊，现任职于UCloud，从事MySQL数据库内核研发工作。主要负责UCloud云数据库UDB的内核故障排查工作以及数据库新特性的研发工作。</p> <p>近期我们的数据库团队对原生复制的多个方面进行了深度优化，提升了UDB高可用数据库的功能和性能。今天借社群这个平台，跟大家分享一二。</p> <h2><strong>一、UDB高可用数据库架构</strong></h2> <p>UDB以虚拟IP、HAProxy、单节点UDB数据库搭建双节点高可用架构：</p> <ul> <li>双节点的UDB数据库保证数据库数据的全量冗余，同时保证数据库的可用性；</li> <li>HAProxy在同一时间只连接一个UDB节点，避免多点写入带来的数据冲突问题；</li> <li>双节点HAProxy保证Proxy的可用性；</li> <li>虚拟IP在HAProxy发生宕机时通过IP漂移的方式对HAProxy进行切换，用户不需要再次修改IP。</li> </ul> <p><img src="https://simg.open-open.com/show/701ce1428e079b5eaa957d9c927922dd.jpg"></p> <p>在上述架构中，从节点UDB的数据是否完整、是否与主库保证数据一致性是整个高可用架构的关键，所以用于数据传输的半同步复制起着至关重要的作用。针对原生的半同步复制，我们作了内核层面的深度优化。</p> <h2><strong>二、UDB数据库深度优化</strong></h2> <p>UDB是以开源数据库MySQL Community Server 5.7.16为基线版本，围绕高可用架构做内核深度优化。</p> <p><img src="https://simg.open-open.com/show/53c4e6dc32a3f03ddc4abe3aef0f5e1b.jpg"></p> <p>复制流程，如上图所示，主要经过如下几个步骤：</p> <ul> <li>MySQL Server执行SQL成功后，记录binlog；</li> <li>Dump线程读取binlog后，发送到从机IO线程；</li> <li>IO线程将接收到的binlog记录到relay log中，同时记录接收进度到master.info中；</li> <li>SQL读取relay log中的日志内容进行复现，同时记录复制日志的进度到relay-log.info中。</li> </ul> <p>我们在原生复制的基础上做了内核的深度优化，针对上述流程中的部分步骤，在功能和性能上做了改进，使得 UDB更加稳定。</p> <h3><strong>1</strong> <strong>、Binlog日志复制优化</strong></h3> <p>存在的问题</p> <p>原生半同步复制存在退化问题，在网络抖动导致超时或者从库追赶主库日志进度时，复制会由半同步复制退化为异步复制。</p> <p>相比于可靠的半同步复制，异步复制过程中，从库是没有办法感知接收到relay log与主库的binlog是否一致。如果发生宕机，也就没有办法确认从库数据是否与主库一致，是否可以发生数据库切换，这种不确定的情况是我们不希望看到的。</p> <p>优化方案</p> <p>建立双通道复制，在原有半同步复制的基础上增加一条UDB复制通道：</p> <ul> <li>建立一条新的复制通道与原有的复制并行，两条通道互相独立；</li> <li>新的复制通道不传输数据，只传输主库的SQL执行进度 （binlog的文件名和位置）；</li> <li>新的复制通道使用半同步复制协议，但是不退化，超时后重连，只接收最新的SQL执行进度 ；</li> <li>新的复制通道不存在追补数据的问题，只要网络正常的情况下，从库永远可以感知SQL的执行进度。</li> </ul> <p><img src="https://simg.open-open.com/show/8da41708440b10d069bff99da1167844.jpg"></p> <p>如上图所示，当从库发生宕机或者网络发生故障后，主从复制停止。当从库复制恢复正常后，原生复制通道通过异步复制的方式进行数据追补，UDB复制通道只接收最新的binlog记录位置，这样可以最大限度地减少主从之间异步复制的时间。即在网络可连通的情况下，无论何时发生宕机，从库均知道与主库是否处于数据一致的状态（或者落后了多少）。</p> <h3><strong>2</strong> <strong>、Relay log文件记录的优化</strong></h3> <p>存在的问题</p> <p>在MySQL中，binlog是以event为基本单位进行记录，以MySQL 5.7 ROW格式（开启GTID）的binlog为例，一个DML（insert）会以5个event的格式记录到binlog中（其他操作均以一个或者多个event组成，不再一一罗列），分别为：</p> <ul> <li>GTID_EVENT：记录当前事务的GTID</li> <li>QUERY_EVENT：事务开始</li> <li>TABLE_MAP_EVENT：操作对应的表</li> <li>WRITE_ROW_EVENT：插入记录</li> <li>XID_EVENT：提交事务</li> </ul> <p>全部event组成一个完整的事务，完整的事务才会被SQL线程正确复现到从库上。当前IO线程接收binlog时，是以event为单位进行接收，即接收到一个event，记录到relay log中后再继续接收下一个。这种做法是低效的，也没有充分利用到MySQL本身的文件缓存。</p> <p>优化方案</p> <p>优化IO线程记录relay log的方式，将以event为单位记录，修改为以事务为单位进行记录。合并IO线程小的IO操作，提高IO性能。</p> <p><img src="https://simg.open-open.com/show/a1c9443cdb5a9c3f079ece1cf04d1075.jpg"></p> <p>将单个的event写操作合并为多个event统一写操作，将小的IO操作合并成较大的IO操作，提高IO性能。</p> <h3><strong>3</strong> <strong>、Master.info文件记录的优化</strong></h3> <p>存在的问题</p> <p>Master.info文件在搭建复制时，记录主库IP、PORT等连接主库的相关信息，在复制过程中，记录IO线程从主库接收到的binlog的文件名和位置，文件和位置会在每次记录relay log成功后更新。</p> <p>在基于GTID搭建复制后，master.info中记录的binlog文件和位置不再作为复制的依据，所以master.info中记录的binlog的文件和位置不再是有效的数据，也就没有必要每次进行更新。</p> <p>优化方案</p> <p>在IO线程记录relay log成功后，更新master.info文件之前，添加判断。如果开启了GTID并且使用GTID作为复制的依据（auto_position=1），那么不再更新master.info中binlog的文件和位置。</p> <p>其它的master.info操作仍然保留，如change master、shutdown等操作。</p> <h3><strong>4</strong> <strong>、Relay log锁的优化</strong></h3> <p>存在的问题</p> <p>在IO线程和SQL线程复制进度相似的情况下，在操作relay log时，会使用同一块文件缓存，在读写文件缓存时，需要加锁来保证操作的正确性。而IO线程和SQL线程需要频繁地读写这块公共内存，就需要对同一把锁频繁的竞争，从而导致性能下降。</p> <p>优化方案</p> <p>将IO线程和SQL线程对relay log的操作拆分开来，不再使用同一块文件缓存。虽然这样做会导致SQL线程增加一次读IO操作。但是消除了对锁的竞争，大大地提高了IO线程和SQL线程整体的性能。</p> <p><img src="https://simg.open-open.com/show/eaf1f5666a797b0be8d32efa34dff943.png"></p> <h2><strong>三、总结</strong></h2> <p>优化后的复制流程图如下：</p> <p><img src="https://simg.open-open.com/show/18585ca9fe3c9dfba6900925e7c1a931.jpg"></p> <p>数据库原生复制流程中包括记录binlog、记录relay log、记录master.info、relay-log.info等，针对上述流程中的部分步骤以及其它未列出的优化，在功能和性能上进行改进，UDB高可用数据库在功能和性能上均得到了明显的提升。</p> <p>文章来自微信公众号：DBAplus社群</p> <p> </p> <p>来自：http://www.yunweipai.com/archives/22294.html</p> <p> </p>