状態スナップショット転送（SST）は、ノードが同期されて「プライマリコンポーネント」の一部として宣言されるまで、ノードがクラスターに参加しているときに初期同期を実行するためにGaleraが使用する2つの方法の1つです。データセットのサイズとワークロードに応じて、SSTは非常に高速になるか、データベースサービスを停止させる高価な操作になる可能性があります。
SSTは、次の3つの方法で実行できます。
- mysqldump
- rsync（またはrsync_wan）
- xtrabackup（またはxtrabackup-v2、mariabackup）
ほとんどの場合、xtrabackup-v2とmariabackupが推奨されるオプションです。本番クラスターでrsyncまたはmysqldumpを実行している人はめったに見られません。
問題
SSTが開始されると、ジョイナーノードでトリガーされるいくつかのプロセスがあり、これらは「mysql」ユーザーによって実行されます。
$ ps -fu mysql
UID PID PPID C STIME TTY TIME CMD
mysql 117814 129515 0 13:06 ? 00:00:00 /bin/bash -ue /usr//bin/wsrep_sst_xtrabackup-v2 --role donor --address 192.168.55.173:4444/xtrabackup_sst//1 --socket /var/lib/mysql/mysql.sock --datadir
mysql 120036 117814 15 13:06 ? 00:00:06 innobackupex --no-version-check --tmpdir=/tmp/tmp.pMmzIlZJwa --user=backupuser --password=x xxxxxxxxxxxxxx --socket=/var/lib/mysql/mysql.sock --galera-inf
mysql 120037 117814 19 13:06 ? 00:00:07 socat -u stdio TCP:192.168.55.173:4444
mysql 129515 1 1 Oct27 ? 01:11:46 /usr/sbin/mysqld --wsrep_start_position=7ce0e31f-aa46-11e7-abda-56d6a5318485:4949331ドナーノードにいる間：
mysql 43733 1 14 Oct16 ? 03:28:47 /usr/sbin/mysqld --wsrep-new-cluster --wsrep_start_position=7ce0e31f-aa46-11e7-abda-56d6a5318485:272891
mysql 87092 43733 0 14:53 ? 00:00:00 /bin/bash -ue /usr//bin/wsrep_sst_xtrabackup-v2 --role donor --address 192.168.55.172:4444/xtrabackup_sst//1 --socket /var/lib/mysql/mysql.sock --datadir /var/lib/mysql/ --gtid 7ce0e31f-aa46-11e7-abda-56d6a5318485:2883115 --gtid-domain-id 0
mysql 88826 87092 30 14:53 ? 00:00:05 innobackupex --no-version-check --tmpdir=/tmp/tmp.LDdWzbHkkW --user=backupuser --password=x xxxxxxxxxxxxxx --socket=/var/lib/mysql/mysql.sock --galera-info --stream=xbstream /tmp/tmp.oXDumYf392
mysql 88827 87092 30 14:53 ? 00:00:05 socat -u stdio TCP:192.168.55.172:4444大規模なデータセット（数百Gバイト）に対するSSTは面白くありません。ハードウェア、ネットワーク、およびワークロードによっては、完了するまでに数時間かかる場合があります。運用中にサーバーリソースが飽和状態になる場合があります。 --rlimitおよび--use-memoryオプションを使用するSST（xtrabackupおよびmariabackupのみ）でスロットリングがサポートされているにもかかわらず、多数派のアクティブノードが不足している場合は、劣化したクラスターにさらされます。たとえば、運が悪ければ、3つのノードのうち1つしか実行されていないことに気付く場合です。したがって、静かな時間帯にSSTを実行することをお勧めします。ただし、このブログ投稿で説明されているように、手動の手順を実行することでSSTを回避できます。
SSTの停止
SSTの停止は、ドナーノードとジョイナーノードの両方で実行する必要があります。ジョイナーは、ローカルのGalera seqnoをクラスターのseqnoと比較するときに、ギャップの大きさを判別した後、SSTをトリガーします。 wsrep_sst_ {wsrep_sst_method}を実行します 指図。これは選択されたドナーによって選択され、ジョイナーへのデータのストリーミングが開始されます。ドナーノードには、Galeraグループ通信によって、または wsrep_sst_donor で定義された値によって選択されると、スナップショット転送の提供を拒否する機能がありません。 変数。同期が開始され、決定を元に戻したい場合、操作を停止する単一のコマンドはありません。
SSTを停止するときの基本原則は、次のとおりです。
- Galeraグループのコミュニケーションの観点から参加者を死んでいるように見せます（シャットダウン、フェンス、ブロック、リセット、ケーブルのプラグを抜く、ブラックリストなど）
- ドナーのSSTプロセスを強制終了します
ドナーでinnobackupexプロセス（kill -9 {innobackupex PID}）を強制終了するだけで十分だと思われるかもしれませんが、そうではありません。ジョイナーをフェンシングせずにドナー（またはジョイナー）のSSTプロセスを強制終了した場合でも、Galeraはジョイナーをアクティブとして認識し、SSTプロセスを未完了としてマークします。これにより、新しいプロセスセットが再生成され、続行または最初からやり直します。正方形に戻ります。これは、タイムアウトに対して脆弱なSST操作を保護するための/ usr / bin / wsrep_sst_ {method}スクリプトの予想される動作です（たとえば、実行時間が長く、リソースを大量に消費する場合）。
例を見てみましょう。クラスターに再参加したいクラッシュしたジョイナーノードがあります。まず、ジョイナーで次のコマンドを実行します。
$ systemctl start mysql # or service mysql start1分後、その特定の瞬間に操作が重すぎることがわかり、交通量の少ない時間帯にそれを延期することにしました。エクストラバックアップベースのSSTメソッドを停止する最も簡単な方法は、ジョイナーノードをシャットダウンし、ドナーノードのSST関連プロセスを強制終了することです。または、ジョイナーで次のiptablesコマンドを実行して、ジョイナーの着信ポートをブロックすることもできます。
$ iptables -A INPUT -p tcp --dport 4444 -j DROP
$ iptables -A INPUT -p tcp --dport 4567:4568 -j DROP次に、ドナーで、SSTプロセスのPIDを取得します（「mysql」ユーザーが所有するプロセスをリストアップします）：
$ ps -u mysql
PID TTY TIME CMD
117814 ? 00:00:00 wsrep_sst_xtrab
120036 ? 00:00:06 innobackupex
120037 ? 00:00:07 socat
129515 ? 01:11:47 mysqld最後に、mysqldプロセスを除くすべてを強制終了します（ドナーのmysqldプロセスを強制終了しないように非常に注意する必要があります！）：
$ kill -9 117814 120036 120037次に、ドナーのMySQLエラーログで、約100秒後に次の行が表示されることに注意してください。
2017-10-30 13:24:08 139722424837888 [Warning] WSREP: Could not find peer: 42b85e82-bd32-11e7-87ae-eff2b8dd2ea0
2017-10-30 13:24:08 139722424837888 [Warning] WSREP: 1.0 (192.168.55.172): State transfer to -1.-1 (left the group) failed: -32 (Broken pipe)この時点で、ドナーは wsrep_local_state_commentによって報告された「同期」状態に戻る必要があります。 SSTプロセスは完全に停止します。ドナーは運用状態に戻り、クライアントにフル稼働でサービスを提供できるようになりました。
ジョイナーのクリーンアッププロセスでは、iptablesチェーンをフラッシュするだけです。
$ iptables -Fまたは、-Dフラグを使用してルールを削除するだけです：
$ iptables -D INPUT -p tcp --dport 4444 -j DROP
$ iptables -D INPUT -p tcp --dport 4567:4568 -j DROP同様のアプローチは、rsync、mariabackup、mysqldumpなどの他のSSTメソッドでも使用できます。
SSTの調整（エクストラバックアップ方式のみ）
ドナーの忙しさにもよりますが、ドナーに大きな影響を与えないように、SSTプロセスを調整することをお勧めします。壊滅的な障害の際に、ユーザーが障害のあるクラスターを単一のブートストラップされたノードとして戻し、残りのメンバーが後で追いつくように必死になっているケースを数多く見てきました。この試みにより、アプリケーション側からのダウンタイムが削減されますが、残りのメンバーがダウンまたは回復している間、この「1ノードクラスター」に追加の負担がかかります。
Xtrabackupは--throttle=
[sst]
rlimit=128k
inno-apply-opts="--use-memory=200M"詳細については、PerconaXtrabackupSSTのドキュメントページをご覧ください。
ただし、落とし穴があります。プロセスが非常に遅いため、InnoDBが書き込んでいるトランザクションログに追いつかない可能性があるため、SSTが完了しない可能性があります。一般に、この状況は非常にまれです。ただし、実際に書き込みが非常に多いワークロードがある場合、またはSSTに非常に限られたリソースを割り当てる場合を除きます。
結論
SSTは重要ですが重いため、データセットのサイズとノード間のネットワークスループットによっては、長時間実行される可能性があります。結果に関係なく、運用を停止する可能性があります。これにより、より適切な時期に、より適切な復旧計画を立てることができます。