カテゴリー「rdb」

muninでMariaDB10.0.4を監視してたら、

情報がほとんどあつまっていなかった。

 

munin自体はepelからインストールしたのだが、

これに内包されている「mysql_」プラグインはMySQL5.1レベルのものまでしかサポートしていないため、

以下にあるファイルで上書きする必要がある。

 

https://github.com/munin-monitoring/munin/blob/8abb3faf7865af125ecc18b4feece35c59c90fd9/plugins/node.d/mysql_.in

 

このファイルで上書き、

1行目の


#!@@PERL@@


#!/usr/bin/perl

に直したら、MariaDB10.0.4でも問題なく動いた。

 

以上

投稿日時:2016年07月29日 23:20   カテゴリー:mariadb, rdb, server   [コメントがあればどうぞ]

以前の記事で、

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. バイナリログサイズがでかいとクラスターのパフォーマンスに影響を及ぼす

 

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

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

 

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

 

投稿日時:2016年05月27日 23:21   カテゴリー:mariadb, mysql, rdb   [コメントがあればどうぞ]

前回

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は結構イベントが拾えるので、

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

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

 

以上

 

投稿日時:2016年05月17日 00:20   カテゴリー:mariadb, mysql, rdb   [コメントがあればどうぞ]

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

 

以上

 

投稿日時:2016年05月17日 00:02   カテゴリー:mariadb, mysql, rdb   [コメントがあればどうぞ]

RDBで大量のselectをしたら、

DBサーバの負荷は重いのだろうか?

例えば、1億レコードが入っているテーブルに対して、

select * from [table]

したら、DBサーバの負荷は重いのだろうか?

 

個人的に思うところとして、

サーバ側は、クライアント側に一定のバッファで

結果を返すことにのみ注力しているのであれば、

少々ネットワークは忙しくなるかもしれないが、

サーバのシステム負荷(CPU使用率、メモリ使用率)は低いんじゃないか?

って考えてます。

 

誰か教えて欲しいわ。。

ソースコード見るしかないかね。。

 

この仮定が成立するとすれば、

インデックスがない環境で複雑なクエリーを発行するより、

一気に大量レコードを引いて、

アプリケーションプログラムで分散並列で処理しちゃえば、いいんじゃないの?って思う。

Hadoopは詳しくないけど、似たようなものなのかな?

ちょっと勉強してみようかな。。

 

投稿日時:2015年11月26日 13:07   カテゴリー:rdb   [コメントがあればどうぞ]

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構文もサポートしている。

 

以上

投稿日時:2015年08月14日 16:08   カテゴリー:rdb   [コメントがあればどうぞ]