以前、MySQL Galera Cluster 4.0の新機能、ストリーミングレプリケーションとMariaDB 10.4での大規模なトランザクションの処理についてブログを書き、パート1とパート2のシリーズで新しいストリーミングレプリケーション機能を使用するためのガイドをいくつか紹介しました。
データベーステクノロジーをMySQLレプリケーションからMySQLガレラクラスターに移行するには、適切なスキルと、成功するために何をしているのかを理解している必要があります。このブログでは、MySQLレプリケーション設定からMySQL GaleraCluster4.0に移行するためのヒントをいくつか紹介します。
MySQLレプリケーションとGaleraクラスターの違い
Galeraにまだ慣れていない場合は、Galera ClusterforMySQLチュートリアルを確認することをお勧めします。 Galera Clusterは、非同期レプリケーションを使用するMySQLレプリケーションとは対照的に、同期レプリケーションに基づくまったく異なるレベルのレプリケーションを使用します（ただし、準同期レプリケーションを実現するように構成することもできます）。
Galera Clusterは、マルチマスターレプリケーションもサポートしています。制約のない並列適用（つまり、「並列レプリケーション」）、マルチキャストレプリケーション、および自動ノードプロビジョニングが可能です。
Galera Clusterの主な焦点はデータの一貫性ですが、MySQLレプリケーションでは、データの不整合が発生しやすくなります（これは、ベストプラクティスと、回避するためにスレーブに読み取り専用を適用するなどの適切な構成で回避できます）。スレーブ内の不要な書き込み）。
Galeraが受信したトランザクションはすべてのノードに適用されるか、まったく適用されませんが、これらの各ノードは、アプライヤーキュー内のレプリケートされた書き込みセット（トランザクションコミット）を認証します。これには、すべてのノードに関する情報も含まれます。トランザクション中にデータベースによって保持されたロック。これらの書き込みセットは、競合するロックが識別されなくなると、適用されます。この時点まで、トランザクションはコミットされたと見なされ、テーブルスペースに適用され続けます。非同期レプリケーションとは異なり、書き込みとコミットは論理同期モードで行われるため、このアプローチは仮想同期レプリケーションとも呼ばれますが、テーブルスペースへの実際の書き込みとコミットは独立して行われ、各ノードで非同期になります。
MySQLレプリケーションとは異なり、Galera Clusterは、マスターフェイルオーバーや読み取り/書き込み分割を必要としない、真のマルチマスター、マルチスレッドスレーブ、純粋なホットスタンバイです。ただし、Galera Clusterに移行しても、問題が自動的に解決されるわけではありません。 Galera ClusterはInnoDBのみをサポートしているため、MyISAMまたはメモリストレージエンジンを使用している場合は、設計が変更される可能性があります。
Galera ClusterではMyISAMを使用できますが、これはGaleraClusterが設計された目的ではありません。 Galera Clusterは、クラスター内のすべてのノード内でデータの一貫性を厳密に実装するように設計されており、これには強力なACID準拠のデータベースエンジンが必要です。 InnoDBは、この分野でこの強力な機能を備えたエンジンであり、InnoDBを使用することをお勧めします。特にトランザクションを処理する場合。
ClusterControlを使用している場合は、パフォーマンスアドバイザーが提供するMyISAMテーブルのデータベースインスタンスを簡単に特定できます。これは、[パフォーマンス]→[アドバイザ]タブにあります。たとえば、
MyISAMテーブルとMEMORYテーブルが必要な場合は、引き続き使用できますが、複製する必要のないデータを確認してください。保存されたデータは読み取り専用で使用でき、必要に応じて「STARTTRANSACTIONREADONLY」を使用できます。
Galera ClusterはInnoDBのみをサポートしているため、すべてのテーブルにクラスター化インデックス（主キーまたは一意キーとも呼ばれる）が必要であることが非常に重要です。クエリ、挿入、およびその他のデータベース操作から最高のパフォーマンスを得るには、InnoDBがクラスター化インデックスを使用して各テーブルの最も一般的なルックアップおよびDML操作を最適化するため、すべてのテーブルを一意のキーで定義する必要があることが非常に重要です。 。これにより、クラスター内で長時間実行されるクエリを回避でき、クラスター内の書き込み/読み取り操作が遅くなる可能性があります。
ClusterControlには、これを通知できるアドバイザーがいます。たとえば、MySQLレプリケーションマスター/スレーブクラスターでは、アドバイザのリストのまたはビューからアラームが発生します。以下のスクリーンショットの例は、主キーを持たないテーブルがないことを示しています。
マスター（またはアクティブライター）ノードを特定する
Galera Clusterは、純粋に真のマルチマスターレプリケーションです。ただし、ターゲットにしたいノードを自由に作成できるという意味ではありません。確認すべきことの1つは、別のノードに書き込んでいて競合するトランザクションが検出されると、次のようなデッドロックの問題が発生することです。
2019-11-14T21:14:03.797546Z 12 [Note] [MY-011825] [InnoDB] *** Priority TRANSACTION:
TRANSACTION 728431, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
MySQL thread id 12, OS thread handle 140504401893120, query id 1414279 Applying batch of row changes (update)
2019-11-14T21:14:03.797696Z 12 [Note] [MY-011825] [InnoDB] *** Victim TRANSACTION:
TRANSACTION 728426, ACTIVE 3 sec updating or deleting
mysql tables in use 1, locked 1
, undo log entries 11409
MySQL thread id 57, OS thread handle 140504353195776, query id 1414228 localhost root updating
update sbtest1_success set k=k+1 where id > 1000 and id < 100000
2019-11-14T21:14:03.797709Z 12 [Note] [MY-011825] [InnoDB] *** WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1663 page no 11 n bits 144 index PRIMARY of table `sbtest`.`sbtest1_success` trx id 728426 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
0: len 8; hex 73757072656d756d; asc supremum;;現在のアクティブライターノードを識別せずに書き込みを行う複数のノードの問題。これらの問題は、GaleraClusterを使用して複数のノードに書き込むときに見た非常に一般的な問題になります。同時に。これを回避するために、シングルマスターセットアップアプローチを使用できます：
フロー制御を緩和するには、以下の設定を使用できます。
wsrep_provider_options = "gcs.fc_limit = 256; gcs.fc_factor = 0.99; gcs.fc_master_slave = YES"fc_master_slaveは動的ではないため、上記ではサーバーを再起動する必要があります。
実際には、wsrep_logs_conflictsを有効にするのが最善です。これにより、競合するMDLの詳細とクラスター内のInnoDBロックがログに記録されます。この変数の有効化は動的に設定できますが、有効にすると注意が必要です。エラーログファイルに詳細にデータが入力され、エラーログファイルのサイズが大きすぎるとディスクがいっぱいになる可能性があります。
DDLクエリに注意してください
MySQLレプリケーションとは異なり、ALTERステートメントの実行は、ALTERステートメントの対象となるテーブルにアクセスまたは参照する必要がある着信接続にのみ影響を与える可能性があります。テーブルが大きく、スレーブの遅延をもたらす可能性がある場合にも、スレーブに影響を与える可能性があります。ただし、クエリが現在のALTERと競合しない限り、マスターへの書き込みはブロックされません。ただし、これは、GaleraClusterでALTERなどのDDLステートメントを実行する場合にはまったく当てはまりません。 ALTERステートメントは、クラスター全体のロックが原因でGalera Clusterがスタックしたり、一部のノードが大規模な書き込みから回復しているときにフロー制御がレプリケーションを緩和し始めたりするなどの問題を引き起こす可能性があります。
状況によっては、Galera Clusterのテーブルが大きすぎて、アプリケーションにとって主要かつ重要なテーブルである場合、ダウンタイムが発生する可能性があります。ただし、ダウンタイムなしで実現できます。リック・ジェームスが彼のブログで指摘したように、以下の推奨事項に従うことができます：
RSUとTOI
- ローリングスキーマのアップグレード=一度に1つのノード（オフライン）を手動で実行します
- 全順序の分離=Galeraは同期して、すべてのノードで同時に（複製シーケンスで）実行されるようにします。 RSUとTOI
注意：クライアントをDDLと同期する方法がないため、クライアントが古いスキーマまたは新しいスキーマのいずれかに満足していることを確認する必要があります。それ以外の場合は、スキーマとクライアントコードの両方を同時に切り替えると同時に、クラスター全体を停止する必要があります。
- CREATE / DROP / RENAME DATABASE / TABLE
- ALTERでデフォルトを変更
- ENUMまたはSETの定義を変更するALTER（マニュアルの警告を参照）
- ドロップインデックス（主キー以外）
- インデックスを追加しますか？
- 5.6、特に5.7ではALTER ALGORITHM =INPLACEのケースが多いため、どのALTERをどの方法で実行する必要があるかを確認してください。
それ以外の場合は、RSUを使用します。ノードごとに個別に次の手順を実行します。
SET GLOBAL wsrep_OSU_method='RSU';これにより、ノードもクラスターから削除されます。
ALTER TABLE
SET GLOBAL wsrep_OSU_method='TOI';元に戻し、再同期につながります（できれば、遅いSSTではなく速いIST）
Galeraはバイナリログに依存しないため、GaleraClusterはbinlog_do_dbやbinlog_ignore_dbなどのレプリケーションフィルターをサポートしていません。これは、クラスターに沿って複製される書き込みセットを格納するGCacheとも呼ばれるリングバッファーファイルに依存しています。このようなデータベースノードの一貫性のない動作や状態を適用することはできません。
一方、Galeraは、クラスター内でデータの一貫性を厳密に実装します。行またはレコードが見つからない場合に、不整合が発生する可能性があります。たとえば、変数wsrep_OSU_methodをDDL ALTERステートメントにRSUまたはTOIのいずれかに設定すると、動作に一貫性がなくなる可能性があります。 TOIとRSUのGaleraとの不一致について説明している、Perconaのこの外部ブログを確認してください。
wsrep_on =OFFを設定し、続いてDMLまたはDDLクエリを実行すると、クラスターにとって危険な場合があります。結果がノードの状態または環境に依存しない場合は、ストアドプロシージャ、トリガー、関数、イベント、またはビューも確認する必要があります。特定のノードに一貫性がない場合、クラスター全体がダウンする可能性があります。 Galeraが一貫性のない動作を検出すると、Galeraはクラスターを離れ、そのノードを終了しようとします。したがって、すべてのノードに一貫性がなく、ジレンマ状態に陥る可能性があります。
特にトラフィックの多い時間帯にGaleraClusterノードでもクラッシュが発生する場合は、ノードをすぐに起動しないことをお勧めします。代わりに、完全なSSTを実行するか、できるだけ早く、またはトラフィックが少なくなったときに新しいインスタンスを導入してください。ノードが一貫性のない動作を引き起こし、データが破損している可能性があります。
大規模なトランザクションを分離し、ストリーミングレプリケーションを使用するかどうかを決定する
追加するもう1つの点は、大規模なトランザクションを処理しているため、トランザクションが完了するまでにかなりの時間がかかる可能性があるため、変数innodb_lock_wait_timeoutをhighに設定することを考慮する必要があります。見積もり時間に応じてセッションを介してこれを設定しますが、終了する予定の時間よりも長く設定します。それ以外の場合は、タイムアウトを発生させます。
GRANTsステートメントの複製
GRANTを使用している場合、関連する操作はデータベース`mysql`のMyISAM/Ariaテーブルに作用します。 GRANTステートメントは複製されますが、基になるテーブルは複製されません。つまり、テーブルがMyISAMであるため、INSERT INTOmysql.user...は複製されません。
ただし、Percona XtraDB Cluster（PXC）8.0（現在は実験的）であるため、mysqlスキーマテーブルがInnoDBに変換されているため、上記は当てはまらない可能性がありますが、MariaDB10.4では一部のテーブルがまだ残っていますAria形式ですが、その他はCSVまたはInnoDBです。使用しているGaleraのバージョンとプロバイダーを決定する必要がありますが、mysqlスキーマを参照するDMLステートメントの使用は避けるのが最善です。そうしないと、これがPXC 8.0であることが確実でない限り、予期しない結果が生じる可能性があります。
XAトランザクション、テーブルのロック/ロック解除、GET_LOCK/RELEASE_LOCKはサポートされていません
XAトランザクションはロールバックの処理とコミットが異なるため、GaleraClusterはXAトランザクションをサポートしていません。 LOCK/UNLOCKまたはGET_LOCK/RELEASE_LOCKステートメントは、Galeraで適用または使用するのは危険です。クラッシュまたはロックが発生する可能性がありますが、これらは強制終了できず、ロックされたままになります。たとえば、
---TRANSACTION 728448, ACTIVE (PREPARED) 13356 sec
mysql tables in use 2, locked 2
3 lock struct(s), heap size 1136, 5 row lock(s), undo log entries 5
MySQL thread id 67, OS thread handle 140504353195776, query id 1798932 localhost root wsrep: write set replicated and certified (13)
insert into sbtest1(k,c,pad) select k,c,pad from sbtest1_success limit 5このトランザクションはすでにロック解除されており、強制終了されていますが、役に立ちません。 Galera Clusterに移行するときは、アプリケーションクライアントを再設計し、これらの機能を削除する必要があることをお勧めします。
Galera Clusterは、WAN間トポロジまたはgeo間トポロジでも問題なく動作します（Galeraを使用したgeo間トポロジの実装については、このブログを確認してください）。ただし、各ノード間のネットワーク接続が安定していないか、予期しない時間の間断続的にダウンしている場合は、クラスターに問題が発生する可能性があります。これらの各ノードが接続されているプライベートネットワークとローカルネットワークでクラスターを実行することをお勧めします。ノードを災害復旧として設計する場合、それらが異なる地域または地域にある場合は、クラスターの作成を計画してください。以前のブログ「MySQLGaleraクラスターレプリケーションを使用した地理分散クラスターの作成：パート1」を読み始めることができます。これは、Galeraクラスターのトポロジーを決定するのに最も役立つ可能性があるためです。
ネットワークハードウェアへの投資について追加するもう1つの点は、IST中のインスタンスの再構築中にネットワーク転送速度が遅くなるか、SSTで悪化する場合、特にデータセットが大量の場合は問題になります。 。ネットワーク転送には長時間かかる可能性があり、特に3ノードクラスターがあり、2ノードがドナーとジョイナーである場合に2ノードが使用できない場合は、クラスターの安定性に影響を与える可能性があります。 SSTフェーズ中は、最終的にプライマリクラスターと同期できるようになるまで、DONOR/JOINERノードを使用できないことに注意してください。
以前のバージョンのGaleraでは、ドナーノードの選択に関して、状態スナップショット転送（SST）ドナーがランダムに選択されていました。 Glera 4では、インクリメンタルステート転送（IST）を提供できるドナーを優先したり、同じセグメント内のドナーを選択したりできるため、クラスター内で適切なドナーを選択できるようになりました。または、wsrep_sst_donor変数を、常に選択する適切なドナーに設定することもできます。
データをバックアップし、移行中および本番前に厳密なテストを実行します
スーツを着て、データをGalera Cluster 4.0に移行することを決定したら、常にバックアップを準備しておくようにしてください。 ClusterControlを試した場合は、バックアップを取る方が簡単です。
正しいバージョンのInnoDBに移行していることを確認し、テストを実行する前に常にmysql_upgradeを適用して実行することを忘れないでください。すべてのテストが、MySQLレプリケーションが提供できる望ましい結果に合格することを確認してください。ほとんどの場合、推奨事項とヒントが事前に適用および準備されている限り、MySQLレプリケーションクラスターとMySQLガレラクラスターで使用しているInnoDBストレージエンジンに違いはありません。
Galera Cluster 4.0への移行は、望ましいデータベーステクノロジーソリューションではない場合があります。ただし、Galera Cluster 4.0の特定の要件を準備、セットアップ、および提供できる限り、GaleraCluster4.0を利用することはできません。 Galera Cluster 4.0は、特に高可用性プラットフォームとソリューションにおいて、非常に強力で実行可能な選択肢とオプションになりました。また、GaleraCaveatsまたはGaleraClusterの制限に関するこれらの外部ブログ、またはMariaDBのこのマニュアルを読むことをお勧めします。