新架构 FAQ

本文档介绍 YMatrix 5.X 新架构的常见问题。

架构相关文档请见：

1 听说 5.X 下不能随便重启 Supervisor 了，为什么，如果重启了会发生什么？

在 4.X 时代，支持用 sudo systemctl restart matrixdb.supervisor.service 来重启图形化界面（MXUI）等组件。
但在 5.X 架构下，Supervisor 管理了更多子进程，包括 etcd、高可用服务、包括 Postmaster 进程。
因此现在如果随意关停或重启 Supervisor，会带来 etcd、Postmaster 等关键进程重启，轻则集群崩溃，重则丢失数据。

因此除了删除数据库集群、卸载数据库软件等操作之外，切勿再使用重启 Supervisor 的命令。

2 为什么每个服务器上都有 Shard / Cluster 服务进程，但只有一个是活跃（active）状态？

新架构在设计上考虑了最严苛的网络分区下的高可用性。

Cluster / Shard 服务负责数据库集群状态的管理。如果网络分区导致它们不能与集群其他应正常工作的部分联通，它们就不在能正确的对数据库集群状态进行决策。
为了在任何故障情况下都尽可能保持数据库集群可用，需要做出集群状态决策的服务本身也是高可用的。能够在各种网络异常下做出跟人类一样的客观判断，这也就是引入 etcd 集群的核心意义。
通常情况下，每个机器上都会运行一组 Cluster / Shard 服务。但整个集群里，每一种服务最多只有一个活跃的实例。其他不活跃的实例会在原活跃的实例失效后自动选出一个成为新的活跃实例。

3 etcd 是部署在每台主机上吗？

etcd 的存储可以理解为全复制表，因此节点数量不必太多。在实践层面，推荐的配置为 1、3、5、7 节点，安装部署过程会自动根据主机数量选定部署几个 etcd 实例。
因此如果集群里的主机个数是偶数，或者超过 7 台主机，那么有些机器上是没有 etcd 节点的。可以通过 ps 命令查看当前主机上有没有 etcd 进程。
通常 Master 和 Standby 的主机上会优先安放 etcd 节点。

4 日常我们需要针对 etcd 做哪些运维操作？

首先，需要部署针对 etcd 的监控。目前支持 Prometheus 5.0 部署 etcd 的监控(Prometheus + Grafana)。

5 etcd 的数据量有多大？是否需要特别的运维工作？

5.X 的 etcd 会定期自动进行清理操作，因此数据目录和内存大小都能维持在一个相对固定的范围。
但是如果有节点故障和后续 recover 操作，会使 etcd 的数据在短时间内发生稍许膨胀。只要 etcd 的数据目录不持续膨胀超过 1.5GB，都是正常的，建议通过监控进行监视和定期检查。

6 引入 etcd 后，图形化界面部署数据库集群操作有哪些变化？

从使用体验上并没有变化，安装部署的页面和操作方法跟以前完全一致。

7 5.X 现版本如何在线扩容？

可以使用图形化界面进行扩容操作。

8 5.0 beta 号称实现了 Master Auto-failover，为什么 Master 关机并切换后，再开机 Master 不会自动恢复？

这里存在一个概念误区，一个 Segment 有两个维度的概念：

一个维度是角色：Primary 或 Mirror
一个维度是状态：Up 或 Down

当前版本下，Master Auto-failover 功能指的是节点角色的自动切换，即 Master 离线之后，Standby 能自动切换为 Master，这个动作称为提升（Promote）或者故障自动转移（Failover）。
而一旦一个 Segment 的状态从 Up 变成 Down，是必须通过手动节点恢复操作（mxrecover）才能变回 Up。

9 当故障自动转移（Auto-failover）发生在不同组件，会分别产生什么影响？我要如何进一步操作？

9.1 MatrixGate

9.1.1 Master Auto-failover 发生时

场景 1：mxgate 不在 Master 主机上，或 Master 的 postgres 崩溃，但 Master 主机仍然存活

MatrixGate 启动前，就已经配置了 Standby
MatrixGate 启动时会自动判断出 Standby 的连接信息。
当 Master 的 postgresql 进程崩溃，Standby 被提升并开始对外服务时，MatrixGate 会自动切换到连接 Standby，无需手动介入。
MatrixGate 启动后，才添加的 Standby
由于 MatrixGate 当前仅在启动时识别 Standby 是否存在，所以一旦 MatrixGate 启动，在之后添加的 Standby 并不能让 MatrixGate 实现自动切换。
当前对集群管理操作的建议是先配置 Standby 再部署 MatrixGate，也可以在追加 Standby 后重启 MatrixGate。

