首先说明,该配置方法尝试了DM7版本和DM8版本,在DM8版本按照配置来能保证正常,但是在DM7版本下,总会在最后启动监视器的时候,备库(读库)永远处于mount状态,无法转换到open状态.不清楚原因为何?望知悉者可以在评论区支援说明.
开始
1.达梦数据库读写分离的介绍以及连接后其内部运转
一、 系统概述
在一个高并发的事务型系统中,当写事务占的比例相对读事务相对较小时,可以借助DM7的主备系统备机可读的特点,将读事务转移到备机执行,减少单节点的并发压力,通过增加备机节点资源,提高系统的并发能力,增强系统性能。
DM8提供一种独具创新的主备方案,即时归档主备系统,该系统可通过客户端来实现读写事务的自动分离,读事务在备机执行,写事务在主机执行,减轻主机的负载。备机可以配置多个,备机配置的越多,更能分担主机的压力,系统整体并发效率越高。
二、 读写分离流程
DM8使用JDBC驱动与服务器结合的方式实现读写分离,大致流程如下:
1) 用户登录后,客户端首先连接到主机,主机根据即时归档的配置,获取一个有效的备机信息,并返回给客户端。
2) 客户端根据主机返回的备机IP和端口,建立与该备机的连接。
3) 客户端执行语句时先在备机上执行,如果是只读事务,则只在备机上执行。
4) 如果系统收到客户端试图在备机模式下修改数据等错误,则说明该事务是写事务,则转移到主机上执行。
5) 一旦主机上执行的写事务提交,则下次继续从备机开始执行。
6) 为了实现负载均衡,防止出现读事务过多占用备机资源、主机空闲的情况,客户端采用一定的算法进行均衡,主机上也会执行一部分读事务。
三、 即时归档
DM8支持多种归档类型,本地归档、实时归档、同步归档、异步归档等类型。为了实现读写分离,新增一种即时归档(Timely archive)类型,以区别实时归档。
实时归档是实时发送日志到备机,备机收到日志不会等待日志APPLY完成,立即响应给主机,主机收到响应后才刷本地日志。
即时归档是一种比实时归档更加严格的远程归档方式,先刷本地日志,然后发送到备机,并且等待备机APPLY完成,之所以要这么做,原因有2个:
首先,即时归档主备系统不会发生主备切换,在主机发送完日志到备机后刷日志前主机崩溃的情况下,不能让备机多一段日志,确保主机数据是完整且最新的。
其次,需要保证主备机的数据一致性,避免从备机读的数据到主机进行更新时数据已经不一致了。
在某些不需要保证严格一致性的情况下,可以通过dmarch.ini中的ARCH_WAIT_APPLY配置项,来配置不需要等待备机重做完日志的主备系统,类似于实时归档,可以进一步提高系统性能。
四、 事务一致性
若事务全为读操作,则全部在备机上执行。
若事务全为写操作,则全部在主机上执行。
若事务既有读又有写,备机会将写操作返回给主机执行,该事务中从写操作开始以后所有操作均在主机上执行,保证事务一致性。
五、 数据同步
配置读写分离集群之前,必须先同步主备机数据,确保两者保持完全一致;主数据库可以是新初始化的数据,也可以是正在生产、使用中的数据。DM7提供了两种方式初始化同步主备机数据,数据文件拷贝以及备份还原方式。
不能使用分别初始化库的方法,原因如下:
1) 每个库都有一个永久魔数(permenant_magic),主备机传送日志时会判断这个值是否一样,确保来自同一个库,不同的库传送不了日志
2) 由于dminit初始化数据库时,会生成随机密钥用于加密,每次生成的密钥都不相同,备机无法解析采用主机密钥加密的数据
1. 数据文件拷贝
如果搭建系统之前,数据库系统已经上线运行了,可通过拷贝数据文件的方式实现主备数据库的同步。具体步骤包括:
1) 正常关闭数据库。
2) 严格按照数据文件在主机上的分布,拷贝数据文件到备机的对应目录。
3) 如果数据文件统一存放在一个目录下,则直接拷贝整个目录即可。
2. 备份还原方式
用户也可以通过脱机备份、脱机还原的方式同步主备机数据,更详细的说明可以参考备份恢复相关文档。具体步骤包括:
1) 正常关闭数据库