技術めも

前回、

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を用いた構成の説明（やってみた）を近々で書こうと思う。

以上

MySQLでは、

・truncate

・load in file

・create

などの一部はトランザクションが効かないのね。。

また、load in fileは、

replaceキーワードを使えば、主キーが存在していれば、

updateを行ってくれるのね。。

基本的なことだろうけど、知らなかったわ。。

load in fileの例（RDSにて）

LOAD DATA LOCAL INFILE '${file_path}' REPLACE INTO TABLE ${table_name} FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n'

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

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

詳しくは、こちら。

ちょっと気になるのは、

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

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

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

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

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