1.概述
读写分离集群是基于即时归档或实时归档实现的高性能数据库集群，不但提供数据保护、容灾等数据守护基本功能，还具有读写操作自动分离、负载均衡等特性。读写分离集群最多可以配置 8 个即时备库或 8 个实时备库，提供数据同步、备库故障自动处理、故障恢复自动数据同步等功能，也支持自动故障切换和手动故障切换两种守护模式。
在一个高并发的事务型系统中，当写事务占的比例相对读事务相对较小时，可以借助 DM 数据库的主备系统备机可读的特点，将读事务转移到备机执行，减少单节点的并发压力，通过增加备机节点资源，提高系统的并发能力，增强系统性能。
DM 数据库提供一种独具创新的主备方案，即时归档主备系统，该系统可通过客户端来实现读写事务的自动分离，读事务在备机执行，写事务在主机执行，减轻主机的负载。备机可以配置多个，备机配置的越多，更能分担主机的压力，系统整体并发效率越高。
2.读写分离环境配置说明


A.测试读写分离的可用性：
[root@dataguard-pri ~]# su dmdba
[dmdba@dataguard-pri root]$ cd /dmsoft/bin
[dmdba@dataguard-pri bin]$ ./disql SYSDBA/Dameng_123

服务器[LOCALHOST:5236]:处于主库打开状态
登录使用时间 : 3.671(ms)
disql V8
SQL> CREATE TABLE TEST_1 (ID INT,NAME VARCHAR(20));
操作已执行
已用时间: 46.976(毫秒). 执行号:600.
SQL> INSERT INTO TEST_1 VALUES (1,'LOU'),(2,'XIN'),(3,'RU');
影响行数 3

已用时间: 0.753(毫秒). 执行号:601.
SQL> COMMIT;
操作已执行
已用时间: 4.527(毫秒). 执行号:602.
SQL> SELECT * FROM TEST_1;

行号 ID NAME

---

1 1 LOU
2 2 XIN
3 3 RU

已用时间: 0.607(毫秒). 执行号:603.
前往读库验证数据是否能够正常同步：
[root@dataguard-sec ~]# su dmdba
[dmdba@dataguard-sec root]$ cd /dmsoft/bin
[dmdba@dataguard-sec bin]$ ./disql SYSDBA/Dameng_123

服务器[LOCALHOST:5236]:处于备库打开状态
登录使用时间 : 3.763(ms)
disql V8
SQL> DESC TEST_1;

行号 NAME TYPE$ NULLABLE

---

1 ID INTEGER Y
2 NAME VARCHAR(20) Y

已用时间: 20.751(毫秒). 执行号:0.
SQL> SELECT * FROM TEST_1;

行号 ID NAME

---

1 1 LOU
2 2 XIN
3 3 RU

已用时间: 0.586(毫秒). 执行号:1.

读写分离集群可以正常运行

B.制造主机故障，测试备机可接管并持续提供服务
1)主库机器DOWN机时：
[root@dataguard-pri ~]# shutdown -h


[dmdba@dataguard-sec bin]$ ./disql SYSDBA/Dameng_123

服务器[LOCALHOST:5236]:处于主库打开状态
登录使用时间 : 2.563(ms)
disql V8
SQL> CREATE TABLE TEST_2 (ID INT);
操作已执行
已用时间: 30.522(毫秒). 执行号:700.
SQL> INSERT INTO TEST_2 VALUES (1),(3);
影响行数 2

已用时间: 0.639(毫秒). 执行号:701.
SQL> COMMIT;
操作已执行
已用时间: 3.713(毫秒). 执行号:702.
SQL> SELECT * FROM TEST_2;

行号 ID

---

1 1
2 3

已用时间: 0.553(毫秒). 执行号:703.
原先的只读库变成主库现在可读可写。
启动原主库机器：


原主库机器启动后，自动加入集群，变成只读从库。
[dmdba@dataguard-pri bin]$ ./disql SYSDBA/Dameng_123

服务器[LOCALHOST:5236]:处于备库打开状态
登录使用时间 : 3.717(ms)
disql V8
SQL> SELECT * FROM TEST_2;

行号 ID

---

1 1
2 3

已用时间: 35.814(毫秒). 执行号:0.
新从库可以看到新主库之前建的表。

2)当主库数据库被关闭时：



现主库只是短暂的出现错误，然后迅速被守护进程拉起数据库服务。

3)将集群修改成主备+事务一致性，当主库机器断网时：
[root@dataguard-pri DAMENG]# ifdown enp0s3


现在主库切换到了GRP1_RT_02机器。
[dmdba@dataguard-sec bin]$ ./disql SYSDBA/Dameng_123

