1 安装前准备
1.1 软硬件配置建议
最好确保各节点间的操作系统、CPU等服务器配置保持一致,否则可能会严重影响集群的整体性能,尤其是故障切换后可能存在响应服务请求慢的情况;
心跳系统对MAL的影响程度较大,如果网络丢包或延迟过大,则会影响系统对于节点状态的判断,严重影响MAL系统的处理能力,导致整个集群响应变慢。为保证集群稳定性,对网络环境的建议配置如下:
- 使用千兆或千兆以上网络;
- 集群间的心跳同步数据时,尽量使用两个交换机构建内网,以实现冗余和负载均衡;
- 两个网卡(使用bond方式等)联结成一个逻辑网卡使用。一般来说,这对外提供一个统一的虚拟网络接口,以提高带宽和冗余度;在Linux中,存在负载均衡(balance-rr)、主动-备用(active-backup)、链路聚合(802.3ad)等方式。
对Vote Disk和DCR Disk / DCRV的简述:
- Vote Disk:主要用于集群仲裁和故障检测,确保在网络分区或节点故障时保持集群的一致性和高可用性;它通过投票机制来决定哪些节点可以继续运行;
- DCR Disk(Disk Configuration Repository Disk):主要用于存储和管理集群配置和状态信息,帮助集群管理系统进行监控、配置和故障恢复。它确保集群在节点故障或重启后能够快速恢复正常运行。
- DCR V(Disk Configuration Repository Volume,磁盘配置存储卷):是用于存储和管理高可用性集群系统中关键配置和状态信息的磁盘卷,基本功能同DCR Disk,只是作业单位不同。
1.2 集群规划
官方文档给出的当在A / B机器上使用两个独立显卡分别承担独立的业务网络IP和心跳网络IP情形下的理论集群规划表如下。在A机器和B机器之外配置确认监视器IP为10.10.10.10。监视器一般设置在独立于主备节点之外的机器上:
A 机器 | B 机器 | |
---|---|---|
业务 IP | 172.16.1.1 | 172.16.1.2 |
心跳 IP | 192.168.1.1 | 192.168.1.2 |
实例名 | GRP1_RT_01 | GRP1_RT_02 |
实例端口 | 5236 | 5236 |
MAL 端口 | 5336 | 5336 |
MAL 守护进程端口 | 5436 | 5436 |
守护进程端口 | 5536 | 5536 |
OGUID | 45331 | 45331 |
守护组 | GRP1 | GRP1 |
安装目录 | /home/dmdba/dmdbms | /home/dmdba/dmdbms |
实例目录 | /dmdata/data | /dmdata/data |
归档上限 | 51200 | 51200 |
通常,心跳IP会配置在一个独立的网络 / 虚拟局域网VLAN上,该网络与业务网络隔离,以确保心跳信号的可靠传输,其实现方式包括独立网卡(适用于数据中心等高可用集群)、VLAN和软件定义网络SDN等,我们这里为简化配置,选择在同一宿主机上用不同的Container的端口映射实现。
1.3 集群架构
搭建的主备集群架构如下图1-1:
1.4 切换模式说明
故障切换方式 | dmarch | dmwatcher | dmmonitor | 监视器要求 |
---|---|---|---|---|
故障手动切换 | ARCH_WAIT_APPLY=0 | DW_MODE=MANUAL | MON_DW_CONFIRM=0 | 1. 配置手动切换:集群各节点的 bin 目录中,存放非确认监视器配置文件。 |
故障自动切换 | ARCH_WAIT_APPLY=0 | DW_MODE=AUTO | MON_DW_CONFIRM=1 | 1. 配置手动切换:集群各节点的 bin 目录中,存放非确认监视器配置文件。 2. 配置自动切换:在确认监视器上(非集群节点),存放确认监视器配置文件,并注册后台自启服务。 |
对ARCH_WAIT_APPLY参数解释如下:
- 该配置用于指定:当备库收到Redo日志后,是否在重演完成之后再响应主库;
- 有两个值可选:当值为0时,备库在收到后立即响应(高性能模式);当值为1时,备库在重演完成后响应(事务一致模式)。
- 配置为及时归档(Timely Archiving)时,默认值为0;配置为实时归档(Real-time Archiving)时,默认值为1;
- 故障手动切换情境下 ARCH_WAIT_APPLY 只能为 0。故障自动切换情境下 ARCH_WAIT_APPLY 可以为 0,也可以为 1。
ARCH_WAIT_APPLY 参数设置的判断依据为业务是否要查询备机最新数据。如果需要,则配置为 1(较大性能衰减);如果不需要,则配置为 0。
2 集群搭建
这里我们使用Docker容器来模拟集群的搭建。
由图1-1所知,在实际生产环境中本次需要用到3台机器,分别作为主库、备库和监视器;而通过Docker,我们可以在同一台主机上创建3个Container来模拟实现,分别用数据库实例A,数据库实例B和监视器C指代。
2.1 配置A机器
2.1.1 创建Business和Heartbeat网络
创建自定义网络并指定子网的命令如下:
[dmdba@VM-8-6-centos ~]$ docker network create --subnet=172.16.1.0/24 dmwatch-test-business
870c978be7747a6922eece5ad9eb960e30190fd0cf4891d16126f9b21eb43e43
[dmdba@VM-8-6-centos ~]$ docker network create --subnet=192.168.1.0/24 dmwatch-test-heartbeat
f0c46f65d5ee0529fead4335f5c34b8c803a248edf8a66f643849412a52c6348
[dmdba@VM-8-6-centos ~]$ docker network ls
NETWORK ID NAME DRIVER SCOPE
a43284433c5f bridge bridge local
870c978be774 dmwatch-test-business bridge local
f0c46f65d5ee dmwatch-test-heartbeat bridge local
1879a5df6908 docker_gwbridge bridge local
665f2e7911f3 host host local
1s23qjcabtlz ingress overlay swarm
9f5805c8eb61 none null local
此时已成功创建业务网络和心跳网络dmwatch-test-business
和dmwatch-test-heartbeat
。创建完成后可以使用如下命令查看网络详情:
[dmdba@VM-8-6-centos ~]$ docker network inspect dmwatch-test-business
[
{
"Name": "dmwatch-test-business",
"Id": "870c978be7747a6922eece5ad9eb960e30190fd0cf4891d16126f9b21eb43e43",
"Created": "2024-08-27T17:27:30.85677936+08:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "172.16.1.0/24",
"Gateway": "172.16.1.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {},
"Labels": {}
}
]
[dmdba@VM-8-6-centos ~]$ docker network inspect dmwatch-test-heartbeat
[
{
"Name": "dmwatch-test-heartbeat",
"Id": "f0c46f65d5ee0529fead4335f5c34b8c803a248edf8a66f643849412a52c6348",
"Created": "2024-08-27T17:29:18.804362399+08:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "192.168.1.0/24",
"Gateway": "192.168.1.1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {},
"Options": {},
"Labels": {}
}
]
可见两个子网的第一个可用设备地址分别都已经作为subnet的Gateway使用,故我们的部署需要从至少第二个可用IP开始分配。根据实际情况调整1.2小节中的集群规划如下:
A 机器 | B 机器 | |
---|---|---|
业务 IP | 172.16.1.2 | 172.16.1.3 |
心跳 IP | 192.168.1.2 | 192.168.1.3 |
实例名 | GRP1_RT_01 | GRP1_RT_02 |
实例端口 | 5236 | 5236 |
MAL 端口 | 5336 | 5336 |
MAL 守护进程端口 | 5436 | 5436 |
守护进程端口 | 5536 | 5536 |
OGUID | 45331 | 45331 |
守护组 | GRP1 | GRP1 |
安装目录 | /home/dmdba/dmdbms | /home/dmdba/dmdbms |
实例目录 | /dmdata/data | /dmdata/data |
归档上限 | 51200 | 51200 |
2.1.2 创建数据库实例并启动服务
执行如下命令创建数据库实例并启动服务。通过该docker run命令,在初始化时指定连接到dmwatch-test-business:
docker run -d --restart=always --name=GRP1_RT_01 --network dmwatch-test-business --ip 172.16.1.2 --privileged=true -e LD_LIBRARY_PATH=/opt/dmdbms/bin -e PAGE_SIZE=32 -e EXTENT_SIZE=32 -e LOG_SIZE=2048 -e UNICODE_FLAG=1 -e INSTANCE_NAME=GRP1_RT_01 -v GRP1_RT_01:/opt/dmdbms/data dm8_single:dm8_20240715_rev232765_x86_rh6_64
初始化完成后,Container已经连接到business网络。此时再将容器与heartbeat网络连接并验证,有:
docker network connect --ip 192.168.1.2 dmwatch-test-heartbeat GRP1_RT_01
docker inspect GRP1_RT_01
#只截取Networks部分返回值
"Networks": {
"dmwatch-test-business": {
"IPAMConfig": {
"IPv4Address": "172.16.1.2"
},
"Links": null,
"Aliases": null,
"MacAddress": "02:42:ac:10:01:02",
"NetworkID": "870c978be7747a6922eece5ad9eb960e30190fd0cf4891d16126f9b21eb43e43",
"EndpointID": "202b796e7f78b7fb526e4fb618f7904b74d22a30da9d660f748a78d5f7733203",
"Gateway": "172.16.1.1",
"IPAddress": "172.16.1.2",
"IPPrefixLen": 24,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DriverOpts": null,
"DNSNames": [
"GRP1_RT_01",
"609bf46bc879"
]
},
"dmwatch-test-heartbeat": {
"IPAMConfig": {
"IPv4Address": "192.168.1.2"
},
"Links": null,
"Aliases": [],
"MacAddress": "02:42:c0:a8:01:02",
"NetworkID": "f0c46f65d5ee0529fead4335f5c34b8c803a248edf8a66f643849412a52c6348",
"EndpointID": "02f8eda6f764ecf0a083e4498ed05db0f68126b4638797542247d63a661296f1",
"Gateway": "192.168.1.1",
"IPAddress": "192.168.1.2",
"IPPrefixLen": 24,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DriverOpts": {},
"DNSNames": [
"GRP1_RT_01",
"609bf46bc879"
]
}
}
表明容器A已成功连接到business和heartbeat网络。
对docker run
命令中的参数分类解释如下:
DM Docker镜像结构
DM的Docker版本只包含精简后的必要内容,在/opt/dmdbms
下只包含有bin, bin2, data和log四个文件夹,其中数据库实例保存在/data/DAMENG
下。从镜像使用docker run
启动容器时,会自动完成数据库实例的创建、注册并开启服务;这些可以在启动后通过docker logs GRP1_RT_01
查看。执行docker run
命令:
网络配置
使用--network
参数指定要bind到的网络名称;--ip
参数根据创建子网时定义的限制分配给Container A一个固定IP,防止因连接到Docker默认bridge网络导致每次容器重启时会被重新分配IP和Gateway的问题,不利于后续步骤中在dmmal.ini
等配置文件内声明式地配置不同Container的通信Socket信息。
参数:privileged
在上述命令中,--privileged=true
参数是必须的,虽然不符合Docker容器的最佳实现,但如官方文档所言,不使用该参数的潜在后果包括安装后启动数据库报错等严重问题,所以该参数是必要的。
Docker Volume持久化容器数据
此外,上述命令中使用-v
参数创建了GRP1_RT_01
卷(若不存在则自动创建),该卷与数据库实例同名;通常情况下,Docker Volume会创建在/var/lib/docker/volumes
中,而dmdba用户需要sudo权限才能够访问;但在这里,我们已经将dmdba用户加入docker用户组(该用户组会在Docker安装时自动创建,只需要后期向其中加入用户即可),故可以免去在命令中使用sudo。Docker Volume创建后可以使用如下命令查看:
[dmdba@VM-8-6-centos ~]$ docker volume ls
DRIVER VOLUME NAME
local GRP1_RT_01
[dmdba@VM-8-6-centos ~]$ docker volume inspect GRP1_RT_01
[
{
"CreatedAt": "2024-08-27T14:42:20+08:00",
"Driver": "local",
"Labels": null,
"Mountpoint": "/var/lib/docker/volumes/GRP1_RT_01/_data",
"Name": "GRP1_RT_01",
"Options": null,
"Scope": "local"
}
]
2.1.3 设置归档与备份
启动并进入该容器后,可以直接通过数据库服务操纵实例。在容器中执行如下命令以使用disql工具与数据库交互:
cd /opt/dmdbms/bin
./disql SYSDBA/SYSDBA001@localhost:5236
接下来使用SQL方式开启归档:
SQL> ALTER DATABASE MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE ADD ARCHIVELOG 'DEST=/opt/dmdbms/data/DAMENG/arch, TYPE=LOCAL, FILE_SIZE=1024, SPACE_LIMIT=51200';
SQL> ALTER DATABASE OPEN;
在上述命令中,首先挂起数据库,后更改数据库Status为归档状态,并设置归档日志目录为/opt/dmdbms/data/DAMENG/arch
,类型为本地归档,单个日志文件大小上限为1024,日志文件总空间最大限制为51200;至此,成功开启数据库归档。查看归档:
root@5b3f4ae87d72:/opt/dmdbms/data/DAMENG$ ls arch
ARCHIVE_LOCAL1_0x6BA8F490_EP0_2024-09-11_17-12-31.log
接着使用以下命令备份数据:
SQL> BACKUP DATABASE BACKUPSET '/opt/dmdbms/data/DAMENG/bak/BACKUP_FILE';
2.1.4 修改dm.ini
使用执行SQL语句的方式修改dm.ini
:
SQL> SP_SET_PARA_VALUE (2,'PORT_NUM',5236);
SQL> SP_SET_PARA_VALUE (2,'DW_INACTIVE_INTERVAL',60);
SQL> SP_SET_PARA_VALUE (2,'ALTER_MODE_STATUS',0);
SQL> SP_SET_PARA_VALUE (2,'ENABLE_OFFLINE_TS',2);
SQL> SP_SET_PARA_VALUE (2,'MAL_INI',1);
SQL> SP_SET_PARA_VALUE (2,'RLOG_SEND_APPLY_MON',64);
对上述SP(Stored Process,存储过程)函数,其第一个参数为scope
,有1、2两个值可选;其中,当值为1时表示从dm.ini
中读取,当值为2时表示从内存中读取;后两个参数为指定要定义的dm.ini
参数名和值。
对上述命令中的参数及其含义的解释见:产品手册 - DM8数据守护与读写分离集群 - 配置文件说明;
其中,RLOG_SEND_APPLY_MON对主备库均有效。对于主库,用于指定最近N次(这里是64次)主库到每个备库的归档的发送时间;对于备库,用于指定统计最近N次备库重演日志的时间。取值16~1024,静态参数,缺省64。
如果指定上述SP函数第一个参数为1而不是2,会有报错:
[-839]:Try to alter static ini parameter.
原因是不允许在运行过程中修改静态参数。
如果要搜索dm.ini中的参数值及其在文件中的位置,有:
grep -n "PORT_NUM" ./dm.ini
前提是在Terminal中提前切换到dm.ini
所在目录。
2.1.5 关闭数据库服务
上述步骤执行完成后,dm.ini中已经加入了有关dmmal.ini
的配置,故如果此时尝试重启数据库服务,会导致找不到dmmal.ini
文件定义而报错;
在之前调用存储过程时,我们设置了scope=2
,这意味着需要重启数据库实例才能使在dm.ini
中的更改生效;若希望能够启动数据库实例,我们接下来需要开始进行对dmarch.ini
、dmmal.ini
、dmwatcher.ini
等的配置。
在/opt/dmdbms/bin
下执行如下命令关闭数据库服务:
./DmService stop
2.1.6 修改dmarch.ini
在之前使用三种方法之一的SQL语句配置ARCHIVELOG后,在/opt/dmdbms/data/DAMENG
目录下自动生成了文件dmarch.ini
。使用cat命令查看dmarch.ini
文件内容,得到:
#DaMeng Database Archive Configuration file
#this is comments
ARCH_WAIT_APPLY = 0
[ARCHIVE_LOCAL1]
ARCH_TYPE = LOCAL
ARCH_DEST = /opt/dmdbms/data/DAMENG/arch
ARCH_FILE_SIZE = 1024
ARCH_SPACE_LIMIT = 51200
ARCH_FLUSH_BUF_SIZE = 2
ARCH_HANG_FLAG = 1
修改dm.ini
,加入关于实时归档的内容如下。其中,ARCH_TYPE指实时归档类型、ARCH_DEST指实时归档目标实例名:
[ARCHIVE_REALTIME1]
ARCH_TYPE = REALTIME
ARCH_DEST = GRP1_RT_02
给出修改后的dmarch.ini
全文:
#DaMeng Database Archive Configuration file
#this is comments
ARCH_WAIT_APPLY = 0
[ARCHIVE_LOCAL1]
ARCH_TYPE = LOCAL
ARCH_DEST = /opt/dmdbms/data/DAMENG/arch
ARCH_FILE_SIZE = 1024
ARCH_SPACE_LIMIT = 51200
ARCH_FLUSH_BUF_SIZE = 2
ARCH_HANG_FLAG = 1
[ARCHIVE_REALTIME1]
ARCH_TYPE = REALTIME
ARCH_DEST = GRP1_RT_02
2.1.7 创建dmmal.ini
官方文档原文中新建dmmal.ini
文件内容如下:
MAL_CHECK_INTERVAL = 10 #MAL 链路检测时间间隔
MAL_CONN_FAIL_INTERVAL = 10 #判定 MAL 链路断开的时间
MAL_TEMP_PATH = /opt/dmdbms/data/malpath/ #临时文件目录
MAL_BUF_SIZE = 512 #单个 MAL 缓存大小,单位 MB
MAL_SYS_BUF_SIZE = 2048 #MAL 总大小限制,单位 MB
MAL_COMPRESS_LEVEL = 0 #MAL 消息压缩等级,0 表示不压缩
[MAL_INST1]
MAL_INST_NAME = GRP1_RT_01 #实例名,和 dm.ini 的 INSTANCE_NAME 一致
MAL_HOST = 192.168.1.1 #MAL 系统监听 TCP 连接的 IP 地址
MAL_PORT = 5336 #MAL 系统监听 TCP 连接的端口
MAL_INST_HOST = 172.16.1.1 #实例的对外服务 IP 地址
MAL_INST_PORT = 5236 #实例对外服务端口,和 dm.ini 的 PORT_NUM 一致
MAL_DW_PORT = 5436 #实例对应的守护进程监听 TCP 连接的端口
MAL_INST_DW_PORT = 5536 #实例监听守护进程 TCP 连接的端口
[MAL_INST2]
MAL_INST_NAME = GRP1_RT_02
MAL_HOST = 192.168.1.2
MAL_PORT = 5336
MAL_INST_HOST = 172.16.1.2
MAL_INST_PORT = 5236
MAL_DW_PORT = 5436
MAL_INST_DW_PORT = 5536
对其中实例参数作如下解释:
- MAL_INST_NAME:MAL所在的数据库实例的名称;
- MAL_HOST:MAL系统一般使用和心跳网络相同的IP地址(在高可用性集群中表现为独立网卡等形式)进行通信,和业务网络隔离;
- MAL_PORT:MAL系统监听来自其他数据库实例的MAL系统的通信端口,绑定在MAL_HOST上;
- MAL_INST_HOST:和MAL_INST_NAME相同,指的是MAL所在数据库实例的业务IP,需要与实例在dm.ini中配置的业务IP一致;
- MAL_INST_PORT:同上,是指的MAL所在数据库实例业务网络端口,其IP与在
dm.ini
中配置的业务端口一致,与业务IP绑定; - MAL_DW_PORT:dmwatcher守护进程与数据库实例进行通信的端口(见SERIES5 图1-1中粉色标识的dmwatcher)
- MAL_DW_INST_PORT:MAL所在数据库实例的与守护进程进行通信的端口
在以MAL_INST1
为例的所有参数中,除MAL_INST_HOST
和MAL_INST_PORT
绑定到业务网络的IP、其内容与dm.ini
配置文件中内容相同之外,其他所有的参数包括MAL_HOST
, MAL_PORT
, MAL_DW_PORT
, MAL_INST_DW_PORT
在内,都绑定到心跳网络的IP;
这样做提高了系统的稳定性、安全性,避免了不同类型流量之间的相互干扰。
本次实验中使用Container模拟生产环境的真实dmmal.ini文件内容如下:
MAL_CHECK_INTERVAL = 10
MAL_CONN_FAIL_INTERVAL = 10
MAL_TEMP_PATH = /opt/dmdbms/data/malpath/
MAL_BUF_SIZE = 512
MAL_SYS_BUF_SIZE = 2048
MAL_COMPRESS_LEVEL = 0
[MAL_INST1]
MAL_INST_NAME = GRP1_RT_01
MAL_HOST = 192.168.1.2
MAL_PORT = 5336
MAL_INST_HOST = 172.16.1.2
MAL_INST_PORT = 5236
MAL_DW_PORT = 5436
MAL_INST_DW_PORT = 5536
[MAL_INST2]
MAL_INST_NAME = GRP1_RT_02
MAL_HOST = 192.168.1.3
MAL_PORT = 5336
MAL_INST_HOST = 172.16.1.3
MAL_INST_PORT = 5236
MAL_DW_PORT = 5436
MAL_INST_DW_PORT = 5536
2.1.8 创建dmwatcher.ini
给出实际生产环境配置文件内容如下:
[GRP1]
DW_TYPE = GLOBAL
DW_MODE = AUTO
DW_ERROR_TIME = 20
INST_ERROR_TIME = 20
INST_RECOVER_TIME = 60
INST_OGUID = 45331
INST_INI = /opt/dmdbms/data/DAMENG/dm.ini
INST_AUTO_RESTART = 1
INST_STARTUP_CMD = /opt/dmdbms/bin/dmserver
RLOG_SEND_THRESHOLD = 0
RLOG_APPLY_THRESHOLD = 0
对其中部分参数的解释如下:
- DW_TYPE:守护类型,缺省值为GLOBAL,可选值包括LOCAL和GLOBAL;
- DW_ERROR_TIME:守护进程故障认证时间,缺省15s没有收到远程守护进程消息,即认定远程守护进程故障,对本地守护无效。该参数也是监视器认定守护进程的故障时间。
- INST_ERROR_TIME:数据库故障认定时间,缺省15s未收到数据库故障信息,则认证其监控的数据库出现故障。
- INST_RECOVER_TIME:备库故障恢复检测时间间隔,缺省每60s检查一次备库状态。满足故障恢复条件时,启动历史数据同步流程。
- INST_OGUID:数据守护唯一标识码,同一守护进程组中的所有数据库、守护进程和监视器,都必须配置相同的OGUID值;
- INST_AUTO_RESTART:缺省为0;
- INST_STARTUP_CMD:命令行方式启动。还可以设置为Linux服务方式启动,值为
service dmserverd restart
; - RLOG_SEND_THRESHOLD:用于指定主库发送日志到备库的时间阈值,详见产品手册 - DM8数据守护与读写分离集群 - 配置文件说明
- RLOG_APPLY_THRESHOLD:与RLOG_SEND_THRESHOLD类似;RLOG_SEND_THRESHOLD中的SEND指平均日志发送时间,而APPLY指平均日志重演时间。
此时,A机器的配置已完成。
2.2 配置B机器
2.2.1 创建数据库实例并启动服务
执行如下命令创建数据库实例并启动服务。通过该docker run命令,在初始化时指定连接到dmwatch-test-business:
docker run -d --restart=always --name=GRP1_RT_02 --network dmwatch-test-business --ip 172.16.1.3 --privileged=true -e LD_LIBRARY_PATH=/opt/dmdbms/bin -e PAGE_SIZE=32 -e EXTENT_SIZE=32 -e LOG_SIZE=2048 -e UNICODE_FLAG=1 -e INSTANCE_NAME=GRP1_RT_02 -v GRP1_RT_02:/opt/dmdbms/data dm8_single:dm8_20240715_rev232765_x86_rh6_64
初始化完成后,Container已经连接到business网络。此时再将容器与heartbeat网络连接并验证,有:
"Networks": {
"dmwatch-test-business": {
"IPAMConfig": {
"IPv4Address": "172.16.1.3"
},
"Links": null,
"Aliases": null,
"MacAddress": "02:42:ac:10:01:03",
"NetworkID": "870c978be7747a6922eece5ad9eb960e30190fd0cf4891d16126f9b21eb43e43",
"EndpointID": "8fc772de0e655710f884defdf0099220345c2bb7d9e00d33f22fddd6ec6c7208",
"Gateway": "172.16.1.1",
"IPAddress": "172.16.1.3",
"IPPrefixLen": 24,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DriverOpts": null,
"DNSNames": [
"GRP1_RT_02",
"f8cc01aa885b"
]
},
"dmwatch-test-heartbeat": {
"IPAMConfig": {
"IPv4Address": "192.168.1.3"
},
"Links": null,
"Aliases": [],
"MacAddress": "02:42:c0:a8:01:03",
"NetworkID": "f0c46f65d5ee0529fead4335f5c34b8c803a248edf8a66f643849412a52c6348",
"EndpointID": "7e357bfec8400dfa7c0a3ee189d14cf41288e6c9678bbc509911593f15fec95f",
"Gateway": "192.168.1.1",
"IPAddress": "192.168.1.3",
"IPPrefixLen": 24,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DriverOpts": {},
"DNSNames": [
"GRP1_RT_02",
"f8cc01aa885b"
]
}
}
表明容器B已经成功连接到business和hearbeat网络。
2.2.2 从A的备份文件恢复数据(Reference to 2.1.9)
首先,将Container A中的备份文件传输到Container B。
第一步,将备份文件从Container A拷贝到宿主机:
docker cp GRP1_RT_01:/opt/dmdbms/data/DAMENG/bak/BACKUP_FILE /home/dmdba/Docker
Successfully copied 32MB to /home/dmdba/Docker
第二步,将备份文件从宿主机拷贝到Container B:
docker cp /home/dmdba/Docker/BACKUP_FILE GRP1_RT_02:/opt/dmdbms/data/DAMENG/bak
Successfully copied 32MB to GRP1_RT_02:/opt/dmdbms/data/DAMENG/bak
在Docker版本中dmdba用户已经默认创建。还原与恢复(Restore / Recover)操作必须使用dmdba用户而不能使用root用户。切换到dmrman所在目录后执行如下命令::
./dmrman CTLSTMT="RESTORE DATABASE '/opt/dmdbms/data/DAMENG/dm.ini' FROM BACKUPSET '/opt/dmdbms/data/DAMENG/bak/BACKUP_FILE'"
dmrman V8
RESTORE DATABASE '/opt/dmdbms/data/DAMENG/dm.ini' FROM BACKUPSET '/opt/dmdbms/data/DAMENG/bak/BACKUP_FILE'
file dm.key not found, use default license!
[Percent:100.00%][Speed:0.00M/s][Cost:00:00:02][Remaining:00:00:00]
restore successfully.
time used: 00:00:02.930
./dmrman CTLSTMT="RECOVER DATABASE '/opt/dmdbms/data/DAMENG/dm.ini' FROM BACKUPSET '/opt/dmdbms/data/DAMENG/bak/BACKUP_FILE'"
/opt/dmdbms/bin/dmrman CTLSTMT="RECOVER DATABASE '/opt/dmdbms/data/DAMENG/dm.ini' UPDATE DB_MAGIC"
2.2.3 替换dmarch.ini
以如下内容替换dmarch.ini
:
vim /opt/dmdbms/data/DAMENG/dmarch.ini
ARCH_WAIT_APPLY = 0
[ARCHIVE_LOCAL]
ARCH_TYPE = LOCAL
ARCH_DEST = /opt/dmdbms/data/DAMENG/arch/
ARCH_FILE_SIZE = 1024
ARCH_SPACE_LIMIT = 51200
[ARCHIVE_REALTIME1]
ARCH_TYPE = REALTIME
ARCH_DEST = GRP1_RT_01
2.2.4 配置 dm.ini、dmmal.ini 和 dmwatcher.ini
在这三个配置文件中,dmmal.ini和dmwatcher.ini与GRP1_RT_01容器需保持相同;显然,这符合实例设计的要求。对唯一不同的dm.ini,要求将参数修改如下:
INSTANCE_NAME = GRP1_RT_02
PORT_NUM = 5236
DW_INACTIVE_INTERVAL = 60
ALTER_MODE_STATUS = 0
ENABLE_OFFLINE_TS = 2
MAL_INI = 1
ARCH_INI = 1
RLOG_SEND_APPLY_MON = 64
2.2.5 注册服务
注册服务参考A容器的有关操作,见2.1.10小节。在B容器上执行命令:
/opt/dmdbms/script/root/dm_service_installer.sh -t dmserver -p GRP1_RT_02 -dm_ini /opt/dmdbms/data/DAMENG/dm.ini -m mount
/opt/dmdbms/script/root/dm_service_installer.sh -t dmwatcher -p Watcher -watcher_ini /opt/dmdbms/data/DAMENG/dmwatcher.ini
2.2.6 删除自启(可选)
删除自启参考A容器的有关操作,见2.1.10小节。在B容器上执行命令:
/opt/dmdbms/script/root/dm_service_uninstaller.sh -n DmServiceGRP1_RT_02
/opt/dmdbms/script/root/dm_service_uninstaller.sh -n DmWatcherServiceWatcher
2.3 配置确认监视器
确认监视器在实际生产环境中一般配置到单独的机器上。这里我们为期分配子网IP 10.10.10.10,并在该主机上创建dmmonitor.ini,同时注册后台自启服务:
2.3.1 创建dmmonitor.ini
vim /opt/dmdbms/bin/dmmonitor.ini
MON_DW_CONFIRM = 1
MON_LOG_PATH = ../log
MON_LOG_INTERVAL = 60
MON_LOG_FILE_SIZE = 512
MON_LOG_SPACE_LIMIT = 2048
[GRP1]
MON_INST_OGUID = 45331 #组 GRP1 的唯一 OGUID 值
MON_DW_IP = 192.168.1.1:5436 #IP 对应 MAL_HOST,PORT 对应 MAL_DW_PORT
MON_DW_IP = 192.168.1.2:5436
非确认监视器配置文件一般存放在集群各节点的 bin 目录中。在配置监视器时,一般配置好确认监视器后,建议再配置一个非确认监视器的配置文件,在主备发生切换时,可以通过前台的方式启动非确认监视器进行手动切换。非确认监视器是通过将监视器配置文件中 MON_DW_CONFIRM 参数值修改为 0 来实现。
有示例:
vim /opt/dmdbms/bin/dmmonitor_manual.ini
MON_DW_CONFIRM = 0
MON_LOG_PATH = ../log
MON_LOG_INTERVAL = 60
MON_LOG_FILE_SIZE = 512
MON_LOG_SPACE_LIMIT = 2048
[GRP1]
MON_INST_OGUID = 45331
MON_DW_IP = 192.168.1.1:5436
MON_DW_IP = 192.168.1.2:5436
2.3.2 注册服务
需要注意的是,只有确认监视器才需要进行服务注册,而非确认监视器无需注册。
若要删除自启服务,有:
/opt/dmdbms/script/root/dm_service_uninstaller.sh -n DmMonitorServiceMonitor
至此,数据守护集群安装部署以完成,可以开始运行并检查各个节点上的服务可用性。