场景2：MatrixGate 在 Master 主机上，且 Master 主机离线
这种场景下，MatrixGate 进程因为在离线的主机上，可以认为已经随主机消亡，或者与其他节点网络隔离。此时 MatrixGate 肯定是没有功能了，需要人工介入，在存活的机器上启动另一个 MatrixGate。

9.1.2 恢复损坏的 Master 后

mxrecover 工具会修复（Failback）损坏的旧 Master，并将它作为 Standby 角色拉起来。
mxrecover -r 会进一步将这个旧 Master 恢复为 Master 角色，Standby 也恢复为原来的角色。
按照 MatrixGate 建立连接的原理，与 Failover 发生时的情况相同，recover/rebalance 操作后，MatrixGate 会自动找到正确的 Master 并继续灌数据，不需要人工介入。

9.2 图形化界面

9.2.1 Master Auto-failover 发生时

场景1：当安装部署集群时配置了 Standby

假如仅仅是 Master 挂了，Master 主机以及图形化界面的 MXUI 进程还都存活。
- 此时访问 Master 的图形化界面地址：
  可以看到集群管理页面上能显示出 Master 故障和 Standby 切换信息：此时如果访问其他功能页面，可能会提示无法连接 Master 的数据库，在当前版本是符合预期的：如果此时退出图形化界面尝试重新登陆，可以看到登陆页面给出提示信息：
- 此时，用户应根据提示访问 Standby 节点上的图形化界面，默认地址为 http://<standbyIP>:8240 可以用 mxadmin 的数据库密码，或 Standby 节点上的 /etc/matrixdb5/auth.conf 超级密码正常登陆：登陆后一切功能均可正常使用。
Master 整个主机离线不可访问
跟上述操作相同，你可以直接访问位于 Standby 上的图形化界面，地址为 http://<standbyIP>:8240 。一切功能可以正常使用。

场景2：安装时没有部署 Standby，但曾经通过 mxinitstandby 追加过 Standby
首先，如果没有部署 Standby，在图形化界面上的集群拓扑信息会看到：未配置 Standby 节点。此时如果 Master 主机崩溃离线，将无法访问其图形化界面，建议在严肃生产环境里一定要配置 Standby。
增加 Standby 节点后，后续的 Auto-failover 动作，以及 Failover 发生时图形化界面的使用方法，跟上述场景1完全相同。

9.2.2 恢复损坏的 Master 后

Master 修复上线后，即可恢复访问位于 Master 上的图形化界面。

9.3 监控（SELECT mxmgr_init_local()部署）

9.3.1 背景知识

当执行了 SELECT mxmgr_init_local() 部署监控后：

会在当前集群的每台主机后台启动一个 telegraf 进程，用于采集监控信息；
同时还会在当前 Master 上启动一个参数为 --hidden 的 MatrixGate 进程；
各个主机上的 telegraf 进程会把监控数据 post 给 Master 上的这个 MatrixGate 进程，从而将监控信息插入到 matrixmgr 的 local.system 表中。

9.3.2 Master Failover 发生时

场景1：仅 Master 的 postgres 进程崩溃，Master 主机和 supervisor 服务仍然存活
此时，Master 上的 telegraf 和 MatrixGate 进程应该不受影响。Master 崩溃后，MatrixGate 会自动切换为插入 Standby，监控数据会继续正常入库，无需人工介入。
如果需要查看 Grafana 监控页面，此时需要手动修改数据源，指向 Standby 的地址。

场景2：Master 主机离线
这种情况下，因为监控部署的 MatrixGate 服务也一并消亡，因此即便其他存活的机器还在采集信息，也不会插入数据库了。
你也可以不使用 mxmgr_init_local 部署的监控，而是在外部部署 Prometheus 监控。基于外部 Prometheus 的监控将不受 Master 主机崩溃的影响，但你需要自己运维 Prometheus。

9.3.3 恢复损坏的 Master 后

Master 恢复后，监控服务将自动被 supervisor 拉起，监控信息的采集和入库都能自动恢复，无需人工介入。

10 YMatrix 5 单个组件启动

不使用 matrixdb.supervisor.service 的原因

在 YMatrix 5 的架构下，supervisor 管理了更多子进程，包括 etcd 集群、高可用服务、postmaster 进程等。随意关停或重启 supervisor，会带来 etcd、postmaster 等关键进程重启，从而引发数据库问题。
因此需要重启某个组件的时候我们推荐采用 supervisorctl 工具。

单个组件管理

查看 supervisor 的状态及信息

