transaction_replay – MariaDB MaxScale 2.3 read/write split 新機能

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

はじめに

MaxScale 2.2 で導入された,自動failover(auto_failover)ではMHAなどの3rd partyツールを必要とせず,Masterでの障害発生時にSlaveをMasterに自動昇格させることができますが,failoverの際にクライアント/アプリケーションとの接続が途切れ,再接続の必要があるのが難点でした。
2018年12月にGAとなった MariaDB MaxScale 2.3 の readwritesplit(read/write split)モジュールではクライアントからデータベースへの接続が途切れない新機能(transaction_replay/master_reconnection)が追加されています。

Announcing MariaDB MaxScale 2.3 GA

今回はこの新機能について解説したいと思います。

master_reconnection

master_reconnection=true(有効)に設定すると,セッション途中で接続先のMasterノードが自動failoverしても接続が維持(再接続)されるようにします。なお,以下の条件があり,これらを満たすと再接続されます。なお,デフォルトでは無効(false)です。

  • すでにSlaveに接続されており,そのSlaveノードがMasterに昇格される
  • トランザクションがない
  • Autocommit が有効
  • LOAD DATA LOCAL INFILE が実行中でない
  • 旧Masterノードにルーティングされているクエリがない

transaction_replay

Masterの障害等で途中で中断されたトランザクションを再実行します(デフォルトではfalse)。なお,transaction_replay=true(有効)とすると,delayed_retrymaster_reconnection が自動的に有効となります。

トランザクション実行中のサーバに障害が発生すると,readwritesplit はトランザクションを Master に昇格したサーバで実行します。クライアント/アプリケーション側で再接続を行う必要はありません。

他の代替ノードが存在せず,delayed_retry_timeout で設定した時間内に代替ノードが見つからない場合,クライアントとの接続は閉じられます。

すべてのトランザクションが再実行されるわけではなく,以下のSQL文がトランザクションに含まれ,初回の部分的なザクションと同一の結果が得られる場合のみ,トランザクションが再実行されます。

  • INSERT
  • UPDATE
  • DELETE
  • SELECT
  • FOR UPDATE

例えば,トランザクション中で,NOW() や @@server_id 等が含まれている場合,同一の結果にはなりませんので,再実行されません。

master_reconnection の検証

簡単なテスト・スクリプトを用い,master_reconnection 有効/無効での挙動の違いを確認してみます。

テスト環境

以下の環境でテストを実施しました。

  • MariaDB MaxScale 2.3.3 x 1
  • MariaDB Server 10.3.12 x 3 (Master x 1 – Slave x 2)
  • CentOS 7.6.1810

テスト・スクリプト

MaxScale read/write split経由でINSERTを定期的に実行する以下のRubyスクリプトを用います。

テスト・テーブル作成

master_reconnection=false (デフォルト)の場合

まずは比較のため,/etc/maxscale.cnf の read/write split serviceセクションを以下のように設定し,master_reconnectionを無効(デフォルト)にしてテストを実行します。

テスト・スクリプト実行結果

(id=4でMasterを停止,自動failover)

id=4完了後にMasterノードを停止させると接続が切れ,そのまま接続が切れていますので,クライアント/アプリケーションでデータベースへの再接続を行う必要があります。

master_reconnection=true の場合

これに対して,/etc/maxscale.cnf の read/write split serviceセクションの設定を以下のように設定し,master_reconnection を有効にしてテストを再実行します。

テスト・スクリプト実行結果

master_reconnection=false の場合と異なり,failover時にRuby mysql2 コネクタからのエラーメッセージは表示されていません。

(id=4でMasterを停止,自動failover)

INSERTされたデータの確認

テスト・スクリプトでは5秒間隔でINSERTを行っていますが,id=4とid=5のレコード間では13秒間隔となっているものの,接続は途切れていません。

このときの MaxScale のログ,/var/log/maxscale/maxscale.log には以下のように記録されています。

server2(Master)がダウンしたことが検知され,server1がMasterに昇格,その後クエリがserver1にルーティングされていることが確認できます。

まとめ

今回は MaxScale 2.3 で新たに導入された,master_reconnection および transaction_replay について解説いたしました。Master-Slave構成にて自動failover時にアプリケーション/クライアント側でデータベースからの切断を検知,再接続を行う必要がなく,アプリケーション側でデータベース・システム構成に依存したコードを書く必要がなくなると考えます。

 

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

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

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