MySQL(Q4M) + DRBD + HA(Pacemaker/corosync) 構築手順 (障害対応/復旧手順編)
先行の記事(https://ogugu.hateblo.jp/entry/2019/07/02/121645)で構築完了したが、日々の運用で発生した障害対応を行った時の情報を知見として作業記録メモを残す。
HA / DRBD(冗長化)構築に伴い、障害対応時の確認事項が多い為、参考資料として共有。
- 以下構築要件
- 先行の記事参照
■ 障害状況
# crm_mon Last updated: Fri Jun 21 17:05:18 2019 Last change: Fri Jun 21 16:26:10 2019 Stack: corosync Current DC: drbd01 (176359015) - partition with quorum Version: 1.1.12-561c4cf 2 Nodes configured 3 Resources configured Online: [ drbd01 drbd02 ] Full list of resources: Master/Slave Set: ms-drbd_data [drbd_data] Masters: [ drbd01 ] Slaves: [ drbd02 ] fs_data (ocf::heartbeat:Filesystem): Started drbd01 Node Attributes: * Node drbd01: + master-drbd_data : 10000 + ringnumber_0 : 10.131.6.103 is UP * Node drbd02: + master-drbd_data : 1000 + ringnumber_0 : 10.131.6.175 is UP Operations: * Node drbd02: fs_data: migration-threshold=1 fail-count=1 last-failure='Fri Jun 21 16:49:09 2019' + (17) monito
■ 両ノードがStandAlone状態
drbd01がプライマリ-(ro:Primary),drbd02がセカンダリー(ro:Secondary)となっており、csのステータスがどちらも「cs:StandAlone」となっていれば確認は完了です。
もし、どちらかのcsのステータスが接続待ち状態であることを示す「cs:WFConnection」となっていたら、cs:WFConnectionとなっているサーバで以下の切断コマンドを実行して、「StandAlone」に戻します。
# drbdadm disconnect r0
「cat /proc/drbd」コマンドを再実行して、ステータスが「cs:StandAlone」に変わったことを確認できれば準備は完了です。
drbd02のデータを破棄します。
# drbdadm -- --discard-my-data connect r0
csのステータスが「cs: WFConnection」、roのステータスが「ro:Secondary」となったことを確認します。データを破棄したことによって、drbd02はスタンドアロン状態から「(drbd01との)接続待ち」状態に変更されました。
drbd01の状態がcsのステータスは「cs:StandAlone」、roのステータスは「ro:Primary」となっている事を確認したら、drbd01でDRBD接続コマンドを実行します。
# drbdadm connect r0
接続コマンドを実行すると、drbd01は以下の状態に変わります。
# cat /proc/drbd version: 8.4.8-1 (api:1/proto:86-101) GIT-hash: 22b4c802192646e433d3f7399d578ec7fecc6272 build by mockbuild@, 2016-10-13 19:58:26 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----- ns:2056 nr:0 dw:32790 dr:76120 al:2 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0 1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r----- ns:996 nr:0 dw:58900 dr:230731 al:5 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:4088 [===================>] sync'ed:100.0% (4088/5084)K finish: 0:00:03 speed: 996 (996) K/sec
DRBD接続コマンド実行後のdrbd01の状態がroのステータスは「ro:Primary/Secondary」に、csのステータスは「Connected」「SyncSource」となり、drbd01は同期元として、drbd02と正しく接続されました。
接続完了と同時に、DRBDでの同期が再実行されます。
※一部引用
https://www.atmarkit.co.jp/ait/articles/1612/16/news015_3.html
◆ 実際の復旧手順
drbd01:secondary側(旧primary)
drbd02:primary側(旧secondary)
・現状ステータス確認
[root@drbd01 ~]# /etc/init.d/drbd status m:res cs ro ds p mounted fstype 0:r0 StandAlone Secondary/Unknown UpToDate/DUnknown r----- [root@drbd02 ~]# /etc/init.d/drbd status m:res cs ro ds p mounted fstype 0:r0 StandAlone Primary/Unknown UpToDate/DUnknown r----- ext4
・secondary側のDRBDリソースをセカンダリ状態へ変更
[root@drbd01 ~]# drbdadm secondary r0 [root@drbd01 ~]# /etc/init.d/drbd status m:res cs ro ds p mounted fstype 0:r0 StandAlone Secondary/Unknown UpToDate/DUnknown r-----
・secondary側のメタデータを破棄
[root@drbd01 ~]# drbdadm -- --discard-my-data connect r0 [root@drbd01 ~]# /etc/init.d/drbd status m:res cs ro ds p mounted fstype 0:r0 WFConnection Secondary/Unknown UpToDate/DUnknown C
・primary側でステータス確認
[root@drbd02 ~]# /etc/init.d/drbd status m:res cs ro ds p mounted fstype 0:r0 StandAlone Primary/Unknown UpToDate/DUnknown r----- ext4
※Primary側がStandAloneの場合、Primaryへ昇格させる
[root@drbd01 ~]# /etc/init.d/drbd status m:res cs ro ds p mounted fstype 0:r0 StandAlone Secondary/Unknown UpToDate/DUnknown r----- [root@drbd01 ~]# drbdadm Primary r0 [root@drbd01 ~]# /etc/init.d/drbd status m:res cs ro ds p mounted fstype 0:r0 StandAlone Primary/Unknown UpToDate/DUnknown r-----
・primary側で手動再同期
[root@drbd02 ~]# drbdadm connect r0 [root@drbd02 ~]# /etc/init.d/drbd status m:res cs ro ds p mounted fstype 0:r0 Connected Primary/Secondary UpToDate/UpToDate C /data ext4
※自動マウントされてない場合、手動にて実行
# mount -t ext4 /dev/drbd0 /data/
・secondary側ステータス確認
[root@drbd01 ~]# /etc/init.d/drbd status m:res cs ro ds p mounted fstype 0:r0 Connected Secondary/Primary UpToDate/UpToDate C
■ 故障履歴の表示、クリア
・個別リソース
[root@drbd01 ~]# crm resource failcount drbd_data show drbd01 scope=status name=fail-count-drbd_data value=0 [root@drbd01 ~]# crm resource failcount fs_data show drbd01 scope=status name=fail-count-fs_data value=0 [root@drbd01 ~]# crm resource cleanup fs_data Cleaning up fs_data on drbd01 Waiting for 2 replies from the CRMd.. OK
●Master/Slave の障害履歴のクリア
・確認
Online: [ drbd01 drbd02 ] Master/Slave Set: ms_res_drbd Masters: [ drbd02 ] Stopped: [ res_drbd:0 ] res_fs (ocf::heartbeat:Filesystem): Started drbd02
・履歴クリア
[root@drbd02 ~]# crm resource cleanup ms_res_drbd Online: [ drbd01 drbd02 ] Master/Slave Set: ms_res_drbd Masters: [ drbd02 ] Slaves: [ drbd01 ] res_fs (ocf::heartbeat:Filesystem): Started drbd02
■ crm コマンドリファレンス
crm configure [リソースの定義] # リソースの追加 crm configure delete [リソース名] # リソースの削除 crm configure save backup.crm # バックアップ crm configure load update backup.crm # 外部ファイル読み込み crm configure show # 設定内容確認 crm configure erase # 設定削除 ただし、ノードが「running」ステータスでは下記のようなエラーが発生します。 WARNING: resource IPaddr2_1 is running, can't delete it WARNING: resource pingd_gw is running, can't delete it WARNING: resource prmVIPcheck is running, can't delete it ERROR: CIB erase aborted (nothing was deleted) その場合は、全ノードを「standby」ステータスに切り替え、「running」ステータス以外にする事が必要です。 crm resource start # リソースの開始 crm resource stop # リソースの停止 crm resource cleanup [リソース名] [ノード名] # 故障履歴の削除 crm node list # ノードの一覧 crm node delete [ノード名] # ノードの削除 crm node standby server1 # ノードstandby crm node online server1 # ノードonline
ref)
http://infra.blog.shinobi.jp/Entry/44/
https://hogem.hatenablog.com/entry/20080706/1215341445
https://linux-ha.osdn.jp/wp/archives/1338#i-3