muninでMariaDB10.0.4を監視してたら、
情報がほとんどあつまっていなかった。
munin自体はepelからインストールしたのだが、
これに内包されている「mysql_」プラグインはMySQL5.1レベルのものまでしかサポートしていないため、
以下にあるファイルで上書きする必要がある。
このファイルで上書き、
1行目の
#!@@PERL@@
を
#!/usr/bin/perl
に直したら、MariaDB10.0.4でも問題なく動いた。
以上
カテゴリー「rdb」
以前の記事で、
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問わず同じ設定を入れている。
ここで準同期レプリケーションの課題を考えてみると、以下のようなものがありそうだ。
- ネットワーク帯域が狭いとクラスターのパフォーマンスに影響を及ぼす
- slave台数が増えるとクラスターのパフォーマンスに影響を及ぼす
- バイナリログサイズがでかいとクラスターのパフォーマンスに影響を及ぼす
非同期と混在させることが出来なかったような気がするので、
遠隔地にバックアップをおくこともできないと思われる。
これらについて、検証したら詳細を記述したい。
前回、
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を用いた構成の説明（やってみた）を近々で書こうと思う。
以上
RDBで大量のselectをしたら、
DBサーバの負荷は重いのだろうか？
例えば、１億レコードが入っているテーブルに対して、
select * from [table]
したら、DBサーバの負荷は重いのだろうか？
個人的に思うところとして、
サーバ側は、クライアント側に一定のバッファで
結果を返すことにのみ注力しているのであれば、
少々ネットワークは忙しくなるかもしれないが、
サーバのシステム負荷（CPU使用率、メモリ使用率）は低いんじゃないか？
って考えてます。
誰か教えて欲しいわ。。
ソースコード見るしかないかね。。
この仮定が成立するとすれば、
インデックスがない環境で複雑なクエリーを発行するより、
一気に大量レコードを引いて、
アプリケーションプログラムで分散並列で処理しちゃえば、いいんじゃないの？って思う。
Hadoopは詳しくないけど、似たようなものなのかな？
ちょっと勉強してみようかな。。
ORマッパーを作成して、
INDEXの存在確認方法を調べたのでまとめておきます。
【PostgreSQL】
select indexname from pg_indexes where tablename = ‘テーブル名’;
【MySQL・MariaDB】
SELECT INDEX_NAME FROM information_schema.STATISTICS WHERE table_name = ‘テーブル名’;
→whereに「TABLE_SCHEMA」を追加すれば、データベース名も条件に加えられる。
【SQLite3】
select name From sqlite_master where type = ‘index’;
→インデックス名の一覧がとれるから、そこから検索すればよい。
【H2】
select index_name from information_schema.indexes where table_name = ‘テーブル名;
→大文字小文字を区別している場合、テーブル名は大文字にする必要がある。
→大文字小文字を区別している場合、結果セットは大文字になるので、注意する。
→CREATE INDEX IF NOT EXISTS index_name ON table_name (column_name1, column_name2);
という形で、IF NOT EXISTS構文もサポートしている。
以上