MariaDB MaxScale 2.3 新機能 : causal_reads

本記事は MariaDB Corporation より寄稿された記事となります
目次

はじめに

MariaDB のデータベース Proxy, MaxScale では バージョン 2.3 で read/write split ルータ・モジュールに causal_reads と呼ばれる新機能が追加されました。今回はこの新機能に関して説明させて頂きます。

causal_reads

causal_reads は read/write split ルータにおいて,クライアント/アプリケーションがデータベース上のデータ変更を行った際に,直後に Replica ノードで実行される read (SELECT等)に対するレプリケーション遅延の影響がないような処理を行います。
なお,causal_reads はデフォルトで無効になっています。

制限事項

casula_reads を用いる場合,MariaDB Server 10.2.16 以降のバージョンを利用する必要があり,また,session_track_system_variables パラメータに last_gtid を設定する必要があります。

利用例

autocommit を1 (有効)に設定している場合,以下の例において,

各SQL文はトランザクション内では実行されないため,MaxScaleから見ると,後者のSELECT文は Replica ノードにルーティングされます。これにより起こりうる問題としては,Primary に INSERT されてから,SELECT文が実行される Replica ノードにまだレプリケーションされていない場合,クエリ結果が異なってしまう可能性があります。

このような場合に,MaxScale は一貫したクエリ結果を返すことを保証するコマンドをプリフィックスとして付与することにより,一貫性を犠牲にすることなく read スケーラビリティを向上させることができます。

上記の例のSQL文は以下のように変換されます。

ここで,SET コマンドは Replica をあるGTIDに同期させるようにします(詳細は MASTER_GTID_WAIT を参照)。

もし,Replica が Primary に対して causal_reads_timeout 時間内に同期できない場合,MaxScale は Primary に対して再度クエリを実行します。

causal_reads_timeout

causal_reads におけるタイムアウト時間(単位: 秒)のパラメータで, デフォルト値は 10 秒です。

まとめ

今回は MaxScale 2.3 において導入された新機能,causal_reads について解説させて頂きました。従来であれば,アプリケーション側での対処が必要な場面においても,MaxScale を介することにより,あたかもシングルノード構成のデータベースであるかのように扱えるかと存じます。

 

スマートスタイルTECHブログについて

スマートスタイルTECHブログでは、日頃オープンソースデータベースのサポート業務に従事している有資格者で構成された技術サポートチームがMariaDBに関する技術情報を発信しています。データベースのお困りごとはお気軽にご相談下さい。

よかったらシェアしてね!
  • URLをコピーしました!
目次