一、配置环境说明
机器名 | IP地址 | 实例信息 |
---|---|---|
主机 | 192.168.106.128 | DM128 |
备机 | 192.168.106.129 | DM129 |
确认监视器 | 192.168.106.129 | 确认监视器 |
端口规划
实例名 | PORT_NUM(MAL_INST_PORT) | MAL_INST_DW_PORT(实例监听守护进程TCP连接端口) | MAL_HOST(MAL系统监听TCP连接的IP) | MAL_PORT(MAL系统监听TCP连接的端口) | MAL_DW_PORT(守护进程监听TCP端口) |
---|---|---|---|---|---|
DM128 | 5237 | 33141 | 192.168.106.128 | 61141 | 51141 |
DM129 | 5236 | 33142 | 192.168.106.129 | 61142 | 51142 |
二、配置
1.初始化主库,前台启动主库,exit
2.初始化备库,前台启动主库,exit
3.主备发送归档到备库进行还原
4.编辑主库dm.ini dmmarch.ini dmarch.ini文件
Dmmai.ini
5.发送主库dm.ini dmmarch.ini dmarch.ini文件到备库,并修改相应参数
6.以mount方式前台启动主库和备库
7.登录主库disql(主库配置模式),设置主库OGUID,修改数据库模式为primary
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);
SQL>sp_set_oguid(453331);
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);
SQL>alter database primary;
8.登录备库disql(备库配置模式),设置备库OGUID,修改数据库模式为standby
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1);
SQL>sp_set_oguid(453331);
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0);
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 1); ----第 1 步
SQL>alter database standby; ----第 2 步
SQL>SP_SET_PARA_VALUE(1, 'ALTER_MODE_STATUS', 0); ----第 3 步
9.在备库上配置监视器
10.启动主库备库守护进程
11.启动监视器
三、模拟主机断电
操作:将主机DM128直接重启(reboot)
1.监视器:检测DM128故障
2.监视器分配备机DM129接管
3.等待DM128重启,开启DM128守护进程
4.在监视器中使用show global info查看DM128接入后集群信息
从图中可以看到DM128重新接入后仍然以主机身份,出现集群数据分裂(双主库)
5.关闭确认监视器,关闭DM128守护进程,关闭DM128实例,恢复到mount模式,修改数据库模式为standby。
然后重启启动DM128守护进程
修改后可以通过disql查看当前是否处于备库模式
6.备库重新接入后,主库会进行回滚,保证主库、备库数据一致。
7.监视器显示收到当前备库DM128的消息
8.使用show global info查看当前集群转态是否正常
可以看到主、备库状态已经完全进行了切换,原来的主库变成了备库,原来的备库变成了主库。
以下是主机断电后,备机接管切换为主机,主机重新接入为备机身份的例子;
1.由于监视器之前部署在DM129上,我开了另一台机子作为确认监视器,关闭当前主机(DM129),备机DM128接管。
2.在监视器中查看,集群状态
注意:此处虽然DM129也是显示primary,但是整个数据库是error状态,并未open,所以并未出现双主机的情况。
3.等待DM129重启,开启DM129守护进程;
4.用监视器查看集群信息
可以看到重新接入的主机DM129是以备机身份接入的,整个集群运行正常;
四、模拟备机断电
1.重启备机
2.监视器发现备机状态异常
3.启动备机守护进程后监视器收不到备机消息,退出监视器,重新打开监视器仍然收不到
报上面的错
4.退出监视器,重启备机守护进程,出现checkpoint finished
5.关闭备机防火墙,开启监视器,回复到正常状态