技術めも

以前の記事で、

master、slave構成において、

• 非同期レプリケーション
• 準同期レプリケーション

があることが抜けていた。

今回のように、maxscaleでsalve auto promotionを使う場合、

データロスト率が低い準同期方式がよいと思われる。

準同期レプリケーションについては、詳細説明をされているホームページがあるので、

それを参照されたい。

準同期レプリケーションの設定は以下。

[mysqld]
plugin-load=rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout=1000
rpl_semi_sync_slave_enabled=1

これで、プラグインのロードと、

準同期レプリケーションの設定が入る。

なお、ここでは、masterがslaveに、slaveがmasterになることがあるので、

master・slave問わず同じ設定を入れている。

ここで準同期レプリケーションの課題を考えてみると、以下のようなものがありそうだ。

1. ネットワーク帯域が狭いとクラスターのパフォーマンスに影響を及ぼす
2. slave台数が増えるとクラスターのパフォーマンスに影響を及ぼす
3. バイナリログサイズがでかいとクラスターのパフォーマンスに影響を及ぼす

非同期と混在させることが出来なかったような気がするので、

遠隔地にバックアップをおくこともできないと思われる。

これらについて、検証したら詳細を記述したい。

前回、

Slave auto promotionについて記載するといったが、

詳細はさておき、先に結論を書いておく。

【前提】

• maxscaleによるWriterReaderSplit機能を使う
• masterダウン時には、生きているslaveが自動昇格する

【結論】

• ノード数は3以上が推奨と書かれているが、ノード数が1になると、maxscaleのWriterReaderSplitが機能しなくなる
• slaveの同期が失敗していている状態では、masterに昇格しないし、maxscaleのクラスターからも外れる

ということが挙げられる。

つまり、3ノードあっても、2ノード死んだら、実質アウトなのである。

そのため、打っておく手段としては、

• masterがダウン→手動復旧→自動で新masterのslaveとなるようにする
• 1ノードになった場合、maxscale経由でアクセスしないようにする

ということをやっておけば完璧だと思われる。

ちなみに、良い点として、masterがダウン→復旧しても、新masterとバイナリログポジションがずれているため、

maxsacle上のクラスターからは外され、マルチマスター状態にはならない。（単独のマスターとして存在する）

幸い、maxscaleは結構イベントが拾えるので、

上記対策もなんとか実現できそうな気がしている。

そのあたりの検証記事を、今後書こうと思います。

以上

MariaDBでクラスターを組む際、

• maxscale
• mariadb-replication-manager
• MariaDB

を使うとよい。

そもそも、MariaDBのクラスターには、

• Spider（マルチマスター、データ分散型）
• Galera（マルチマスター、データ同期型）
• Slave auto promotion（マスタースレーブ、データ同期型）

のような3つの手段があるが（もっとあるかも。。調べてません。）、

GaleraとSlave auto promotionであれば、maxslace & repliacation-managerの監視および発砲でいける。

すいません、Spliderは記載しておきながら、大してわからないので、

GaleraとSlave auto promotionの特徴を書いてみる。

【Galera】

（メリット）

• 全てmasterであるため、障害時のダウンタイムがほぼ0
• 各ノードのデータ状況に差異が出にくい

（デメリット）

• データの同期化のため、ノード数が増えると更新時間がかかる
• テーブルor行ロックは同一ノードのみ有効

【Slave auto promotion】

（メリット）

• データ更新時間はシングル構成と変わらない（うそ、シングルより遅いし、レプリケーションタイプにも影響をうける）

（デメリット）

• Slaveの昇格が完了するまではダウンタイムとなる
• Slave遅延が発生するとデータのロストが発生する

上記のような特徴があるので、

使いどころはサービスに依存するのかもしれない。

私の見解では、

・同一データを更新することがない場合　→　Galera

・同一データを更新することが多い場合　→　Slave auto promotion

がよいと思う。

決め手は、更新速度とロックの有無かと。

※Spiderは分散データなので、Slave auto promotionと組み合わせないとデータロストしちゃうかも。。

Galeraは結構やっている人がいるから、

Slave auto promotionについて、

maxscaleとreplication-managerを用いた構成の説明（やってみた）を近々で書こうと思う。

以上

AWSのRDSにmariadbが追加されましたね。

xtradbのサポートはあるようだけど、

mariadbのクラスター関連のエンジンはサポートしていない感じがする。

AWSの場合、Auroraがあるから、mariadb流行らないかも。。

クラスター関連をサポートしてくれないかな。。

プレビュー版のようですが、

MySQLと互換性をもつRDSが発表されましたね。

詳しくは、こちら。

ちょっと気になるのは、

AmazonのEC2で選択できるAmazonLinuxって、centos6系をベースにカスタマイズされたものだったような。

centosは7から、標準レポジトリにMySQLが外れて、mariadbになってたから、

当面はAmazonLinuxはcentos7には上げないのかね？

EC2とRDSで違うから、問題ないのかもしれないけど、

mariadbもaws（特にRDS）で使えるようになると、今後もっと流行りそうな気がします。