[mxadmin@mdw3 ~]$ systemctl status matrixdb5.supervisor.service
● matrixdb5.supervisor.service - MatrixDB 5 Supervisord Daemon
Loaded: loaded (/usr/lib/systemd/system/matrixdb5.supervisor.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2023-05-24 21:04:35 PDT; 1h 28min ago
Process: 4426 ExecStop=/bin/bash -c exec "$MXHOME"/bin/supervisorctl shutdown (code=exited, status=1/FAILURE)
Main PID: 4439 (supervisord)
Memory: 605.4M
CGroup: /system.slice/matrixdb5.supervisor.service
        ├─  954 /bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
        ├─  955 /bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
        ├─ 3357 /bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
        ├─ 4439 /opt/ymatrix/matrixdb5/bin/supervisord -c /etc/matrixdb5/supervisor.conf
        ├─ 4451 mxctl telegraf exec --gpname mdw3 --mxui-collector --socket-addr mdw3:51574 --cluster-id AuWFhsrjyywC4xfMahgyor --master-role --dbhost mdw3 --dbport ...
        ├─ 4461 mxctl telegraf exec --gpname mdw3 --mxui-collector --socket-addr mdw3:56639 --cluster-id GFpQhTxkwGqb7qM6iYVA8y --master-role --dbhost mdw3 --dbport ...
        ├─ 4470 /opt/ymatrix/matrixdb5/bin/cylinder -nofile -port 4637 -db-cluster-id AuWFhsrjyywC4xfMahgyor
        ├─ 4479 /opt/ymatrix/matrixdb5/bin/telegraf --config /tmp/mxui_collector_AuWFhsrjyywC4xfMahgyor.conf
        ├─ 4515 /opt/ymatrix/matrixdb5/bin/telegraf --config /tmp/mxui_collector_GFpQhTxkwGqb7qM6iYVA8y.conf
        ├─ 4528 /bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
        ├─ 4539 /bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
        ├─ 4997 /opt/ymatrix/matrixdb5/bin/mxui
        ├─12093 /usr/lib64/sa/sadc -S DISK 4 2 /tmp/sysstat-3640257011
        └─12094 /usr/lib64/sa/sadc -S DISK 4 2 /tmp/sysstat-3256168522

查看各组件运行状态

[mxadmin@mdw3 ~]$ supervisorctl status
Status:
     1. pc_id:{group:"mxui_collector_AuWFhsrjyywC4xfMahgyor" name:"mxui_collector_AuWFhsrjyywC4xfMahgyor"} describe:"pid 4451, uptime 1:29:17" now:1684992833 state:"Running" log_file:"/var/log/matrixdb5/mxui_collector_AuWFhsrjyywC4xfMahgyor.log" stdout_log_file:"/var/log/matrixdb5/mxui_collector_AuWFhsrjyywC4xfMahgyor.log" pid:4451
     2. pc_id:{group:"cylinder_AuWFhsrjyywC4xfMahgyor" name:"cylinder_AuWFhsrjyywC4xfMahgyor"} describe:"pid 4470, uptime 1:29:17" now:1684992833 state:"Running" log_file:"/var/log/matrixdb5/cylinder_AuWFhsrjyywC4xfMahgyor.log" stdout_log_file:"/var/log/matrixdb5/cylinder_AuWFhsrjyywC4xfMahgyor.log" pid:4470
     3. pc_id:{group:"shard_AuWFhsrjyywC4xfMahgyor" name:"shard_AuWFhsrjyywC4xfMahgyor"} describe:"pid 4477, uptime 1:29:17" now:1684992833 state:"Running" log_file:"/var/log/matrixdb5/shard_AuWFhsrjyywC4xfMahgyor.log" stdout_log_file:"/var/log/matrixdb5/shard_AuWFhsrjyywC4xfMahgyor.log" pid:4477
     4. pc_id:{group:"mxui" name:"mxui"} describe:"pid 4997, uptime 1:24:43" now:1684992833 state:"Running" log_file:"/var/log/matrixdb5/mxui.log" stdout_log_file:"/var/log/matrixdb5/mxui.log" pid:4997
     5. pc_id:{group:"replication-1_AuWFhsrjyywC4xfMahgyor" name:"replication-1_AuWFhsrjyywC4xfMahgyor"} describe:"pid 4484, uptime 1:29:17" now:1684992833 state:"Running" log_file:"/var/log/matrixdb5/replication-1_AuWFhsrjyywC4xfMahgyor.log" stdout_log_file:"/var/log/matrixdb5/replication-1_AuWFhsrjyywC4xfMahgyor.log" pid:4484
     6. pc_id:{group:"replication-3_AuWFhsrjyywC4xfMahgyor" name:"replication-3_AuWFhsrjyywC4xfMahgyor"} describe:"pid 4466, uptime 1:29:17" now:1684992833 state:"Running" log_file:"/var/log/matrixdb5/replication-3_AuWFhsrjyywC4xfMahgyor.log" stdout_log_file:"/var/log/matrixdb5/replication-3_AuWFhsrjyywC4xfMahgyor.log" pid:4466
     7. pc_id:{group:"etcd" name:"etcd"} describe:"pid 4450, uptime 1:29:17" now:1684992833 state:"Running" log_file:"/mxdata_20230514185455/etcd/log/etcd.log" stdout_log_file:"/mxdata_20230514185455/etcd/log/etcd.log" pid:4450
     8. pc_id:{group:"replication-2_AuWFhsrjyywC4xfMahgyor" name:"replication-2_AuWFhsrjyywC4xfMahgyor"} describe:"pid 4453, uptime 1:29:17" now:1684992833 state:"Running" log_file:"/var/log/matrixdb5/replication-2_AuWFhsrjyywC4xfMahgyor.log" stdout_log_file:"/var/log/matrixdb5/replication-2_AuWFhsrjyywC4xfMahgyor.log" pid:4453
     9. pc_id:{group:"cluster_AuWFhsrjyywC4xfMahgyor" name:"cluster_AuWFhsrjyywC4xfMahgyor"} describe:"pid 4454, uptime 1:29:17" now:1684992833 state:"Running" log_file:"/var/log/matrixdb5/cluster_AuWFhsrjyywC4xfMahgyor.log" stdout_log_file:"/var/log/matrixdb5/cluster_AuWFhsrjyywC4xfMahgyor.log" pid:4454
     10. pc_id:{group:"deployer" name:"deployer"} describe:"pid 4457, uptime 1:29:17" now:1684992833 state:"Running" log_file:"/var/log/matrixdb5/deployer.log" stdout_log_file:"/var/log/matrixdb5/deployer.log" pid:4457
     11. pc_id:{group:"mxui_collector_GFpQhTxkwGqb7qM6iYVA8y" name:"mxui_collector_GFpQhTxkwGqb7qM6iYVA8y"} describe:"pid 4461, uptime 1:29:17" now:1684992833 state:"Running" log_file:"/var/log/matrixdb5/mxui_collector_GFpQhTxkwGqb7qM6iYVA8y.log" stdout_log_file:"/var/log/matrixdb5/mxui_collector_GFpQhTxkwGqb7qM6iYVA8y.log" pid:4461

重启某个组件，例：图形化界面（Mxui）

[mxadmin@mdw3 ~]$ supervisorctl restart mxui
Restarted:
     1. name:"mxui"

11 我不想安装 etcd，可以选择在 YMatrix 5.X 上安装无 etcd（非高可用）的集群吗？

可以的。

安装完 YMatrix 安装包之后，执行 sudo vi /etc/default/matrixdb5，在文件中添加如下高亮两行配置。仅在 Master 主机上操作即可。

重启 supervisor 服务。仅在 Master 主机上操作即可。
```
sudo systemctl restart matrixdb5.supervisor.service
```
正常访问 http://<MASTER-IP>:8240/login 。你应当能够看到提示的密码路径为 /etc/matrixdb/auth.conf (而并非正常初始化 YMatrix 5 会显示的 /etc/matrixdb5/auth.conf )，但是这里仍然需要输入的是 /etc/matrixdb5/auth.conf 文件里的密码，因为在 5 的部署体系下并不存在 /etc/matrixdb/auth.conf 这个文件。

注意！
使用此方式部署，可能会导致 YMatrix 5.X 图形化界面的某些功能无法正常使用。

注意！
使用此方式部署，将永远无法开启故障自动转移机制。

12 Master 发生自动切换的延迟是多久？

当 Master 的 postmaster 进程发生崩溃，但主机和网络都正常，Master 可以快速切换到 Standby。
当 Master 主机发生断电、网络隔离等现象，其自动切换会根据参数的配置延迟重试一段时间。

13 Segment 是否可以被 supervisor 自动恢复？

不可以。

supervisor 服务没有自动启动一个 Segment（或称为一个 postgresql 进程组）的功能，只有在 supervisor 被注册的服务才能被 supervisor 启动。postgresql 进程组作为副本（Replication）服务进程的子孙进程，由 replication 服务进程而不是 supervisor 服务进程管理。该进程组的启动只由集群管理工具（mxstart，mxstop，mxrecover 等）通过调用 replication 服务 API 启动或停止。

14 当半数以上的 etcd 进程异常（被杀死或无法启动）后，集群出现宕机，是正常现象吗？

是的。

postgres 进程的存活需要依赖 etcd 集群的租约存续。当 etcd 服务本身出现异常（半数以上的 etcd 节点宕机或失联），postgres 进程就无法维持存活，宕机是必然的结果。因此，请严格部署 etcd 监控，密切关注其健康状态。监控事项包括但不限于：磁盘剩余空间、磁盘 I/O、网络联通性、宿主进程 supervisor 的存活等。