pxcクラスタ中のgcacheを計算する.sizeはどれくらい設定する必要がありますか

原文住所:https://www.percona.com/blog/2014/09/08/calculate-correct-size-percona-xtradb-clusters-gcache/
書き込みクエリーをPercona XtraDBクラスタに送信すると、すべてのノードがgcacheというファイルに書き込みセットを格納します.デフォルトでは、ファイルの名前はgaleraです.Cache、MySQLデータディレクトリに格納されます.これは非常に重要なファイルであり、通常のようにMySQLで最も重要な変数では、デフォルト値は高負荷サーバには適用されません.なぜ重要なのか、クラスタのワークロードに対して正しい値を計算する方法を見てみましょう.
gcacheとは?ノードがクラスタから離れる(クラッシュまたはメンテナンス)と、変更の受信が停止することは明らかです.ノードをクラスタに再接続しようとすると、データは古くなります.Joinerノードは、ダウンタイム中に発生した変更を寄付者に送信する必要があります.
ドナーはまず、ノードが閉じたときにクラスタの書き込みセットを受信するインクリメンタル(IST)の伝送を試みる.ドナーは、加入プログラムが受信した最後の書き込みセットをチェックし、ローカルgcacheファイルをチェックします.必要な書き込みセットがすべてキャッシュにある場合、寄付者はそれらをコネクタに送信します.結合プログラムはそれらを適用します.それだけで、最新でクラスタに参加する準備ができています.したがって、ISTは、失われたノードから漏れたすべての変更がドナーのgcacheファイルに残っている場合にのみ実現される.
一方、書き込みセットがない場合は、サポートされている方法XtraBackup、Rsyncまたはmysqldumpを使用して完全転送(SST)する必要があります.
要するに,ISTとSSTの違いは,ノードがクラスタに参加する時間を必要とすることである.差は数秒から数時間の間にある可能性があります.WAN接続や大型データセットの場合、数日かかる場合があります.
これが正しいgcacheが重要な理由です.ループ・ログとして動作するため、フルになると書き込みセットが最初から書き換えられます.より大きなgcacheを使用すると、ノードはSSTを使用せずにクラスタを離れる時間を増やすことができます.
正しいサイズを計算するテクニックが、正しいInnoDBログファイルのサイズを計算するテクニックと非常に似ている場合.毎分何バイト書き込まれているかを確認する必要があります.チェックする変数は次のとおりです.
wsrep_replicated_bytes:他のノードに送信される書き込みセットの合計サイズ(バイト単位).
wsrep_received_bytes:他のノードから受信した書き込みセットの合計サイズ(バイト単位).

   SQL：
show global status like 'wsrep_received_bytes'; 
show global status like 'wsrep_replicated_bytes'; 
select sleep(60); 
show global status like 'wsrep_received_bytes'; 
show global status like 'wsrep_replicated_bytes';

次に、本番環境で取得したデータ(クラスタ負荷が低い)を示します.

[(none)] 21:41:23 > show global status like 'wsrep_received_bytes'; 
+----------------------+------------+
| Variable_name        | Value      |
+----------------------+------------+
| wsrep_received_bytes | 2457075353 |
+----------------------+------------+
1 row in set (0.00 sec)

[(none)] 21:41:28 > show global status like 'wsrep_replicated_bytes'; 
+------------------------+------------+
| Variable_name          | Value      |
+------------------------+------------+
| wsrep_replicated_bytes | 1092525304 |
+------------------------+------------+
1 row in set (0.00 sec)

[(none)] 21:41:28 > select sleep(60); 
+-----------+
| sleep(60) |
+-----------+
|         0 |
+-----------+
1 row in set (1 min 0.00 sec)

[(none)] 21:42:28 > show global status like 'wsrep_received_bytes'; 
+----------------------+------------+
| Variable_name        | Value      |
+----------------------+------------+
| wsrep_received_bytes | 2461808265 |
+----------------------+------------+
1 row in set (0.01 sec)

[(none)] 21:42:28 > show global status like 'wsrep_replicated_bytes';
+------------------------+------------+
| Variable_name          | Value      |
+------------------------+------------+
| wsrep_replicated_bytes | 1095290728 |
+------------------------+------------+
1 row in set (0.00 sec)

1分あたりのバイト数:
(2番目のwsrep_received_bytes–1番目のwsrep_received_bytes)+(2番目のwsrep_replicated_bytes–1番目のwsrep_replicated_bytes)
ここで計算した結果は,(1095290728−1092525304)＋(2461808265−24570775353)＝7498336＝7.5 MBであった.
すなわち、1分間あたりのwriteset使用量は7.5 MB、1時間あたり7.5*60=450 MBであり、
従って、1時間のダウンタイムメンテナンスウィンドウを許可する場合、gcache.sizeは少なくとも450 MBである(生産環境は、一般的にはより多く推定され、1.5倍で計算すると、1時間のダウンタイムには675 MBのgcache.size値を設定する必要がある).