diff --git "a/content/zh/post/liuxu/MogHA\357\274\232\344\270\273\345\244\207\347\263\273\347\273\237\346\227\266\351\227\264\344\270\215\345\220\214\346\255\245\345\257\271RTO\347\232\204\345\275\261\345\223\215.md" "b/content/zh/post/liuxu/MogHA\357\274\232\344\270\273\345\244\207\347\263\273\347\273\237\346\227\266\351\227\264\344\270\215\345\220\214\346\255\245\345\257\271RTO\347\232\204\345\275\261\345\223\215.md" new file mode 100644 index 0000000000000000000000000000000000000000..46adc3ae0907143832bd34a98bc49040392e3467 --- /dev/null +++ "b/content/zh/post/liuxu/MogHA\357\274\232\344\270\273\345\244\207\347\263\273\347\273\237\346\227\266\351\227\264\344\270\215\345\220\214\346\255\245\345\257\271RTO\347\232\204\345\275\261\345\223\215.md" @@ -0,0 +1,303 @@ ++++ + +title = "MogHA：主备系统时间不同步对RTO的影响" + +date = "2022-09" + +tags = ["MogHA：主备系统时间不同步对RTO的影响"] + +archives = "2022-09" + +author = "由迪" + +summary = "MogHA：主备系统时间不同步对RTO的影响" + +img = "/zh/post/zhangcuiping/title/img.png" + +times = "10:20" + ++++ + +# MogHA：主备系统时间不同步对RTO的影响 + +# 1. MogHA与RTO + +## 1.1 MogHA + +MogHA 是云和恩墨基于 MogDB 同步异步流复制技术自研的一款保障数据库主备集群高可用的企业级软件系统 + +(适用于 MogDB 和 openGauss 数据库) + +MogHA 能够自主探测故障实现故障转移，虚拟IP自动漂移等特性，使得数据库的故障持续时间从分钟级降到秒级（RPO=0，RTO<30s），确保数据库集群的高可用服务。 + +## 1.2 RTO + +RTO(Recovery Time Objective，复原时间目标)是数据中心可容许服务中断的时间长度。比如说服务发生后半天内便需要恢复，RTO数值就是十二小时。RTO具体时间长短只是从故障发生后，从数据中心系统宕机导致应用停顿之刻开始，到数据中心系统恢复至可以支持各部门运作之时，此两点之间的时间段。RTO是反映数据中心业务恢复的及时性指标，表示业务从中断到恢复正常所需的时间，RTO数值越小，代表容灾系统的数据恢复能力越强 + +## 1.3 实验目的 + +在某个项目上，由于主备两台机器在配置了MogHA之后，并没有配置时间同步，最终高可用切换测试得到的RTO的值非常的高，所以此次实验旨在研究、重现：当主备系统时间有差异，主库出现故障宕库，高可用进行切换的时候对业务恢复时间的影响如何。 + +------ + +# 2. 实验环境 + +| 角色 | IP | VIP | 数据库 | 操作系统 | 高可用软件 | +| ---- | --------------- | --------------- | ------------ | ------------ | ------------ | +| 主 | 192.168.101.159 | 192.168.101.161 | MogDB v3.0.1 | CentOS 7 x86 | MogHA v2.3.5 | +| 备 | 192.168.101.160 | 192.168.101.161 | MogDB v3.0.1 | CentOS 7 x86 | MogHA v2.3.5 | + +# 3. 主备状态检查 + +## 3.1 检查集群状态 + +由于此次主从库都是使用ptk安装的方式，所以可以使用以下命令进行集群状态检查： + +```sql +由于此次主从库都是使用ptk安装的方式，所以可以使用以下命令进行集群状态检查： + +[root@mogdba mogha]# ptk cluster status -n mogdb_cluster +[ Cluster State ] +database_version : MogDB-3.0.1 +cluster_name : mogdb_cluster +cluster_state : Normal +current_az : AZ_ALL + +[ Datanode State ] + id | ip | port | user | instance | db_role | state +-------+-----------------+-------+------+----------+---------+--------- + 6001 | 192.168.101.159 | 26000 | omm | dn_6001 | primary | Normal + 6002 | 192.168.101.160 | 26000 | omm | dn_6002 | standby | Normal +``` + +集群状态正常 + +## 3.2 MogHA高可用服务状态检查 + +- 主：mogdba + +```sql +[root@mogdba ~]# systemctl status mogha +● mogha.service - MogHA High Available Service + Loaded: loaded (/usr/lib/systemd/system/mogha.service; disabled; vendor preset: disabled) + Active: active (running) since Sun 2022-09-11 21:43:29 CST; 36min ago + Docs: https://docs.mogdb.io/zh/mogha/v2.0/installation-and-depolyment + Main PID: 5255 (mogha) + CGroup: /system.slice/mogha.service + ├─5255 /home/omm/mogha/mogha -c /home/omm/mogha/node.conf + ├─5256 mogha: watchdog + ├─5257 mogha: http-server + └─5258 mogha: heartbeat + +Sep 11 21:43:29 mogdba systemd[1]: Started MogHA High Available Service. +Sep 11 21:43:30 mogdba mogha[5255]: MogHA Version: Version: 2.3.5 +Sep 11 21:43:30 mogdba mogha[5255]: GitHash: 7dfa158 +Sep 11 21:43:30 mogdba mogha[5255]: config loaded successfully +Sep 11 21:43:39 mogdba sudo[5333]: omm : TTY=unknown ; PWD=/home/omm/mogha ; USER=root ; CO...55.0 +Hint: Some lines were ellipsized, use -l to show in full. + +[root@mogdba mogha]# tailf /home/omm/mogha/mogha_heartbeat.log +2022-09-11 22:20:17,885 INFO [__init__.py:61]: ping result: {'192.168.101.255': False, '192.168.101.160': True} +2022-09-11 22:20:17,935 INFO [__init__.py:86]: local instance is alive Primary, state: Normal +2022-09-11 22:20:23,027 INFO [__init__.py:61]: ping result: {'192.168.101.255': False, '192.168.101.160': True} +2022-09-11 22:20:23,077 INFO [__init__.py:86]: local instance is alive Primary, state: Normal +2022-09-11 22:20:28,171 INFO [__init__.py:61]: ping result: {'192.168.101.255': False, '192.168.101.160': True} +2022-09-11 22:20:28,220 INFO [__init__.py:86]: local instance is alive Primary, state: Normal +2022-09-11 22:20:33,312 INFO [__init__.py:61]: ping result: {'192.168.101.255': False, '192.168.101.160': True} +``` + +- 从：mogdbb + +```sql +[root@mogdbb ~]# systemctl status mogha +● mogha.service - MogHA High Available Service + Loaded: loaded (/usr/lib/systemd/system/mogha.service; disabled; vendor preset: disabled) + Active: active (running) since Sun 2022-09-11 21:43:35 CST; 36min ago + Docs: https://docs.mogdb.io/zh/mogha/v2.0/installation-and-depolyment + Main PID: 8598 (mogha) + CGroup: /system.slice/mogha.service + ├─8598 /home/omm/mogha/mogha -c /home/omm/mogha/node.conf + ├─8599 mogha: watchdog + ├─8600 mogha: http-server + └─8601 mogha: heartbeat + +Sep 11 21:43:35 mogdbb systemd[1]: Started MogHA High Available Service. +Sep 11 21:43:35 mogdbb mogha[8598]: MogHA Version: Version: 2.3.5 +Sep 11 21:43:35 mogdbb mogha[8598]: GitHash: 7dfa158 +Sep 11 21:43:35 mogdbb mogha[8598]: config loaded successfully + +[root@mogdbb ~]# cd /home/omm/mogha +[root@mogdbb mogha]# tailf mogha_heartbeat.log +2022-09-11 22:20:38,771 INFO [__init__.py:61]: ping result: {'192.168.101.255': False, '192.168.101.159': True} +2022-09-11 22:20:38,823 INFO [__init__.py:86]: local instance is alive Standby, state: Normal +2022-09-11 22:20:43,907 INFO [__init__.py:61]: ping result: {'192.168.101.255': False, '192.168.101.159': True} +2022-09-11 22:20:43,960 INFO [__init__.py:86]: local instance is alive Standby, state: Normal +2022-09-11 22:20:49,040 INFO [__init__.py:61]: ping result: {'192.168.101.255': False, '192.168.101.159': True} +``` + +mogha服务正常 + +## 3.3 查看VIP是否已绑定 + +``` +[root@mogdba mogha]# ifconfig +ens33: flags=4163 mtu 1500 + inet 192.168.101.159 netmask 255.255.255.0 broadcast 192.168.101.255 + inet6 fe80::d894:ac81:4fba:2740 prefixlen 64 scopeid 0x20 + ether 00:0c:29:3f:e3:e4 txqueuelen 1000 (Ethernet) + RX packets 208899 bytes 226654097 (216.1 MiB) + RX errors 0 dropped 0 overruns 0 frame 0 + TX packets 260860 bytes 559965572 (534.0 MiB) + TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 + +ens33:1: flags=4163 mtu 1500 + inet 192.168.101.161 netmask 255.255.255.0 broadcast 192.168.101.255 + ether 00:0c:29:3f:e3:e4 txqueuelen 1000 (Ethernet) +``` + +看见ens33:1虚拟网卡已绑定 + +# 4. 实验准备 + +## 4.1 创建测试表 + +```sql +MogDB=# create table ha_test (time timestamp,ip varchar); +CREATE TABLE +MogDB=# CREATE USER ha_user identified by 'Enmo@123'; +CREATE ROLE +MogDB=# alter table ha_test owner to ha_user; +ALTER TABLE +``` + +## 4.2 编写插入数据的脚本 + +这个插入数据的脚本模拟在线业务，连接到VIP，插入数据到ha_test表中。 + +```sql +[omm@mogdba ~]$ cat ha.sh +#!/bin/bash + +while true +do +gsql -d postgres -h 192.168.101.161 -U ha_user -W 'Enmo@123' -c "insert into ha_test select current_timestamp,setting from pg_settings where name='local_bind_address';" +sleep 1 +done +``` + +## 4.3 修改配置文件参数（node.conf) + +修改两项参数 + +``` +# [2.1新增] 主库实例进程未启动时，如何处理 +# 支持两种处理方式： +# - restart: 尝试重启，尝试次数在 restart_strategy 参数中设定 +# - failover: 直接切换 +primary_down_handle_method=failover + +# 心跳间隔时间 +heartbeat_interval=1 +``` + +## 4.4 主备重启mogha服务 + +``` +systemctl restart mogha +``` + +# 5. 实验过程 + +## 5.1 时间同步时的RTO + +### 5.1.1 查看时间是否同步 + +![image.png](.\figures\9c715ca9-155e-4d0e-8ad9-ea740d844710.png) + +### 5.1.2 在主库上执行数据插入脚本 + +模拟在线业务 + +``` +[omm@mogdba ~]$ . ha.sh +INSERT 0 1 +INSERT 0 1 +INSERT 0 1 +INSERT 0 1 +``` + +### 5.1.3 杀掉主库进程模拟故障 + +``` +[omm@mogdba ~]$ ps -ef |grep mogdb +omm 4838 1 1 21:24 ? 00:01:57 /opt/mogdb/app/bin/mogdb -D /opt/mogdb/data -M primary +omm 67476 64006 0 23:05 pts/1 00:00:00 grep --color=auto mogdb +[omm@mogdba ~]$ kill -9 4838 +``` + +### 5.1.4 查看业务恢复时间 + +之前是有数据插入脚本模拟在线业务，那么ha_test这张表记录的两列分别代表着插入数据的时间和当前IP。经过mogha参数的设置，当发生了主库宕库的情况，mogha会对主备进行切换。在宕库前，VIP是漂移到主库159上，当主备发生切换，VIP会漂移到160上。那么，我们就可以比对表中IP从159变成160之前相差的时间来表示RTO值。因为数据库从宕库到能够重新插入数据才能算是业务的恢复。 + +- 查看ha_test表 + +``` +MogDB=# select * from ha_test; + time | ip +----------------------------+----------------- + 2022-09-11 23:04:58.743228 | 192.168.101.159 + 2022-09-11 23:04:59.774394 | 192.168.101.159 + 2022-09-11 23:05:00.806935 | 192.168.101.159 + ............................................ + 2022-09-11 23:05:49.239632 | 192.168.101.159 + 2022-09-11 23:05:50.270707 | 192.168.101.159 + 2022-09-11 23:05:51.300373 | 192.168.101.159 + 2022-09-11 23:05:59.503423 | 192.168.101.160 + 2022-09-11 23:11:36.580824 | 192.168.101.160 + 2022-09-11 23:11:37.61244 | 192.168.101.160 + 2022-09-11 23:11:38.643501 | 192.168.101.160 + 2022-09-11 23:11:39.673735 | 192.168.101.160 +``` + +根据原理，RTO值大概在8s左右。 + +## 5.2 备库时间晚于主库的RTO + +### 5.2.1 设置备库时间晚于主库时间9s左右 + +![image.png](.\figures\bd1db438-67e5-4e80-968b-00e5709a96bb.png) + +### 5.2.2 查看结果 + +操作步骤如5.1，直接查看最终结果 + +``` + 2022-09-11 23:30:37.810103 | 192.168.101.159 2022-09-11 23:30:38.843325 | 192.168.101.160 +``` + +这样的方法得出的RTO只有1s，这显然是不对的。 + +### 5.2.3 分析原因 + +可以看到之前编写的数据插入脚本，插入的时间是current_timestamp，其代表的是操作系统的时间。在主库159故障前记录当前操作系统的时间是t1，业务恢复到新的主库160记录的是当前操作系统时间t2，而两个操作系统时间本身就有差异，因为之前设置过备库服务器的时间晚与主库时间9s，那么恢复业务后，相对于原主机159的插入时间应该为（t2+9），正确的RTO值为：t2+9s-t1=10s。 + +> RTO指的是服务中断到恢复之间的用时，那么此时时间就应该以中断的那个服务器的时间作为基准。 + +## 5.3 备库时间快于主库的RTO + +为了验证上面5.2.3的分析，接下来将主库时间调整晚于备库9s左右。按照之前的分析，此次的测算出t2-t1的值必定大于9s，且正确的RTO值应该为：t2-t1-9s +![image.png](.\figures\c2d44004-2217-4139-94fc-d9017a83cfcf.png) + +### 5.3.1 查看结果 + +操作步骤如5.1，接下来直接看表中结果 + +``` + 2022-09-12 12:45:41.501278 | 192.168.101.159 + 2022-09-12 12:45:42.535259 | 192.168.101.159 + 2022-09-12 12:45:58.489625 | 192.168.101.160 +t2-t1=16s > 9s 验证成功 +RTO= t2-9s-t1 = 7s +``` + +结论以上实验得出结论，当主备系统时间不一致的时候，不能只看测试表中切换ip的时间差，还需要考虑到两个系统之间本身的时间差，这样才能计算得出真正的RTO值。在此次实验中，查看实验结果，系统时间不同步对真实的RTO值几乎没有影响。当然，这样计算出的RTO值可能不太准确，仅供参考。使用MogHA在生产环境一定要使用ntp等工具对各个数据库节点进行时间同步，以免后续发生误判。 \ No newline at end of file diff --git a/content/zh/post/liuxu/figures/9c715ca9-155e-4d0e-8ad9-ea740d844710.png b/content/zh/post/liuxu/figures/9c715ca9-155e-4d0e-8ad9-ea740d844710.png new file mode 100644 index 0000000000000000000000000000000000000000..7266a70bb5d0cd88ba395b88fa9dfcd438a9e81a Binary files /dev/null and b/content/zh/post/liuxu/figures/9c715ca9-155e-4d0e-8ad9-ea740d844710.png differ diff --git a/content/zh/post/liuxu/figures/bd1db438-67e5-4e80-968b-00e5709a96bb.png b/content/zh/post/liuxu/figures/bd1db438-67e5-4e80-968b-00e5709a96bb.png new file mode 100644 index 0000000000000000000000000000000000000000..34dde8df0b84d6302d55604553f6ec874de1c693 Binary files /dev/null and b/content/zh/post/liuxu/figures/bd1db438-67e5-4e80-968b-00e5709a96bb.png differ diff --git a/content/zh/post/liuxu/figures/c2d44004-2217-4139-94fc-d9017a83cfcf.png b/content/zh/post/liuxu/figures/c2d44004-2217-4139-94fc-d9017a83cfcf.png new file mode 100644 index 0000000000000000000000000000000000000000..23232e030df65183cd23385f5830d3548bc4edb3 Binary files /dev/null and b/content/zh/post/liuxu/figures/c2d44004-2217-4139-94fc-d9017a83cfcf.png differ