水电站桥（门）式启闭机数据库冗余控制技术

水电站桥（门）式启闭机数据库冗余控制技术

刘千，张建，彭家彬，朱珩,李远

中国长江电力股份有限公司乌东德水力发电厂 云南 昆明 650000

中国水利水电夹江水工机械有限公司 四川 乐山 614100

摘要：在实际的作业环境中，如果数据库的读和写的操作是放在同一个数据库服务器中，那么会给服务器带来较大的负荷，降低了性能以及安全性。因此，通过主从复制的方式来同步数据，再通过读写分离来提升数据库的并发负载能力。

关键词：数据库；主从复制；读写分离

0．引言

在水电站桥（门）式启闭机中，以往的数据采集与储存多采用PLC/控制器内部寄存器来实现，PLC/控制器具有一定的数据存储功能，可防止因通信错误而出现数据丢失的情况，但是PLC/控制器在存储、管理大数据量能力不足的缺陷。另外在电源异常或内存丢失，PLC的系统时间会被初始化,这会使数据保存时间与实际时间不符，无法对监测数据进行长期有效的保存。因此，数据库在大数据时代所展现的数据管理能力，让其可以在水电站桥（门）式启闭机项目扮演数据管理员的重要角色。

当我们的数据库只使用一台服务器时，如果我们的数据库遭到破坏，例如人为操作的失误、机器的老化等等情况。虽然我们可以针对数据进行定时备份，在一定的程度上保障我们数据库的恢复。但是万一某一个备份操作未执行之前数据库就已经出现了问题，那么中间的这段时间的数据就会丢失，造成不必要的损失。因此可以采用主从复制模式增加冗余，提高可用性，当一台数据库服务器宕机后能通过调整另外一台从数据库来以最快的速度恢复服务。还可以基于此基础上通过读写分离缓解主服务的压力。当访问数据库的请求越来越多，这时候就给服务器增加了负担，容易导致服务崩溃等问题。因此，读写模式可以缓解单一服务器的压力，将写的操作分给主服务器，读的操作分给从服务器，分摊压力。

1．基于GTID的主从复制

（1）主从复制的目的

为什么要做主从复制？试想一下，在一个比较复杂的系统中，有这么一个情景，使用数据库时无故锁表，那么可能会影响到查询操作，进而影响运行中的业务。因此使用主从复制，将读与写分离出来，让主库负责写，让从库负责读取数据，这样，即使出现了主库被锁表的情况，通过读从库也可以暂时保证业务的运行。当然主从复制不仅仅只有这一个作用，比如主库宕机后能够及时替换主库，保证业务可用性，还有就是随着业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。

（2）主从复制原理

主从复制说得简单一点就是将一台服务器的数据库文件同步到其他的服务器上，使得被同步的服务器也可以读取到我们的数据。master服务器会将SQL记录通过多dump线程写入到binary log中。slave 服务器开启一个io thread线程向服务器发送请求，向master服务器请求binary log。master服务器在接收到请求之后，根据偏移量将新的binary log发送给slave服务器。slave服务器收到新的binary log之后，写入到自身的relay log中，这就是所谓的中继日志。slave服务器，单独开启一个sql thread读取relay log之后，写入到自身数据中。主从复制就如图1所示。

图1 主从复制原理

（3）主从复制的形式

常见的主从模式有一主一从模式、一主多从模式、级联主从模式以及一从多主模式等等，具体的模式也得看实际的业务需要。根据实际的情况，选择合适的一种架构模式。在本次水电站桥（门）式启闭机科研项目中，采用的是一主一从模式，如下图2所示，一主一从模式实施起来简单并且有效，不仅可以实现高可用，而且还能读写分离，进而提升集群的并发能力。

图2 一主一从模式

（4）GTID

    全局事务标识符GTID的全称为Global Transaction Identifier，是在整个复制环境中对一个事务的唯一标识。它是MySQL 5.6加入的一个强大特性，是由UUID+TID所组成的。其中的UUID(即server_uuid)是一个MySQL实例的唯一标识。能够实现主从自动定位和切换，而不像以前需要指定文件和位置。使用GTID复制时，主库上提交事务时创建事务对应的GTID，从库在应用中继日志时用GTID识别和跟踪每个事务。在启动新从库或因故障转移到新主库时可以使用GTID来标识复制的位置，极大地简化了这些任务。TID代表了该实例上已经提交的事务数量，并且随着事务提交单调递增。始终保留在主库和从库中，这就意味着可以通过检查其二进制日志来确定应用于任何从库的任何事务的来源。而且，一旦在给定库上提交了具有给定GTID的事务，则该库将忽略具有相同GTID的任何后续事务。因此，在主库上提交的事务只会在从库上应用一次，这也有助于保证一致性。能够保证不会重复的去执行同一个事务，并且会补全没有执行的事务。由于GTID的复制完全基于事务，因此只要在主库上提交的所有事务也在从库上提交，两者之间的一致性也就能够得到保证。

2．读写分离

如图3所示，读写分离就是将数据库分为了主从库，一个主库用于写数据，一个或多个从库完成读数据的操作，这是一种常见的数据库架构。在水电站桥（门）式启闭机科研项目中，对于启闭机的状态数据查询操作是很频繁的，但是数据库的读与写操作所消耗的时间是不一样的，写的操作比较耗时的，但是相对于写的操作来说读取10000条数据可能只需要5秒钟，所以为了消除读写冲突，提高查询效率，在读大于写的情况下，读写分离不失为一种有效方式。

图3 读写分离模式

3.部分配置信息

配置是比较重要的一环，配置好了主从库的通讯才能正常使用。在配置文件中主库和从库都要有自身的server-id，而且每一个的server-id是不能相同的。master开启log_bin选项，推荐从服务器的该选项也开启。binlog_format=row和log_slave_updates也逐步开启，后期如果slave升级为master也方便扩展。如以下所示。

将master的配置文件加入：

server_id               = 1

log_bin                 = mysql-bin

binlog_format           = ROW

将slave的配置文件加入：

server_id               = 2

log_bin                 = mysql-bin

binlog_format           = ROW

log_slave_updates= ON

read_only    = ON

super_read_only= ON

将master和slave的配置文件修改过后就可以组成一主一从的读写分离的主从复制模式，在此基础上继续加入GTID的相关配置，配置如下所示。

master的配置文件增加如下配置：

gtid_mode    = ON

enforce_gtid_consistency = ON

slave的配置文件增加如下配置：

gtid_mode    = ON

enforce_gtid_consistency = ON

配置好之后，重启master和salve服务。至此基于GTID的主从复制配置就已经完成了。

4．结语

在实际的作业环境中，对数据库的读和写操作都在同一个数据库服务器上，是不能够满足实际的需求的，无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。因此基于GTID的主从复制模式，在一定程度上保证了数据的一致性，复制数据安全性更高，故障切换更简单。再通过读写分离来提升数据库的并发负载能力，既可以解决可用性的问题，还能提高数据库的性能。

参考文献:

[1]练振兴.My SQL读写分离的技术原理[J].福建电脑,2019,35(08):49-51.DOI:10.16707/j.cnki.fjpc.2019.08.014.

[2]陈潇.SQL Server数据库性能优化策略研究[J].信息与电脑(理论版),2019,31(23):113-115.

[3]汪彦舒. 容器化分布式数据库系统的备份恢复的设计与实现[D].东南大学,2020.DOI:10.27014/d.cnki.gdnau.2020.004013.