DM数据库几种主备模式说明
前言
DM数据库的主备集群主要是由搭建数据守护的方式来实现。DM数据守护(DM Data Watch)的实现原理非常简单:将主库(生产库)产生的Redo日志传输到备库,备库接收并重新应用 Redo 日志,从而实现备库与主库的数据同步。在此基础下,DM通过一些参数和接口的控制可以实现实时主备、读写分离集群、异步备库和同步备库,这里主要说明这几种模式的实现方式和相互之间的区别,并引申对比Oracle、Mysql和PostgreSQL主备模式之间的对比。
数据守护
数据守护是DM主备集群的基础,主要由主库、备库、Redo日志、Redo日志传输、Redo 日志重演、守护进程(dmwatcher)、监视器(dmmonitor)组成。
1、守护进程
守护进程(dmwatcher)是 DM 数据守护系统不可或缺的核心部件,是数据库实例和监视器之间信息流转的桥梁。数据库实例向本地守护进程发送信息,接收本地守护进程的消息和命令;监视器(dmmonitor)接收守护进程的消息,并向守护进程发送命令。主要功能有:
- 监控数据库实例
- 发送状态信息
- 监控其他守护进程
- 接收监视器消息
- 主备库启动运行
- 备库故障处理
- 备库异常处理
- 主库故障处理
- 故障恢复处理
2、监视器
监视器(dmmonitor)是基于监视器接口实现的一个命令行工具,是DM数据守护系统的重要组成部分。在类型上分为 普通监视器 和 确认监视器 ,监视器的基本作用如下:
- 监控数据守护系统
- 管理数据守护系统
- 确认状态信息
- 发起故障自动接管命令
3、归档模式
3.1 说明
数据库在发生变更之后会产生对应的redo日志,并且会将redo日志写入联机redo日志文件中,通常数据库在初始化后会生成两个联机redo日志文件,此文件可以被重复覆盖写入,为了保障数据库的安全性,可以将数据库运行在归档模式下,即在redo日志写入联机redo日志文件后,还会写入归档日志文件。归档日志文件不会被覆盖或者自动删除,可以通过配置对归档日志进行定期清理或备份。
3.2 分类
归档是数据守护系统实现的重要技术手段,在数据守护系统中,主库会将自身的redo日志写入主库本地的归档日志文件中,称之为本地归档,同时还会将redo日志发送到备库中,备库也会对此日志进行归档和重演,我们可以理解成是一种远程归档。主库的归档日志内容是主库自身的redo日志,而备库是归档的主库发送过来的redo日志,并且进行redo日志重演。 根据进行redo日志传输的时机不同,可以将归档分为:实时归档、即时归档、异步归档和同步归档。
[NOTE]
在DM中远程归档是指将归档目录配置在远程节点上,并且必须双向配置远程归档,专门用于DMSDC环境中。所以上述将主库redo日志传输到备库后进行归档,我们理解成远程归档,并不是DM中真正的远程归档定义,只是便于理解。
-
实时归档
实时归档(Realtime)是在主库在Redo日志(RLOG_PKG)写入联机日志文件前,将Redo日志发送到备库。 -
即时归档
即时归档(Timely)在主库将Redo日志写入联机日志文件后,通过MAL系统将Redo日志发送到备库。即时归档与实时归档的主要区别是Redo日志的发送时机不同。[NOTE]
实时归档和即时归档在根据响应主库的时间点不同下,可以分为事务一致模式和高性能模式。事务一致模式下需要等备库收到redo日志并完成重演后再响应主库;高性能模式下备库收到redo日志后就马上响应主库,再启动日志重演。实时归档默认配置时是高性能模式,即时归档默认配置时是事务一致模式。 -
异步归档
异步归档(Async)由主、备库上配置的定时器触发,根据异步备库的KEEP LSN 信息,扫描本地归档目录获取Redo日志,并通过MAL系统将Redo日志发送到异步备库。 -
同步归档
同步归档(Sync)在主库归档日志刷盘后,通过MAL系统将Redo日志发送到备库。
3.3 归档区别对比
实时归档 | 即时归档 | 异步归档 | 同步归档 | |
---|---|---|---|---|
归档时机 | 写入联机日志前,发送到备库 | 写入联机日志后,发送到备库 | 定时启动 | 写入归档日志后,发送到备库 |
备库响应时机 | 事务一致模式:重演完成后响应;高性能模式:收到立即响应 | 事务一致模式:重演完成后响应;高性能模式:收到立即响应 | 收到立即响应 | 收到立即响应 |
4、配置文件说明
与DM数据守护相关的配置文件包括:
- 数据库配置文件dm.ini
- MAL配置文件dmmal.ini
- Redo日志归档配置文件dmarch.ini
- 守护进程配置文件dmwatcher.ini
- 监视器配置文件dmmonitor.ini
- 定时器配置文件dmtimer.ini
4.1 dm.ini
无论哪中主备模式,都需要配置当前数据库的dm.ini文件,主要需要修改的参数如下:
INSTANCE_NAME = GRP1_RT_01 #实例名,建议使用―组名_守护环境_序号‖的命名方式,总长度不能超过16
PORT_NUM = 32141 #数据库实例监听端口
DW_INACTIVE_INTERVAL = 60 #接收守护进程消息超时时间
ALTER_MODE_STATUS = 0 #不允许手工方式修改实例模式/状态/OGUID
ENABLE_OFFLINE_TS = 2 #不允许备库OFFLINE表空间
MAL_INI = 1 #打开MAL系统
ARCH_INI = 1 #打开归档配置
RLOG_SEND_APPLY_MON = 64 #统计最近64次的日志发送信息
4.2 dmmal.ini
dmmal.ini是MAL配置文件。需要用到MAL环境的实例,所有站点dmmal.ini需要保证严格一致。根据不同的主备模式添加对应节点的mal配置信息,举例如下:
MAL_CHECK_INTERVAL = 5 #MAL链路检测时间间隔
MAL_CONN_FAIL_INTERVAL = 5 #判定MAL链路断开的时间
[MAL_INST1]
MAL_INST_NAME = GRP1_RT_01 #实例名,和dm.ini中的INSTANCE_NAME一致
MAL_HOST = 192.168.0.141 #MAL系统监听TCP连接的IP地址
MAL_PORT = 61141 #MAL系统监听TCP连接的端口
MAL_INST_HOST = 192.168.1.131 #实例的对外服务IP地址
MAL_INST_PORT = 32141 #实例的对外服务端口,和dm.ini中的PORT_NUM一致
MAL_DW_PORT = 52141 #实例本地的守护进程监听TCP连接的端口
MAL_INST_DW_PORT = 33141 #实例监听守护进程TCP连接的端口
[MAL_INST2]
MAL_INST_NAME = GRP1_RT_02
MAL_HOST = 192.168.0.142
MAL_PORT = 61142
MAL_INST_HOST = 192.168.1.132
MAL_INST_PORT = 32142
MAL_DW_PORT = 52142
MAL_INST_DW_PORT = 33142
4.3 dmarch.ini
dmarch.ini是Redo日志归档配置文件,其中
-
ARCH_WAIT_APPLY
参数表示备库收到Redo日志后,是否需要重演完成后再响应主库。0表示收到马上响应(高性能模式),1表示重演完成后响应(事务一致模式)。配置为即时归档的读写分离集群时,缺省值为1;配置为实时归档的读写分离集群时,缺省值为0; -
[ARCH_NAME]
参数表示Redo日志归档名,由于“STANDBY_ARCHIVE”用于表示备库生成的归档日志,因此不允许将归档名称配置为“STANDBY_ARCHIVE”;
还有一些其他参数,例如如下实时归档的配置:
[ARCHIVE_REALTIME]
ARCH_TYPE = REALTIME #实时归档类型
ARCH_DEST = GRP1_RT_02 #实时归档目标实例名
[ARCHIVE_LOCAL1]
ARCH_TYPE = LOCAL #本地归档类型
ARCH_DEST = /dm/data/DAMENG/arch #本地归档文件存放路径
ARCH_FILE_SIZE = 128 #单位Mb,本地单个归档文件最大值
ARCH_SPACE_LIMIT = 0 #单位Mb,0表示无限制,范围1024~2147483647M
4.4 dmwatcher.ini
dmwatcher.ini是守护进程配置文件,其中:
[GROUP_NAME]
守护进程组名(长度不能超过16;DW_TYPE
守护类型,缺省为LOCAL,LOCAL:本地守护,GLOBAL:全局守护;DW_MODE
切换模式,缺省为MANUAL,MANUAL:故障手动切换模式,AUTO:故障自动切换模式;INST_OGUID
数据守护唯一标识码,同一守护进程组中的所有数据库、守护进程和监视;
还有一些其他参数,例如如下实时归档的配置:
[GRP1]
DW_TYPE = GLOBAL #全局守护类型
DW_MODE = AUTO #自动切换模式
DW_ERROR_TIME = 10 #远程守护进程故障认定时间
INST_RECOVER_TIME = 60 #主库守护进程启动恢复的间隔时间
INST_ERROR_TIME = 10 #本地实例故障认定时间
INST_OGUID = 453331 #守护系统唯一OGUID值
INST_INI = /dm/data/DAMENG/dm.ini #dm.ini配置文件路径
INST_AUTO_RESTART = 1 #打开实例的自动启动功能
INST_STARTUP_CMD = /dm/bin/dmserver #命令行方式启动
RLOG_SEND_THRESHOLD = 0 #指定主库发送日志到备库的时间阈值,默认关闭
RLOG_APPLY_THRESHOLD = 0 #指定备库重演日志的时间阈值,默认关闭
4.5 dmmonitor.ini
dmmonitor.ini是监视器配置文件,其中:
MON_DW_CONFIRM
是否配置为确认模式,缺省为0。0:监控模式 1:确认模式;[GROUP_NAME]
守护进程组名,与dmwatcher.ini中的守护进程组名保持一致
具体参考如下:
MON_DW_CONFIRM = 1 #确认监视器模式
MON_LOG_PATH = /dm/data/log #监视器日志文件存放路径
MON_LOG_INTERVAL = 60 #每隔60s定时记录系统信息到日志文件
MON_LOG_FILE_SIZE = 32 #每个日志文件最大32M
MON_LOG_SPACE_LIMIT = 0 #不限定日志文件总占用空间
[GRP1]
MON_INST_OGUID = 453331 #组GRP1的唯一OGUID值
#以下配置为监视器到组GRP1的守护进程的连接信息,以―IP:PORT‖的形式配置
#IP 对应dmmal.ini中的MAL_HOST,PORT对应dmmal.ini中的MAL_DW_PORT
MON_DW_IP = 192.168.0.141:52141
MON_DW_IP = 192.168.0.142:52142
4.6 dmtimer.ini
dmtimer.ini 用于配置定时器,可记录异步备库的定时器信息,其中:
[TIMER_NAME1]
定时器名称。例如,名为RT的定时器,名称书写方式为[RT];TYPE
定时器调度类型- 1:执行一次。时间上只需要指定DURING_START_DATE 即可,不需要指定START_TIME、END_TIME和DURING_END_DATE
- 2:按日执行
- 3:按周执行
- 4:按月执行的第几天
- 5:按月执行的第一周
- 6:按月执行的第二周
- 7:按月执行的第三周
- 8:按月执行的第四周
- 9:按月执行的最后一周
- 10: 按REPEAT_INTERVAL 指定的日历表达式的频率进行。不再需要通过START_TIME 、 END_TIME 、 DURING_START_DATE 和DURING_END_DATE 指定时间
下面示例中定时器配置为每天00:00:00触发主库发送归档日志到异步备库:
[RT_TIMER] #和dmarch.ini中的ARCH_TIMER_NAME一致
TYPE = 2
FREQ_MONTH_WEEK_INTERVAL = 1
FREQ_SUB_INTERVAL = 0
FREQ_MINUTE_INTERVAL = 0
START_TIME = 00:00:00
END_TIME = 00:00:00
DURING_START_DATE = 2016-02-11 17:36:09
DURING_END_DATE = 9999-12-31 23:59:59
NO_END_DATE_FLAG = 1
DESCRIBE = RT TIMER
IS_VALID = 1
几种主备集群的对比
1、基础配置
几种以数据守护为基础实现的主备集群模式,在基础配置上大多数都是相同的:
-
从库数据准备
DM中配置主备模式时,备库需要先通过对主库进行备份还原的方式来得到。 -
分别配置主备库
主要是配置上述的几个参数文件,多数的参数配置要求都是相同的,主要是在归档模式的配置上所有区别,另读写分离集群还需要通过配置对应接口得以实现。 -
设置OGUID和数据库模式
SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1); sp_set_oguid(453331); alter database primary; SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);
以上是在主库上配置,在备库上需要将primary修改为standby。
-
启动数据库和守护进程
主备库都需要以mount的方式启动,然后启动对应的守护进程后会自动将数据库切换到open状态。 -
配置监视器
需要自动处理故障的功能并搭配守护进程配置的自动切换模式,需要配置确认监视器。
2、实时主备
实时主备在定义实例名和设置归档模式时做特定调整:
-
根据实例名的建议使用规则,在配置实时主备时可以将主备库实例名定为
GRP1_RT_01
和GRP1_RT_02
; -
归档配置中除了本地归档配置外再配置实时归档,并设置好归档类型和归档目标,并且实时归档模式下
ARCH_WAIT_APPLY
参数缺省值为0,即采用高性能模式:[ARCHIVE_REALTIME] # 实时归档名称 ARCH_TYPE = REALTIME # 实时归档类型 ARCH_DEST = GRP1_RT_02 # 实时归档目标实例名,主库的归档目标是备库,在备库上配置时归档目标应设置成主库
3、读写分离集群
读写分离集群除了在定义实例名和设置归档模式时做特定调整外,还需要在配置接口时定义读写分离配置:
-
根据实例名的建议使用规则,在配置实时主备时可以将主备库实例名定为
GRP1_RWW_01
和GRP1_RWW_02
; -
读写分离集群通常为了保证在备库的事务一致性,在归档配置时会选择即时归档模式,此时
ARCH_WAIT_APPLY
参数缺省值为1,即采用事务一致性模式:[ARCHIVE_TIMELY1] ARCH_TYPE = TIMELY #即时归档类型 ARCH_DEST = GRP1_RWW_02 #即时归档目标实例名,设置归档目标时注意主备库的区别 [ARCHIVE_TIMELY2] ARCH_TYPE = TIMELY ARCH_DEST = GRP1_RWW_03
-
读写分离环境搭建完成后应用在连接数据库时,在对应接口上还需要配置读写分离,不同的接口可能使用的具体参数不同,大同小异的是都是配置是否使用读写分离系统的参数和分发到主库的事务占主备库总事务的百分比的参数,例如:
-
JDBC接口中需要设置
rwSeparate
和rwPercent
连接属性:<DRIVER>dm.jdbc.driver.DmDriver</DRIVER> <URL>jdbc:dm://192.168.0.206:5236?rwSeparate=1&rwPercent=10</URL>
-
ODBC接口中需要设置
RW_SEPARATE
和RW_SEPARATE_PERCENT
关键字:"DSN=DM8;DRIVER=DM ODBC DRIVER;UID=SYSDBA;PWD=SYSDBA;TCP_PORT=5236;RW_SEPARATE=TRUE;RW_SEPARATE_PERCENT=25"
-
dmPython接口中支持
rwseparate
和rwseparate_percent
两个读写分离的连接属性:import dmPython conn = dmPython.connect(rwseparate=True, rwseparate_percent=25)
[NOTE]
更多的DM接口配置说明可以查看官方文档《程序员手册》。 -
4、配置异步备库
在实际应用中,如果数据库规模很大,并且对数据的实时性要求不是很严格,则可以配置多个异步备库用于分担统计报表等任务。异步备库支持多源配置,主要目的是在主备环境中发生主备切换时可以继续向同一个异步备库同步数据。以实时主备环境为例,为实时主备环境中的主备库添加同一个异步备库,主备库中的配置文件都需要做修改:
-
在dm.ini中需要打开定时器配置,其他配置不变
#配置有异步归档时,打开定时器,定时同步归档到异备库 TIMER_INI = 1
-
在dmmal.ini中需要再添加异步备库的对应配置
[MAL_INST3] MAL_INST_NAME = GRP1_LOCAL_01 #实例名,和dm.ini中的INSTANCE_NAME一致 MAL_HOST = 192.168.0.143 MAL_PORT = 61143 MAL_INST_HOST = 192.168.1.133 MAL_INST_PORT = 32143 MAL_DW_PORT = 52143 MAL_INST_DW_PORT = 33143
-
在dmarch.ini中需要加上异步归档配置
[ARCHIVE_ASYNC] ARCH_TYPE = ASYNC #异步归档类型 ARCH_DEST = GRP1_LOCAL_01 #异步归档目标实例名 ARCH_TIMER_NAME = RT_TIMER #定时器名称,和dmtimer.ini中的名称一致
-
配置dmtimer.ini文件
下面示例中定时器配置为每天00:00:00触发主库发送归档日志到异步备库,可以根据实际情况再做调整:[RT_TIMER] #和dmarch.ini中的ARCH_TIMER_NAME一致 TYPE = 2 FREQ_MONTH_WEEK_INTERVAL = 1 FREQ_SUB_INTERVAL = 0 FREQ_MINUTE_INTERVAL = 0 START_TIME = 00:00:00 END_TIME = 00:00:00 DURING_START_DATE = 2016-02-11 17:36:09 DURING_END_DATE = 9999-12-31 23:59:59 NO_END_DATE_FLAG = 1 DESCRIBE = RT TIMER IS_VALID = 1
-
以上在实时主备库上修改之后还需要配置异步备库,主要也是修改dm.ini中的实例名等,注意异步备库不具备故障自动切换功能,因此异步备库上的dmwatcher.ini文件中参数
DW_MODE
设置为MANUAL
即可,另配置为本地守护模式。
5、配置同步备库
同步备库也支持多源配置,我们还是以实时主备环境为例,为实时主备配置一台同步备库,先配置主备中的配置文件:
-
需要在dmmal.ini文件中添加同步备库的配置项;
-
在dmarch.ini文件中增加同步归档的配置
[ARCHIVE_SYNC] ARCH_TYPE = SYNC #同步归档类型 ARCH_DEST = GRP1_SYNC_01 #同步归档目标实例名 ARCH_RECOVER_TIME = 1 #同步备库的异步恢复间隔
-
在实时主备上的配置修改完成后,同步备库上主要是修改实例名,然后只需要配置本地归档即可,同样注意同步备库不具备故障自动切换功能,因此同步备库上的dmwatcher.ini文件中参数
DW_MODE
设置为MANUAL
即可,另配置为本地守护模式。
DM主备模式与其他数据库主备模式对比
1、对比Mysql
1.1 基本原理
Mysql是通过在备库上执行change master
命令,设置主库IP、端口、用户名、密码,以及要从哪个位置开始请求binlog,包含文件名和偏移量,然后通过start slave
命令,备库会启动两个线程即io_thread和sql_thread,其中io_thread线程负责与主库连接并接受主库发送的binlog,备库拿到binlog后先写入本地文件(relay log),然后sql_thread线程读取relay log中的内容进行解析并执行,以达到同步主库数据的目的。
1.2 对比
- 整体来说DM和Mysql都是通过日志的传输和重演来实现数据同步的,DM是redo日志,Mysql则是binlog;
- Mysql默认的是异步同步,与DM的实时主备默认采用高性能模式类似,即将binlog日志发送给备库后不会关心备库是否有将binlog写入relay log,也不会关系后续relay log是否有被解析执行;后续通过安装插件可以实现半异步同步,即主库会等到备库接受到binlog并将其写入relay log后才会响应客户请求,类似与DM的默认即时归档配置下采用的事务一致性模式;
- Mysql的读写分离需要通过程序代码内部或者是中间代理来实现,DM是通过配置接口实现。
2、对比PostgreSQL
2.1 基本原理
PostgreSQL支持物理复制和逻辑复制,逻辑复制基于对WAL进行逻辑解析后执行,生成环境中PG的主备常用的还是物理复制也可以称之为流复制。即主服务器在WAL记录产生时即将它们以流式传送给备服务器,备服务器接受到WAL数据后,按照相同的顺序应用到自己的数据库上,然后将已经应用的WAL数据库持久化到磁盘,并确认接受到的数据已经应用成功。
2.1 对比
- PG的主备数据同步基于WAL,即预写日志,记录所有的数据更改操作,类似与DM的redo日志;
- PG的流复制默认也是异步的,即异步流复制下主库无需等待备库响应已应用数据后才能继续处理客户请求,提高了性能,但是会有一定的数据延迟。当然PG也提供了同步流复制,即主库必须等待备库反馈已经成功应用完数据库后才能继续响应客户,这样保证了数据的一致性,但是损失了部分性能;
- PG可以通过pgpool来实现读写分离,pgpool是是一个位于 PostgreSQL 服务器和 PostgreSQL 数据库客户端之间的中间件,它除了可以实现读写分离,还可以用于负载均衡、监控数据库状态、主备切换等功能。对比DM数据守护来说,类似守护进行和监视器的结合。
3、对比Oracle
3.1 基本原理
Oracle的DATAGUARD就是一种常用的主备模式,基本原理是将日志文件从原数据库传输到目标数据库,然后在目标数据库上应用这些日志文件,从而使目标数据库与源数据库保持同步,是一种数据库级别的高可用方案。
3.2 对比
- Oracle Data Guard也是通过redo日志的传输和重演来实现数据同步;
- 有三种保护模式,即最大保护、最大可用性和最大性能。最大保护模式下,要求所有的事务在提交前其redo不仅写入到本地的联机日志文件中,还要同时写入到备库的standby redologs,并确认redo数据至少在一个备库中可用,类似于DM的即时归档的事务一致性模式;最大性能模式下,保证了主库性能最大化,主备库之间数据是异步传输的,即主日志归档后才会传输到备用库上,类似于DM的同步备库;最大可用性模式下,常规与最大保护类似,但是若有备库故障,主备不会被关闭而是转为最大性能模式;
- Oracle的读写分离可以通过自身组件来实现,例如ADG等,也可以通过独立的中间件如mycat配置来实现。
4、总结
数据库类型 | 集群类型 | 实现原理 | 读写分离 | 异步/同步 | 配置区别 | 备注 |
DM | 实时主备 | 以DM数据守护为基础,在归档配置时采用实时归档,默认是使用高性能模式 | / | 默认高性能模式即异步复制 | 归档模式是实时归档,即dmarch.ini中ARCH_TYPE参数值为REALTIME,且默认ARCH_WAIT_APPLY参数值为0,采用高性能模式 | 类似与Mysql的主从模式、PG的异步流复制和Oracle的最大性能模式 |
读写分离集群 | 以DM数据守护为基础,在归档配置时采用即时归档,默认是使用事务一致性模式 | 在接口上配置读写分离 | 默认事务一致性模式即同步复制 | 归档模式是即时归档,即dmarch.ini中ARCH_TYPE参数值为TIMELY,且默认ARCH_WAIT_APPLY参数值为1,采用事务一致性模式 | 类似与PG的同步流复制和oracle的最大保护模式 | |
异步备库 | 以DM数据守护为基础,在归档配置时采用异步归档,即根据dmtimer.ini中配置的规则在指定的时间点上扫描本地归档获取日志后传输给备库后,备库在做重演 | / | 异步复制 | 归档模式是异步归档,参数ARCH_TYPE为ASYNC,同时需要打开定时器,并且配置好dmtimer.ini文件,不具备故障自动切换功能,守护进程是本地守护 | / | |
同步备库 | 以DM数据守护为基础,在归档配置时采用同步归档,即在本地归档日志刷盘后才会传输给备库 | / | 异步复制 | 归档模式是同步归档,参数ARCH_TYPE为SYNC,不具备故障自动切换功能,守护进程是本地守护 | 归档方式上与oracle的最大性能模式类似 | |
Mysql | 主从模式 | 备库上通过change master命令配置好跟主库的连接,并启动io_thread和sql_thread两个线程,io_thread负责接受主库传输的binlog日志,并先写入备库的relay sql后,sql_thread线程负责读取relay log并解析内容和执行,以实现与主库的数据同步 | 通过程序代码层或者中间件如mycat来实现 | 默认是异步复制,可以配置半同步或者完全同步,但是会牺牲性能 | / | 对比DM,与之实时主备类似 |
PostgreSQL | 异步流复制 | PG的流复制是属于物理复制,即主服务器在WAL产生记录时就会以流的方式传输给备服务器,备服务器接受到后会以相同的顺序应用到自己的库当中,再将日志做本地持久化,以实现与主库的数据同步。异步流复制主要在于主库将WAL日志发送给备库后即可提交事务 | 可以通过pgpool来实现 | 异步复制 | 由参数synchronous_standby_names来配置同步备库列表 | 对比DM,与之实时主备类似 |
同步流复制 | PG的同步流复制实现原理与异步流基本相同,主要区别在于同步流复制中主库需要等备库应用了WAL日志后并给主库一个响应,主库才能提交事务 | 可以通过pgpool来实现 | 同步复制 | 由参数synchronous_standby_names来配置同步备库列表 | 对比DM,与之读写分离集群类似 | |
Oracle | DataGuard 最大保护模式 | 最大保护模式下,要求所有的事务在提交前其redo不仅写入到本地的联机日志文件中,还要同时写入到备库的standby redologs,并确认redo数据至少在一个备库中可用 | 自身组件如ADG或独立中间件如mycal来实现 | 同步 | 日志传输进程为LGWR,传输模式为SYNC,写磁盘模式为AFFIRM,备份端需要由STANDBY LOGFILE | 对比DM,与之读写分离集群类似 |
DataGuard最大可用性模式 | 最大可用性模式实现方式与最大保护模式类似,也是要求本地事务在提交前必须至少写入一台Standby数据库的Standby Redologs中,不过与之不同的是,如果出现故障导致Standby数据库无法访问,Primary数据库并不会被Shutdown,而是自动转为最高性能模式,等Standby数据库恢复正常之后,Primary数据库又会自动转换成最高可用性模式 | 自身组件如ADG或独立中间件如mycal来实现 | 异步和同步 | LGWR;SYNC;AFFIRM;STANDBY LOGFILE | / | |
DataGuard最大性能模式 | 最大性能模式下,事务可以随时提交,当前Primary数据库的REDO数据至少需要写入一个Standby数据库,不过这种写入可以是不同步的 | 自身组件如ADG或独立中间件如mycal来实现 | 异步 | LGWR或ARCH;LGWR进程时SYNC或ASYNC,ARCH进程时SYNC;AFFIRM或NOAFFIRM;可没有但推荐有 | 对比DM,与实时主备类似,归档上类似于DM的同步归档 |
更多的内容可以登录达梦的社区进行查看:https://eco.dameng.com