我们在 Debian 8 服务器上获得了 MariaDB 10.1 节点，我们尝试使用 Xtrabackup SST 方法与 CentOS 7 上的 MariaDB 10.0 的 3 节点 galera 集群同步。

启动此节点并设置捐助者工作，SST 也工作：所有数据都正确传输。SST 方法和供体参数在 /etc/mysql/my.cnf 中指定，我们按如下方式启动它：

（请注意，我们在这个系统上也有 mariadb.service 服务）

SST 完成后，mysql 关闭。

当我们再次启动它时，我们可以在日志中看到 innodb 列类型错误（XXX 类型的列应该是 XXX 类型），并且它的 UUID 再次为 0000-0000-0000-0000，而在 SST 之后它确实设置了集群的最后一个 UUID。

它忘记了 UUID 并一遍又一遍地启动 SST。

在集群中启动 mysql 之前，我们还在 SST 之后尝试了 mysql_upgrade，但它没有帮助。

20 次中有一次它启动了 IST，这是意料之中的，但由于无法绑定端口号，它崩溃了。但是，我们从来没有像这次尝试 IST 那样得到它。

端口打开（3306,4444,4567,4568,9200）路由设置，我们也尝试了 rsync 方法但没有成功，经过多次尝试，有时多个 xtrabackup 进程挂起，这就是导致端口号错误的原因。之后我们每次都重新启动以确保我们得到一个干净的系统。

另外值得一提的是，我们确实彻底阅读了这份数据中心迁移指南：http ://severalnines.com/blog/migrating-mysql-galera-cluster-new-data-center-without-downtime

因此，我们希望在仅通过 2 个节点连接的 3 节点集群中建立一个 6 节点集群。

有没有人遇到过这样的问题？

您好，我正在使用带有 10.1.12-MariaDB 的 Galera，SST 方法是 xtrabackup-v2

请不要推荐 SST=rsync 它不适合我

我有健康的集群 8 个节点，有时一个或几个节点出现故障。我刚service mysql开始，他们成功连接到集群，一切正常。

但有时，当几天断开连接的节点时，我无法将它们连接到集群。

