起搏器無法在第二個節點上啟動 MySQL
我在 2 個物理上相同的 Ubuntu Server 16.04 LTS 上有一個起搏器/corosync/drbd 設置，我正在嘗試實現 MySQL 5.7 和 Apache 2.4 的高可用性。
兩台伺服器都以完全相同的方式設置並安裝了完全相同的軟體包。唯一的區別是pacemaker/corosync/drbd 中的主機名、IP 地址和主/從配置。
我的問題是起搏器能夠在節點 1 上啟動 MySQL 伺服器和所有其他服務，但是當我模擬節點 1 的崩潰時，起搏器無法在節點 2 上啟動 MySQL 服務。
這是 crm_mon 的輸出（兩個節點都線上）：
Last updated: Wed Jan 10 18:57:02 2018 Last change: Wed Jan 10 18:00:19 2018 by root via crm_attribute on Server1 Stack: corosync Current DC: Server1 (version 1.1.14-70404b0) - partition with quorum 2 nodes and 7 resources configured Online: [ Server1 Server2 ] Master/Slave Set: ms_r0 [r0] Masters: [ Server1 ] Slaves: [ Server2 ] Resource Group: WebServer ClusterIP (ocf::heartbeat:IPaddr2): Started Server1 WebFS (ocf::heartbeat:Filesystem): Started Server1 Links (ocf::heartbeat:drbdlinks): Started Server1 DBase (ocf::heartbeat:mysql): Started Server1 WebSite (ocf::heartbeat:apache): Started Server1但是當我模擬節點 1 的崩潰時，我得到：
Last updated: Wed Jan 10 19:05:25 2018 Last change: Wed Jan 10 19:05:17 2018 by root via crm_attribute on Server1 Stack: corosync Current DC: Server1 (version 1.1.14-70404b0) - partition with quorum 2 nodes and 7 resources configured Node Server1: standby Online: [ Server2 ] Master/Slave Set: ms_r0 [r0] Masters: [ Server2 ] Resource Group: WebServer ClusterIP (ocf::heartbeat:IPaddr2): Started Server2 WebFS (ocf::heartbeat:Filesystem): Started Server2 Links (ocf::heartbeat:drbdlinks): Started Server2 DBase (ocf::heartbeat:mysql): Stopped WebSite (ocf::heartbeat:apache): Stopped Failed Actions: * DBase_start_0 on Server2 'unknown error' (1): call=45, status=complete , exitreason='MySQL server failed to start (pid=3346) (rc=1), please check your installation', last-rc-change='Wed Jan 10 17:58:15 2018', queued=0ms, exec=2202ms這是我最初的 Pacemaker 配置：https ://pastebin.com/kEYjjgKw
在我認識到在節點 2 上啟動 MySQL 存在問題後，我做了一些研究並讀到應該在起搏器配置中將一些附加參數傳遞給 MySQL。這就是為什麼我將 Pacemaker 配置更改為：https ://pastebin.com/J7Zk1kBA
不幸的是，這並沒有解決問題。
據我了解，Pacemaker 在兩台機器上使用相同的命令來啟動 MySQL 守護程序。這就是為什麼我覺得它無法在以完全相同的方式配置的節點 2 上啟動 MySQL 有點荒謬。
drbd0 正在被起搏器掛載，並且 drbdlinks 正在為 /var/www 和 /var/lib/mysql 創建符號連結
我測試了這個功能，它似乎工作。當節點 1 離線時，drbd0 會掛載到節點 2 上並創建符號連結。/var/lib/mysql 指向 drbd0 並且所有文件都在目錄中。
如果您對如何縮小導致此問題的原因有任何想法/建議，如果您能在此處發布它們，我將非常感激。
如果需要更多資訊，我很樂意提供。
提前致謝！
問候， 帕爾布雷希特
過去，當我不得不使用起搏器時，我在解決此類問題時會使用一些不同的程序。一般的想法是驗證起搏器配置的每個依賴“層”，其中依賴圖是：
mysql -> mounting of filesystem -> DRBD masterClusters from Scratch也有一個非常相似的配置的很好的演練。
首先要確保 DRBD 已配置並同步。在任一節點上，執行：
cat /proc/drbd如果 DRBD 已完全同步並準備好進行故障轉移，則輸出應顯示如下內容（參見 CfS 的第 45 頁）：
[root@pcmk-1 ~]# cat /proc/drbd version: 8.4.6 (api:1/proto:86-101) GIT-hash: 833d830e0152d1e457fa7856e71e11248ccf3f70 build by phil@Build64R7, 2015-04-10 05:13:52 1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----- ns:1048508 nr:0 dw:0 dr:1049420 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0如果
cat /proc/drbd輸出類似的東西（也在 CfS 的第 45 頁上）
[root@ovz-node1 ~]# cat /proc/drbd version: 0.7.17 (api:77/proto:74) SVN Revision: 2093 build by phil@mescal, 2006-03-06 15:04:12 0: cs:SyncSource st:Primary/Secondary ld:Consistent ns:627252 nr:0 dw:0 dr:629812 al:0 bm:38 lo:640 pe:0 ua:640 ap:0 [=>..................] sync'ed: 6.6% (8805/9418)M finish: 0:04:51 speed: 30,888 (27,268) K/sec則係統未處於可以成功進行故障轉移的狀態。等待它完成，然後重試故障轉移測試。
假設 DRBD 在節點 1 的模擬故障之前同步，當數據庫未在節點 2 上執行時故障轉移到節點 2 後要嘗試的下一件事是登錄到節點 2 並檢查以下內容：
- 是否
cat /proc/drbd將 node2 顯示為主節點？- 是否
mount顯示 /dev/drbd0 安裝在其配置的安裝點（來自 pastebin，這應該是 ‘/sync’）？- 是否已設置所有預期的符號連結？
- 您是否在節點 2 上的 /sync 中看到與故障轉移之前節點 1 上相同的文件？
最重要的是，如果所有這些問題的回答都是肯定的：
- 在 node2 上手動啟動 MySQL 是否會成功啟動（可能使用
/etc/init.d/mysql start或 systemctl 等效項）？- 如果 MySQL 啟動，mysql 客戶端是否顯示正在執行的伺服器實際上正在提供儲存在 /sync 下的數據庫數據？可以使用 node2 上的 mysql 客戶端訪問已知在 node1 上工作的數據庫和表嗎？
如果 MySQL 手動啟動，那麼它的起搏器配置可能有問題。
完全公開：我沒有親自使用過 ocf::heartbeat:mysql 資源；相反，我使用了“lsb”資源“lsb:mysql”。