标签: galera

我正在尝试使用 MariaDB 创建 Galera Cluster 的自动部署，在 CoreOS 上的 Docker 容器内运行。

使用的软件： - MariaDB 官方Docker 镜像，版本 10.1.10 - CoreOS 899.5.0，Docker 1.9.1

一切都在 2 个独立的虚拟机上运行：10.2.0.4 和 10.2.0.5

我可以成功启动第一个节点 (10.2.0.4) 并引导集群。

但是，当我启动第二个节点时，我在复制mysql.time_zone_transition_type和mysql.time_zone_name表时遇到了很多错误。在那之后，mysqld守护进程不会崩溃，所以我的 Docker 容器继续运行（它运行了几分钟没有问题），但它似乎没有加入集群（查询第一个节点上的状态显示只有 1 个节点已加入）和它不接受任何连接（尝试连接到该节点失败）。然而，奇怪的是，如果我重新启动 Docker 容器（保留数据文件夹），它就会加入节点并完美运行。

这是 MySQL 配置文件（添加到/etc/mysql/conf.dDocker 容器中）：

# this is read by the standalone daemon and embedded servers
[server]

# this is only for the mysqld standalone daemon
[mysqld]

#
# * Galera-related settings
#
[galera]
# Mandatory …

第一次设置 Galera (Ubuntu 14.04)，在重新启动节点后我无法重新启动集群。我正在遵循本指南，它并没有完全提到如何处理关机或重启（对于内核补丁、管理程序更新、日常维护）。

我在这里找到了一些信息，它解释了如何找到“safe_to_bootstrap”节点，但我认为这是描述一个崩溃的节点。上面的链接将其描述为一个崩溃的节点，但似乎没有什么恢复的运气：

# cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid:    a4f9af07-f235-11e7-a0c0-233dd732dc29
seqno:   -1
safe_to_bootstrap: 1

但是，当我尝试启动该节点时，出现以下错误daemon.log：

`WSREP: failed to open gcomm backend connection: 110: failed to reach primary view: 110 (Connection timed out)`

关闭集群的最佳方法是什么，如何安全地重新启动它？我假设习惯reboot命令不足以干净地关闭 Galera 集群。

我已经与 Galera 合作了几个月，喜欢故障转移和冗余。我有一个正在测试中的 Postgres 数据库，可能会转移到生产中。Postgres 是否有 Galera 等价物？我读过 Postrgres 的“备用”数据库，但不确定它们在自动故障转移/VIP 方面是否与 Galera 相同。

我正在运行一个 3 节点 MySQL 5.6 Galera 集群。一切都是同步的，看起来很好，但我刚刚发现用户表不同步。

其他节点上不存在一个特定用户，我认为它可能会在发出后复制它：

mysql -u root -p -e "INSERT INTO mysql.user (Host,User) values ('10.0.0.10','haproxy_check'); FLUSH PRIVILEGES;"

我仔细检查了所有节点上的 wsrep 状态和用户表。在其他 2 个节点上发出命令后，它可用并且 galera 似乎仍处于同步状态。

我在这里错过了什么吗？为什么 galera 不复制用户表？

我知道要检查Galera集群状态，登录mysql客户端后应该使用的命令是：

SHOW STATUS LIKE 'wsrep%';

但是，如何直接从命令行获取输出？

以下命令会导致错误：

[root@mariadb01 ~]# mysql -u root -p "SHOW STATUS LIKE 'wsrep%';"
Enter password:
ERROR 1049 (42000): Unknown database 'SHOW STATUS LIKE 'wsrep%';'

我计划使用 cron 和 bash 创建一个简单的监控，因此需要使用命令行获取输出

假设我的服务器设置始终满足法定人数投票，那么 Galera 发生裂脑情况的可能性有多大？我的理解是 Galera 会尽力避免这种情况，但这是否意味着如果服务器和 MySQL/MariaDB 进程从不失败，发生这种情况的可能性为零？

如果确实有可能，是否有适当恢复的最佳实践？