经过几次尝试后，我rm -fr /var/lib/mysql/*也rm -fr /var/log/mysql/*没有，他们在系统日志中有这条消息：

mysqld: [ERROR] Binlog file '/var/log/mysql/mariadb-bin.003079' not found in binlog index, needed for recovery. Aborting.

我知道如何使用它，当我的节点无法通过上面的消息连接到集群时，我可以恢复集群，所以我这样做：

1. 关闭所有节点，只保留一个节点
2. 关闭最后一个节点和rm -fr /var/log/mysql/*
3. 使用已删除的 binlog 引导最后一个节点
4. 将其他节点连接到集群service mysql start
5. 利润 - 一切都好

但问题是：

我不能关闭所有生产节点，也不能关闭最后一个节点，因为我有 8 个节点来服务大型站点流量，当所有流量都流向它时，一个正在运行的节点会立即关闭（当然是因为过载）

问题是：

请帮我。当节点无法连接并出现错误时如何将节点连接到集群mysqld: [ERROR] Binlog file '/var/log/mysql/mariadb-bin.003079' not found in binlog index, needed for recovery. Aborting.

mariadb 10.1.x galera 集群设置。

第一个节点 192.168.159.132

/etc/mysql/my.cnf

第一个节点 192.168.159.132

$ sudo 服务 mysql 引导程序

$ systemctl 状态 mariadb.service

为什么“Galera Cluster”没有启动？

如何检查“连接超时”？

之前部署过MariaDB Cluster，最近才出现这个问题（之前没有这个问题，不知道为什么）。

我有服务器 1、2 和 3。我在服务器 3 上执行了 INSERT 命令，但是，服务器 1 和 2 上的表保持不变。

3台服务器位于世界各地。After the INSERT command, the state uuid remains the same.

这是服务器 1 的状态：
MariaDB [mysql]> show status like 'wsrep_%'; +------------------------------+----------------------------------------------------------+ | Variable_name | Value | +------------------------------+----------------------------------------------------------+ | wsrep_local_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e | | wsrep_protocol_version | 7 | | wsrep_last_committed | 205 | | wsrep_replicated | 170 | | wsrep_replicated_bytes | 160481 | | wsrep_repl_keys | 664 | | wsrep_repl_keys_bytes | 9222 | | wsrep_repl_data_bytes | 140379 | | wsrep_repl_other_bytes | 0 | | wsrep_received | 46 | | wsrep_received_bytes | 26150 | | wsrep_local_commits | 170 | | wsrep_local_cert_failures | 0 | | wsrep_local_replays | 1 | | wsrep_local_send_queue | 0 | | wsrep_local_send_queue_max | 1 | | wsrep_local_send_queue_min | 0 | | wsrep_local_send_queue_avg | 0.000000 | | wsrep_local_recv_queue | 0 | | wsrep_local_recv_queue_max | 1 | | wsrep_local_recv_queue_min | 0 | | wsrep_local_recv_queue_avg | 0.000000 | | wsrep_local_cached_downto | 1 | | wsrep_flow_control_paused_ns | 0 | | wsrep_flow_control_paused | 0.000000 | | wsrep_flow_control_sent | 0 | | wsrep_flow_control_recv | 0 | | wsrep_cert_deps_distance | 7.482927 | | wsrep_apply_oooe | 0.009756 | | wsrep_apply_oool | 0.000000 | | wsrep_apply_window | 1.009756 | | wsrep_commit_oooe | 0.000000 | | wsrep_commit_oool | 0.000000 | | wsrep_commit_window | 1.000000 | | wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | wsrep_cert_index_size | 28 | | wsrep_causal_reads | 0 | | wsrep_cert_interval | 0.009756 | | wsrep_incoming_addresses | server1:3306,server2:3306,server3:3306 | | wsrep_evs_delayed | | | wsrep_evs_evict_list | | | wsrep_evs_repl_latency | 0.200155/0.201113/0.201752/0.000614937/4 | | wsrep_evs_state | OPERATIONAL | | wsrep_gcomm_uuid | c4f91b4f-fee1-11e5-8c4f-6e451c332f79 | | wsrep_cluster_conf_id | 3 | | wsrep_cluster_size | 3 | | wsrep_cluster_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e | | wsrep_cluster_status | Primary | | wsrep_connected | ON | | wsrep_local_bf_aborts | 6 | | wsrep_local_index | 0 | | wsrep_provider_name | Galera | | wsrep_provider_vendor | Codership Oy <info@codership.com> | | wsrep_provider_version | 25.3.14(r3560) | | wsrep_ready | ON | | wsrep_thread_count | 2 | +------------------------------+----------------------------------------------------------+

服务器 2 的状态：
MariaDB [(none)]> show status like 'wsrep_%'; +------------------------------+----------------------------------------------------------+ | Variable_name | Value | +------------------------------+----------------------------------------------------------+ | wsrep_local_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e | | wsrep_protocol_version | 7 | | wsrep_last_committed | 225 | | wsrep_replicated | 35 | | wsrep_replicated_bytes | 25700 | | wsrep_repl_keys | 119 | | wsrep_repl_keys_bytes | 1757 | | wsrep_repl_data_bytes | 21703 | | wsrep_repl_other_bytes | 0 | | wsrep_received | 187 | | wsrep_received_bytes | 177793 | | wsrep_local_commits | 35 | | wsrep_local_cert_failures | 0 | | wsrep_local_replays | 1 | | wsrep_local_send_queue | 0 | | wsrep_local_send_queue_max | 1 | | wsrep_local_send_queue_min | 0 | | wsrep_local_send_queue_avg | 0.000000 | | wsrep_local_recv_queue | 0 | | wsrep_local_recv_queue_max | 4 | | wsrep_local_recv_queue_min | 0 | | wsrep_local_recv_queue_avg | 0.032086 | | wsrep_local_cached_downto | 9 | | wsrep_flow_control_paused_ns | 0 | | wsrep_flow_control_paused | 0.000000 | | wsrep_flow_control_sent | 0 | | wsrep_flow_control_recv | 0 | | wsrep_cert_deps_distance | 7.193548 | | wsrep_apply_oooe | 0.004630 | | wsrep_apply_oool | 0.000000 | | wsrep_apply_window | 1.004630 | | wsrep_commit_oooe | 0.000000 | | wsrep_commit_oool | 0.000000 | | wsrep_commit_window | 1.000000 | | wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | wsrep_cert_index_size | 28 | | wsrep_causal_reads | 0 | | wsrep_cert_interval | 0.009217 | | wsrep_incoming_addresses | server1:3306,server2:3306,server3:3306 | | wsrep_evs_delayed | | | wsrep_evs_evict_list | | | wsrep_evs_repl_latency | 0.200138/0.201917/0.203696/0.00177914/2 | | wsrep_evs_state | OPERATIONAL | | wsrep_gcomm_uuid | d562e272-fee1-11e5-b2a2-d3a6b5579aab | | wsrep_cluster_conf_id | 3 | | wsrep_cluster_size | 3 | | wsrep_cluster_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e | | wsrep_cluster_status | Primary | | wsrep_connected | ON | | wsrep_local_bf_aborts | 0 | | wsrep_local_index | 1 | | wsrep_provider_name | Galera | | wsrep_provider_vendor | Codership Oy <info@codership.com> | | wsrep_provider_version | 25.3.14(r3560) | | wsrep_ready | ON | | wsrep_thread_count | 2 | +------------------------------+----------------------------------------------------------+ 57 rows in set (0.01 sec)

server3 的状态（如您所见，延迟显示全部为 0，但我不知道为什么）
MariaDB [(none)]> show status like 'wsrep_%'; +------------------------------+----------------------------------------------------------+ | Variable_name | Value | +------------------------------+----------------------------------------------------------+ | wsrep_local_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e | | wsrep_protocol_version | 7 | | wsrep_last_committed | 245 | | wsrep_replicated | 5 | | wsrep_replicated_bytes | 4350 | | wsrep_repl_keys | 11 | | wsrep_repl_keys_bytes | 203 | | wsrep_repl_data_bytes | 3827 | | wsrep_repl_other_bytes | 0 | | wsrep_received | 226 | | wsrep_received_bytes | 208559 | | wsrep_local_commits | 1 | | wsrep_local_cert_failures | 0 | | wsrep_local_replays | 0 | | wsrep_local_send_queue | 0 | | wsrep_local_send_queue_max | 1 | | wsrep_local_send_queue_min | 0 | | wsrep_local_send_queue_avg | 0.000000 | | wsrep_local_recv_queue | 0 | | wsrep_local_recv_queue_max | 1 | | wsrep_local_recv_queue_min | 0 | | wsrep_local_recv_queue_avg | 0.000000 | | wsrep_local_cached_downto | 19 | | wsrep_flow_control_paused_ns | 0 | | wsrep_flow_control_paused | 0.000000 | | wsrep_flow_control_sent | 0 | | wsrep_flow_control_recv | 0 | | wsrep_cert_deps_distance | 7.022026 | | wsrep_apply_oooe | 0.000000 | | wsrep_apply_oool | 0.000000 | | wsrep_apply_window | 1.000000 | | wsrep_commit_oooe | 0.000000 | | wsrep_commit_oool | 0.000000 | | wsrep_commit_window | 1.000000 | | wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | wsrep_cert_index_size | 28 | | wsrep_causal_reads | 0 | | wsrep_cert_interval | 0.008811 | | wsrep_incoming_addresses | server1:3306,server2:3306,server3:3306 | | wsrep_evs_delayed | | | wsrep_evs_evict_list | | | wsrep_evs_repl_latency | 0/0/0/0/0 | | wsrep_evs_state | OPERATIONAL | | wsrep_gcomm_uuid | fd022144-fee1-11e5-a7a3-f23274fef9c3 | | wsrep_cluster_conf_id | 3 | | wsrep_cluster_size | 3 | | wsrep_cluster_state_uuid | c4f9e2e2-fee1-11e5-8648-a22b867b5a6e | | wsrep_cluster_status | Primary | | wsrep_connected | ON | | wsrep_local_bf_aborts | 0 | | wsrep_local_index | 2 | | wsrep_provider_name | Galera | | wsrep_provider_vendor | Codership Oy <info@codership.com> | | wsrep_provider_version | 25.3.14(r3560) | | wsrep_ready | ON | | wsrep_thread_count | 2 | +------------------------------+----------------------------------------------------------+ 57 rows in set (0.00 sec)

所有三台服务器上的 iptables 都设置为接受所有输入和输出流量。

日志显示所有服务器已加入集群并与集群同步。

有谁知道为什么？谢谢。

我有两个 MariaDB Galera 集群（PROD（服务器 A、B 和 C）和 DR（服务器 1、2 和 3）。我从主组件节点（服务器 A）配置了标准复制（主从） PROD 集群到 DR 集群的主要组件节点（服务器 1）。每个集群可以正常独立运行（即，如果您对一个节点进行更改，那么集群中的所有节点都会立即复制更改）。

此配置的目的是允许我延迟在从属设备上应用中继日志一段预定的时间。不幸的是，MariaDB 10.1 不支持 MySQL 5.6/7 延迟中继日志应用程序。我正在使用 Percona 脚本来帮助控制从属进程，以便我可以改变将中继日志应用到 DR 集群之前的时间量。

当直接对 PROD 集群的主组件节点（Master - server A）进行更改时，更改会立即复制到 DR 集群的主组件节点（Slave - server 1），然后依次复制到所有节点（服务器 2 和 3) 位于 DR 集群中。但是，如果我对 PROD 集群中不是主要组件节点（服务器 A）的节点（例如服务器 C）进行更改，则这些更改不会复制到 DR 主要组件节点（从属 - 服务器 1）。

我怀疑驱动二进制日志记录的进程没有监听通过在端口 4567 上运行的 wsrep 集群复制进程表现出来的 PROD 集群中的更改，因此没有写入二进制日志文件。

有没有办法配置 MariaDB，以便通过集群的主要组件节点（主服务器 A）的二进制日志复制 PROD 集群的任何节点上的更改？

谢谢。

我有一个针对 MariaDB Galera 集群运行的 Laravel (Lumen 5.2) 项目。运行应用程序时，它似乎工作得很好。但是当我运行 PHPUnit 测试时，它们随机失败。

问题是我填充了数据库，然后尝试获取数据（id）以使用外键填充其他表。但是当尝试立即获取数据时，数据为空。

Laravel 数据库连接与 READ 用户和 WRITE 用户一起使用。（Laravel 在插入或读取时会自动使用正确的那个）。我认为这就是问题所在。当我只使用 WRITE 用户时，测试工作得很好。

我正在使用具有 5 个节点的 MariaDB Gallera 集群，数据库版本 10.0.23-MariaDB-1~trusty-wsrep-log(mariadb.org 二进制分发，wsrep_25.11.r21a2415) 供应商：mariadb ClusterControl UI 版本：1.3.0.1393 ClusterControl CMON版本：1.3.0.1242 CMON API 版本：1.3.0.183

所有节点都是 60GB 的 RAM，其中一个服务器消耗更多的 RAM，同时其他 4 个节点运行良好。

如何减少 mariadb1 服务器的 RAM 使用量？

请为此提供解决方案。

1. Hi I am trying to create a wordpress application using docker compose and I use the Galera MariaDB catalog entry from the rancher.

2. I can get all the set up working fine. I use external links and connect to the load balancer with some environment variable like this:

   external_links:

   • r-galera_galera-lb_1:mysql

3. I can see the tables being replicated in the cluster, however if I reboot the machine, even after the stack becomes active again, I fail to launch the application.

4. I get the error like this:

5. When I remove the whole Galera Stack and make a new one I get my wordpress setup working again.

   I had to come to this forum for this issue since I couldn't contact any maintainer of the catalog (there isn't any contact info). Can someone help in this regard ?

我正在尝试在 debian 8 jessie 下使用 MariaDB Galera 10.1。

我已经安装了所有必需的组件并进行了配置，但我无法让它工作。

节点构建为 VPS。

节点1的配置：

节点2的配置：

当我尝试在节点 1 引导命令上运行时

它因错误而失败

我正在使用的网络配置是私有的：

安装了 ProxmoxVE 4.0 的 2x 专用服务器，位于 vRack 网络中的服务器在 VPS 上配置为：

node1: 172.16.0.102 //节点1在服务器1上

node2: 172.16.0.112 //节点2在服务器2上

他们能够在专用网络上相互ping通。

我有一个 mysql 表，该表上有一个列（numviews），该表经常更新（相同的更新查询循环运行）。它花费了超过 2 秒的时间，我无法找到如何改进它，因为它也影响/减慢了我的应用程序，它依赖于这个表。这是mysql表。

注意：它是一个 innodb 表，没有其他慢查询。该表位于 mariadb galera 集群下。我也有300 个最大连接数。在任何时间点，全球连接都不会超过 170/180。

这是在循环上运行的 mysql 更新查询（它大约是在此表上运行的以下查询的 50 倍）。

编辑：我也可以看到一些僵局。

谁能帮我改进这个更新查询？