sql >> データベース >  >> RDS >> MariaDB

MySQL Galeraクラスターストリーミングレプリケーションのガイド:パート1

    ストリーミングレプリケーションは、GaleraClusterの4.0リリースで導入された新機能です。 Galeraはクラスター全体で同期的にレプリケーションを使用しますが、このリリース以前は、2GBを超える書き込みセットはサポートされていませんでした。ストリーミングレプリケーションにより、大規模な書き込みセットをレプリケートできるようになりました。これは、一括挿入やデータベースへのデータの読み込みに最適です。

    以前のブログで、ストリーミングレプリケーションとMariaDB 10.4を使用した大規模なトランザクションの処理について書きましたが、このブログを書いている時点では、Codershipは新しいGaleraClusterのバージョンをまだリリースしていません。ただし、Perconaは、次の機能を強調したPercona XtraDBCluster8.0の実験的なバイナリバージョンをリリースしました...

    • 大規模なトランザクションをサポートするストリーミングレプリケーション

    • 同期機能により、アクションの調整が可能になります(wsrep_last_seen_gtid、wsrep_last_written_gtid、wsrep_sync_wait_upto_gtid)

    • よりきめ細かく改善されたエラーログ。 wsrep_debugは、ロギングの制御を支援する複数値の変数になり、ロギングメッセージが大幅に改善されました。

    • 複製ノードでの一部のDMLおよびDDLエラーは、無視または抑制できます。 wsrep_ignore_apply_errors変数を使用して構成します。

    • 複数のシステムテーブルは、クラスターの状態の詳細を調べるのに役立ちます。

    • Galera 4のwsrepインフラストラクチャは、Galera 3のインフラストラクチャよりも堅牢です。コードの実行が高速で、状態処理、予測可能性、エラー処理が向上しています。

    GaleraCluster4.0の新機能

    新しいストリーミングレプリケーション機能

    ストリーミングレプリケーションでは、トランザクションはトランザクション処理中に小さなフラグメントに徐々に複製されます(つまり、実際のコミットの前に、いくつかの小さなサイズのフラグメントを複製します)。次に、複製されたフラグメントがスレーブスレッドに適用され、すべてのクラスターノードでトランザクションの状態が保持されます。フラグメントはすべてのノードでロックを保持し、後で競合することはできません。

    GaleraSystemTables

    データベース管理者およびMySQLデータベースにアクセスできるクライアントはこれらのテーブルを読み取ることができますが、データベース自体が必要な変更を行うため、これらのテーブルを変更することはできません。サーバーにこれらのテーブルがない場合は、サーバーが古いバージョンのGaleraClusterを使用している可能性があります。

    #> show tables from mysql like 'wsrep%';
    
    +--------------------------+
    
    | Tables_in_mysql (wsrep%) |
    
    +--------------------------+
    
    | wsrep_cluster            |
    
    | wsrep_cluster_members    |
    
    | wsrep_streaming_log      |
    
    +--------------------------+
    
    3 rows in set (0.12 sec)
    新しい同期機能

    このバージョンでは、wsrep同期操作で使用する一連のSQL関数が導入されています。それらを使用して、最後の書き込みまたは最後に確認されたトランザクションのいずれかに基づくグローバルトランザクションIDを取得できます。次のトランザクションを開始する前に、特定のGTIDが複製および適用されるのを待つようにノードを設定することもできます。

    インテリジェントドナーの選択

    Galera 3.x以降に存在していた控えめな機能には、インテリジェントなドナー選択とクラスタークラッシュリカバリが含まれます。これらは元々Galera4で計画されていましたが、主に顧客の要件により、以前のリリースになりました。 Galera 3でのドナーノードの選択に関しては、状態スナップショット転送(SST)ドナーがランダムに選択されました。ただし、Galera 4を使用すると、インクリメンタルステート転送(IST)を提供できるドナーを優先したり、同じセグメント内のドナーを選択したりできるため、ドナーの選択に関してはるかにインテリジェントな選択が可能になります。データベース管理者は、wsrep_sst_donorを設定することでこれを強制できます。

    MySQLGaleraクラスターストリーミングレプリケーションを使用する理由 長時間実行されるトランザクション

    Galeraの問題と制限は、常に実行時間の長いトランザクションの処理方法に関連しており、大規模な書き込みセットが複製されるためにクラスター全体の速度が低下することがよくありました。多くの場合、フロー制御が高くなり、書き込みが遅くなるか、クラスターを通常の状態に戻すためにプロセスが終了することさえあります。これは、以前のバージョンのGaleraClusterでよくある問題です。

    Codershipは、これらの状況を緩和するために、長時間実行されるトランザクションにストリーミングレプリケーションを使用することをお勧めします。ノードがフラグメントを複製して認証すると、他のトランザクションがフラグメントを中止することはできなくなります。

    大規模なトランザクション

    これは、レポートまたは分析にデータをロードするときに非常に役立ちます。一括挿入、削除、更新の作成、またはLOAD DATAステートメントを使用した大量のデータのロードは、このカテゴリーに分類される可能性があります。ただし、取得または保存するデータをどのように管理するかによって異なります。ストリーミングレプリケーションには、証明書ロックがレコードロックから生成されるなどの制限があることを考慮に入れる必要があります。

    ストリーミングレプリケーションがないと、多数のレコードを更新すると競合が発生し、トランザクション全体をロールバックする必要があります。大規模なトランザクションも複製しているスレーブは、しきい値に達するとフロー制御の対象となり、同期複製からの着信トランザクションの受信を緩和する傾向があるため、書き込みを処理するためにクラスター全体の速度が低下し始めます。 Galeraは、書き込みセットが管理可能になるまでレプリケーションを緩和します。これにより、レプリケーションを再度続行できるようになります。ガレラ内のフロー制御についてさらに理解するために、Perconaによるこの外部ブログを確認してください。

    ストリーミングレプリケーションを使用すると、ノードはコミットを待つのではなく、トランザクションフラグメントごとにデータのレプリケーションを開始します。これは、クラスターがこの特定のフラグメントの書き込みセットを認証したことを単に確認するため、他のノード内で実行されている競合するトランザクションを中止する方法がないことを意味します。クラスターへの影響を最小限に抑えながら、大規模なトランザクションをブロックおよび処理することなく、他の同時トランザクションを自由に適用およびコミットできます。

    ホットレコード/ホットスポット

    ホットレコードまたは行は、常に更新されるテーブル内の行です。これらのデータは最も訪問されている可能性があり、データベース全体のトラフィックを非常に多く取得します(ニュースフィード、訪問数やログなどのカウンターなど)。ストリーミングレプリケーションを使用すると、クラスター全体に重要な更新を強制できます。

    コーダーシップのガレラチームが指摘したように

    「この方法でトランザクションを実行すると、すべてのノードのホットレコードが効果的にロックされ、他のトランザクションが行を変更するのを防ぐことができます。また、トランザクションが正常にコミットされ、クライアントが目的の結果を受け取る可能性も高まります。」

    コミットが成功することは永続的で一貫性がない可能性があるため、これには制限があります。ストリーミングレプリケーションを使用しないと、高い可能性またはロールバックが発生し、アプリケーションの観点からこの問題が発生した場合にエンドユーザーにオーバーヘッドが追加される可能性があります。

    ストリーミングレプリケーションを使用する際の考慮事項
    • 認証キーはレコードロックから生成されるため、ギャップロックや次のキーロックは対象外です。トランザクションがギャップロックを取得した場合、別のノードで実行されるトランザクションが、ギャップログに遭遇した書き込みセットを適用し、ストリーミングトランザクションを中止する可能性があります。
    • ストリーミングレプリケーションを有効にすると、書き込みセットログがmysqlシステムデータベースにあるwsrep_streaming_logテーブルに書き込まれ、クラッシュが発生した場合の永続性が維持されるため、このテーブルはリカバリ時に機能します。過剰なロギングと高いレプリケーションオーバーヘッドの場合、ストリーミングレプリケーションはトランザクションスループットレートの低下を引き起こします。これは、高いピーク負荷に達した場合のパフォーマンスのボトルネックになる可能性があります。そのため、ストリーミングレプリケーションはセッションレベルでのみ有効にし、それがないと正しく実行されないトランザクションに対してのみ有効にすることをお勧めします。
    • 最適な使用例は、ストリーミングレプリケーションを使用して大規模なトランザクションを削減することです
    • フラグメントサイズを最大10,000行に設定します
    • フラグメント変数はセッション変数であり、動的に設定できます
    • インテリジェントアプリケーションは、必要に応じてストリーミングレプリケーションのオン/オフを設定できます
    結論

    お読みいただきありがとうございます。パート2では、Galera Cluster Streaming Replicationを有効にする方法と、セットアップでどのような結果になるかについて説明します。


    1. MSAccessのデータベースの破損と対処方法

    2. スレッドメインjava.sql.SQLExceptionの例外:ユーザー'' @'localhost'のアクセスが拒否されました(パスワードを使用:NO)

    3. Oracle:'=ANY()' vs.'IN()'

    4. PL / pgSQL関数:executeステートメントを使用して複数の列を持つ通常のテーブルを返す方法