服务器[LOCALHOST:5236]:处于主库打开状态
登录使用时间 : 3.343(ms)
disql V8
SQL> CREATE TABLE TEST_3(ID INT);
操作已执行
已用时间: 55.593(毫秒). 执行号:700.
SQL> INSERT INTO TEST_3 VALUES (1),(2),(3);
影响行数 3

已用时间: 1.359(毫秒). 执行号:701.
SQL> COMMIT;
操作已执行
已用时间: 1.071(毫秒). 执行号:702.
SQL> SELECT * FROM TEST_3;

行号 ID

---

1 1
2 2
3 3

已用时间: 0.702(毫秒). 执行号:703.
打开GRP1_RT_01的网络



可以看到故障主机已经自动加入集群，且由主库变成了备库。
[dmdba@dataguard-sec bin]$ ./disql SYSDBA/Dameng_123

服务器[LOCALHOST:5236]:处于主库打开状态
登录使用时间 : 3.313(ms)
disql V8
SQL> CREATE TABLE TEST_4 (ID INT);
操作已执行
已用时间: 18.955(毫秒). 执行号:800.
SQL> INSERT INTO TEST_4 VALUES (1),(5);
影响行数 2

已用时间: 0.654(毫秒). 执行号:801.
SQL> COMMIT;
操作已执行
已用时间: 5.004(毫秒). 执行号:802.
SQL> SELECT * FROM TEST_4;

行号 ID

---

1 1
2 5

已用时间: 0.545(毫秒). 执行号:803.
GRP1_RT_02现在变成主机，可读可写。
[dmdba@dataguard-pri bin]$ ./disql SYSDBA/Dameng_123

服务器[LOCALHOST:5236]:处于备库打开状态
登录使用时间 : 3.598(ms)
disql V8
SQL> DESC TEST_4;

行号 NAME TYPE$ NULLABLE

---

1 ID INTEGER Y

已用时间: 23.081(毫秒). 执行号:0.
SQL> SELECT * FROM TEST_4;

行号 ID

---

1 1
2 5

已用时间: 0.607(毫秒). 执行号:1.
SQL> CREATE TABLE TEST_5 (ID INT);
CREATE TABLE TEST_5 (ID INT);
[-710]:试图在STANDBY模式下，修改用户库.
已用时间: 0.204(毫秒). 执行号:0.
GRP1_RT_01由主库变备库，只读不可写。

4)手动切换主备集群，恢复原主备集群的位置：


可以看出，现在GRP1_RT_01重新成为主库。

5)测试读事务自动分发到备机的过程：
在windows中C:\Windows\System32目录下配置 dm_svc.conf文件
TIME_ZONE=(480)
LANGUAGE=(cn)
DMRW=(192.168.100.11:5236,192.168.100.12:5236)

[DMRW]
LOGIN_MODE=(3) # 优先连接Standby模式的库，Primary模式次之，最后选择Normal模式
RW_SEPARATE=(1)
RW_PERCENT=(0) #读全部在从库
SWITCH_TIMES=(60)
SWITCH_INTERVAL=(200)

SELECT 默认在从库上。

使用BEGIN...END时，为了保证一致性，INSERT，SELECT都在主库。

写入时使用主库，读取时，使用从库。



3.总结

(1)根据读写分离语句分发流程可以发现，当一个应用系统中只读事务占绝大多数情况下，可能出现备库高负载、高压力，主库反而比较空闲的情况。为了实现负载均衡，更好地利用主备库的硬件资源，数据库接口提供了配置项，允许将一定比例的只读事务分发到主库执行。因此，用户应该根据主备库的负载情况，灵活调整接口的分发比例RW_PERCENT配置项，以获得最佳的数据库性能。

(2)备库数量是影响读写分离集群性能的一个重要因素，备库越多则每个备库需要承担的任务越少，有助于提升系统整体并发效率。但是在事务一致模式下，主库要等所有备库重演 REDO 日志完成后，才能响应用户，随着备库的增加，即时归档时间会变长，最终降低非只读事务的响应速度。因此，部署多少备库，也需要综合考虑硬件资源、系统性能等各种因素。

(3)建议将读写分离集群修改成主备+事务一致性
即dmarch.ini中配置

ARCH_WAIT_APPLY = 1

[ARCHIVE_REALTIME]
ARCH_TYPE = REALTIME #实时归档类型
ARCH_DEST = *** #实时归档目标实例名

(4)和即时归档不同的是，实时归档先发送日志到备库，然后再写入本地联机日志，和即时归档相比，实时归档的读写分离可以有效避免备库自动接管后老主库的分裂，在对读写分离集群的可用性要求比较高的情况下，可以采用这种配置方式。