節點無法加入 MariaDB Galera 集群
*我正在嘗試為我的 MariaDB 集群設置第三個節點。*我從我的第二個節點（加入集群並可以啟動自己的集群）複製了 server.cnf 文件。前兩個使用類似的文件結構可以正常工作，因為我已經測試了複製並且使一台伺服器失敗以讓另一台接管並重新啟動該伺服器。這只是一個測試集群，可以幫助我了解它（MariaDB/Galera）是如何工作的。我為我的三個 CentOS 7 虛擬伺服器使用 MariaDB 版本 10.1-24。如果它有任何損害，你會發現，在我收到第三個虛擬伺服器之前，我引導並使用了前兩個伺服器。
問題
但是，儘管更改了節點的名稱和地址，但將文件從第二台伺服器複製到第三台伺服器似乎不起作用。我還編輯了其他兩個文件，以便地址為
"gcomm://node1,node2,node3"（將 nodeX 替換為每個伺服器的正確 IP 地址）。然後我在引導引導節點後啟動了該節點。但是，啟動它後，我並沒有看到它加入集群。我能夠並且仍然可以訪問 MySQL 並進行一些測試，但是當我查看集群大小時，我得到了這個：[root@node3 ~]# mysql -uroot -e "show status like 'wsrep_cluster_size';" +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 0 | +--------------------+-------+主節點也不會報告加入集群的節點：
[root@node1 ~]# mysql -uroot -e "SHOW STATUS LIKE 'wsrep_cluster_size';" +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 1 | +--------------------+-------+來這里之前我做了什麼？
我查看了其他幾個有類似問題的人，但確認他們與我的問題無關。我檢查以確保
wsrep_on=ON該地址正確指向其他節點，該節點對其集群夥伴具有唯一名稱等。我將這兩個工作文件與第三個節點進行了比較，它們都是相同的（當然，除了節點的 IP 地址和名稱）。我決定測試是否可能是集群本身的問題，所以我將此節點設置為自己的集群，但引導它仍然沒有任何結果。我使用了原始集群的 server.cnf 文件，看看它是否可以工作，但仍然沒有任何變化。此後，我將其恢復為您將在下面看到的版本。
在 CentOS7 上，我已確認 SELinux 已設置為允許，並且已為我的測試過程禁用/關閉了 firewalld。我知道這是一個問題，因為當我將第一台伺服器放在一起時，由於 SELinux 和 firewalld，它沒有引導。這是我檢查的第一件事。
節點文件
這是問題節點的配置文件：
[mysqld] bind-address=0.0.0.0 # # * Galera-related settings # [galera] # Mandatory settings wsrep_on=ON wsrep_provider=/usr/lib64/galera/libgalera_smm.so binlog_format=ROW innodb_autoinc_lock_mode=2 innodb_locks_unsafe_for_binlog=1 query_cache_size=0 query_cache_type=0 default_storage_engine=InnoDB innodb_log_file_size=100M innodb_file_per_table innodb_flush_log_at_trx_commit=2 wsrep_cluster_address="gcomm://10.32.18.90,10.32.18.91,10.32.18.92" #wsrep_cluster_address="gcomm://" wsrep_cluster_name='galera' wsrep_node_address='10.32.18.92' wsrep_node_name='node3' wsrep_sst_method=rsync #wsrep_sst_auth=test:PASS這是該文件所基於的第二個節點：
[mysqld] bind-address=0.0.0.0 # # * Galera-related settings # [galera] wsrep_on=ON wsrep_provider=/usr/lib64/galera/libgalera_smm.so binlog_format=ROW innodb_autoinc_lock_mode=2 innodb_locks_unsafe_for_binlog=1 query_cache_size=0 query_cache_type=0 default_storage_engine=InnoDB innodb_log_file_size=100M innodb_file_per_table innodb_flush_log_at_trx_commit=2 wsrep_cluster_address="gcomm://10.32.18.90,10.32.18.91,10.32.18.92" #wsrep_cluster_address="gcomm://" wsrep_cluster_name='galera' wsrep_node_address='10.32.18.91' wsrep_node_name='node2' wsrep_sst_method=rsync #wsrep_sst_auth=test:PASS來自 systemctl status mariadb.service -l 的錯誤日誌
mariadb.service - MariaDB database server Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/mariadb.service.d └─migrated-from-my.cnf-settings.conf Active: active (running) since Mon 2017-06-26 10:38:50 EDT; 25s ago Process: 5488 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS) Process: 5448 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/SUCCESS) Process: 5445 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS) Main PID: 5460 (mysqld) Status: "Taking your SQL requests now..." CGroup: /system.slice/mariadb.service └─5460 /usr/sbin/mysqld Jun 26 10:38:50 node3.libvirt mysqld[5460]: 2017-06-26 10:38:50 140610510633216 [Note] InnoDB: Highest supported file format is Barracuda. Jun 26 10:38:50 node3.libvirt mysqld[5460]: 2017-06-26 10:38:50 140610510633216 [Note] InnoDB: 128 rollback segment(s) are active. Jun 26 10:38:50 node3.libvirt mysqld[5460]: 2017-06-26 10:38:50 140610510633216 [Note] InnoDB: Waiting for purge to start Jun 26 10:38:50 node3.libvirt mysqld[5460]: 2017-06-26 10:38:50 140610510633216 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.36-82.0 started; log sequence number 1616839 Jun 26 10:38:50 node3.libvirt mysqld[5460]: 2017-06-26 10:38:50 140609750824704 [Note] InnoDB: Dumping buffer pool(s) not yet started Jun 26 10:38:50 node3.libvirt mysqld[5460]: 2017-06-26 10:38:50 140610510633216 [Note] Plugin 'FEEDBACK' is disabled. Jun 26 10:38:50 node3.libvirt mysqld[5460]: 2017-06-26 10:38:50 140610510633216 [Note] Server socket created on IP: '::'. Jun 26 10:38:50 node3.libvirt mysqld[5460]: 2017-06-26 10:38:50 140610510633216 [Note] /usr/sbin/mysqld: ready for connections. Jun 26 10:38:50 node3.libvirt mysqld[5460]: Version: '10.1.24-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server Jun 26 10:38:50 node3.libvirt systemd[1]: Started MariaDB database server.TL; 博士
問題/問題：第三個節點不會加入現有集群，也無法引導以創建自己的集群。伺服器 3 使用與 1 和 2 類似的配置設置。但是，原始的兩台伺服器都可以工作，並且能夠執行 MariaDB 集群需要和可以執行的任何操作。在設置階段我可能做錯了什麼？
我試過的（沒有特別的順序）：
- 重新啟動伺服器
- 檢查 SELinux 和 firewalld 以確保它們分別被允許和關閉
- 確保 wsrep 設置正確（並且打開）
- 確保 rsync 已下載且為最新版本
- 將問題節點作為自己的集群啟動
- 解除安裝並重新安裝 MariaDB
- 來自 ServerFault 的這個問題
- Galera 自己的文件
- MariaDB 自己的文件
- 直到（包括）Google 的第 9 頁，使用同一問題的不同版本
如果需要更多資訊，請務必說出來。我想讓所有各方都盡可能輕鬆地完成這個過程。
所以我設法弄清楚問題的原因是什麼。顯然，我已經刪除了
/etc/my.cnf（不是文件夾，只是my.cnf）。直到今天，當我試圖找到 eroomydna 的錯誤日誌時，我才意識到這一點。因此，它沒有被寫入，因為該文件不存在並告訴 mysql 要包含哪個目錄。如果其他人遇到問題並且他們也沒有說文件，請添加並寫入：[client-server] !includedir /etc/my.cnf.d當我不小心打開第一台伺服器時，我意識到這個文件失去了，當我選擇自動完成打開
/etc/my.cnf.d/server.cnf時，my.cnf.d由於存在my.cnf.