はじめに
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 (有効)に設定している場合,以下の例において,
1 2 |
INSERT INTO test.t1 (id) VALUES (1); SELECT * FROM test.t1 WHERE id = 1; |
各SQL文はトランザクション内では実行されないため,MaxScaleから見ると,後者のSELECT文は Replica ノードにルーティングされます。これにより起こりうる問題としては,Primary に INSERT されてから,SELECT文が実行される Replica ノードにまだレプリケーションされていない場合,クエリ結果が異なってしまう可能性があります。
このような場合に,MaxScale は一貫したクエリ結果を返すことを保証するコマンドをプリフィックスとして付与することにより,一貫性を犠牲にすることなく read スケーラビリティを向上させることができます。
上記の例のSQL文は以下のように変換されます。
1 2 3 4 5 6 7 |
INSERT INTO test.t1 (id) VALUES (1); SET @maxscale_secret_variable=( SELECT CASE WHEN MASTER_GTID_WAIT('0-3000-8', 10) = 0 THEN 1 ELSE (SELECT 1 FROM INFORMATION_SCHEMA.ENGINES) END); SELECT * FROM test.t1 WHERE id = 1; |
ここで,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 を介することにより,あたかもシングルノード構成のデータベースであるかのように扱えるかと存じます。