カテゴリー「mariadb」

maxscaleにはbinlogrouterなる機能がある。

なお、maxscaleのバージョンは2.2、mariadbのバージョンは10.3で確認しています。

これは以下のようなイメージで、バイナリログを蓄積し、他slaveへ伝播させる中継機能を持つ。

----------
mariadb master
IP:192.168.35.11
----------
|
| (replication)
|
----------
maxscale binlogrouter
IP:192.168.35.12
----------
|
| (replication)
|
----------
mariadb slave
IP:192.168.35.13
----------

 

これはmysqlbinlogのremote機能にも似ているが、

通常のレプリケーションと同じように扱える利点があり、

さらにCDC(Change Data Capture)という機能を利用することで、

Kafkaなんかと連携することも可能らしい。

 

面白いアプローチだなと思いつつ、使いどころが難しい。。。

とりあえず、構築手順だけ残しておく。

 

・master(192.168.35.11)

$ sudo mysql_secure_installation
$ sudo mysql -u root -p
[MariaDB]> CREATE USER 'admin' IDENTIFIED BY 'admin1234';
[MariaDB]> GRANT ALL PRIVILEGES ON *.* TO 'admin';

 

・binlogrouter(192.168.35.12)

$ sudo mkdir /var/lib/maxscale/binlog
$ chown maxscale:maxscale /var/lib/maxscale/binlog

 

/etc/maxscale.cnf

[Replication]
type=service
router=binlogrouter
user=admin
passwd=admin1234
server_id=99
binlogdir=/var/lib/maxscale/binlog
mariadb10-compatibility=1
mariadb10_master_gtid=1

[Replication Listener]
type=listener
service=Replication
protocol=MariaDBClient
port=13306
$ mysql -h 127.0.0.1 -P 13306 -u admin -padmin1234
[MariaDB]> CHANGE MASTER TO MASTER_HOST='192.168.35.11', MASTER_PORT=3306, MASTER_USER='admin', MASTER_PASSWORD='admin1234', master_use_gtid=slave_pos;
[MariaDB]> start slave;

※slave_posは最初は空なので、場合によっては、「SET GLOBAL gtid_slave_pos=’XXX’;」が必要。

 

ここまでで、masterとbinlogrouterのレプリケーション関係が構築された。

binlogrouterはバイナリログしか持っていないので、slave_posは「欲しい状態」を指定すればよい。

 

・slave(192.168.35.13)

$ mysqldump -h 192.168.35.11 -u admin -padmin1234 --master-data=2 --single-transaction --routines --all-databases > master.sql
$ mysql -u admin -padmin2612 < master.sql
$ mysql -u admin -padmin2612
[MariaDB]> SET GLOBAL gtid_slave_pos='{master.sqlファイルに書いてあるGTIDポジション}';
[MariaDB]> CHANGE MASTER TO MASTER_HOST='192.168.35.12', MASTER_PORT=13306, MASTER_USER='admin', MASTER_PASSWORD='admin1234', master_use_gtid=slave_pos;
[MariaDB]> start slave;

 

という手順にて、binlogrouterを介したレプリケーションができる。

あとは、有効な使い所を探すべし。。

 

以上

投稿日時:2018年07月25日 12:36   カテゴリー:mariadb   [コメントがあればどうぞ]

MariaDBでMultisource Replicationをやるときは、

  • GTIDベース
  • 通常ベース(ファイル/ポジション)

によって、制約が異なる。

 

GTIDベースでは、

レプリケーション元のgtid_domain_idが異なっていなければならない。

通常ベースでは、

レプリケーション元のgtid_domain_idが同じでも良い。

 

つまり、GTIDベースでは、以下のようなケースにおいては、

db01とdb02のgtid_domain_idは異る必要がある。

+++++          +++++
db01           db02
+++++          +++++
|              |
|              |
++++++++++++++++++++
multisource
++++++++++++++++++++

 

しかし、通常ベースでは、gtid_domain_idが同じでもよい。

これは、gtid_domain_idを指定できないAWSのRDS環境のおいても、

Multisource Replicationが使えることを意味している。

つまり、db01とdb02がRDSで、multisourceがEC2という位置付けになる。

※RDS上にmultisourceは組めません。

 

さらに、MariaDBの嬉しい機能として、

コネクションごとに、replicate_do_dbやらreplicate_igonore_dbが指定できる。

たとえば、db01へのコネクション名を「con-db01」、db02へのコネクション名を「con-db02」とすると、

以下のような設定をmultisource側のmy.cnfに記載できる。

con-db01.replicate_do_db=hoge01
con-db02.replicate_do_db=hoge02

この設定の意味するところは、「con-db01」ではhoge01データベースをレプリケーションの対象とする、

「con-db02」ではhoge02データベースをレプリケーションの対象とする、ということである。

 

このような機能を使うことで、

分割されたDBからデータをかき集め、

様々な集計/分析を行うことが容易となる。

さらに、MariaDB10.2からはwindow関数も導入されているため、

Multisource Replicationによる恩恵もおおきくなるだろう。

※MariaDB10.2と10.3では使えるwindow関数が異なるので注意。

 

なお、GTIDを使う場合、以下のように、2つのGTIDを指定する。

gtid_domain_idが10はdb01、20はdb02を指している。

> stop all slaves;
> SET GLOBAL gtid_slave_pos='10-11-10,20-21-10';
> CHANGE MASTER 'con-db01' TO  MASTER_HOST='XXX', MASTER_USER='rpl', MASTER_PASSWORD='rplpassword', master_use_gtid=slave_pos;
> CHANGE MASTER 'con-db02' TO  MASTER_HOST='YYY', MASTER_USER='rpl', MASTER_PASSWORD='rplpassword', master_use_gtid=slave_pos;
> start all slaves;

 

以上

投稿日時:2018年06月14日 23:51   カテゴリー:mariadb   [コメントがあればどうぞ]

表題のとおり、MariaDB10.3とOracleをconnectエンジンで繋いでみた。

つなぎ方は、odbcかjdbcを使うことで実現できる。

Oracleのクライアント設定とかも必要なので、

ここでは詳細な設定について割愛。

 

なお、Oracleとの互換性を最大限たかめるため、

SQL_MODE=ORACLE

という、MariaDB10.3で導入されたモードを設定している。

 

おおよそのデータについては、問題なくconnectエンジン経由で扱えるのだが、

最大の難関は日付けである。

Oracleはtimestamp型を拡張しているため、

MariaDB(MySQL)のtimestamp型とカバー範囲が異なる。

そのため、以下の条件のいずれかの場合において、

connectで持ってきた時に「0000-00-00 00:00:00」という日時になってしまう。

  • Oracleのtimestamp型データがMySQLのtimestamp型の範囲外のとき
  • Oracleのtimestamp型データがNULLのとき

前者はその通りの話ではあるが、後者のパターンも有り得るのがやっかいである。

しかも、条件句で指定した時は、NULLと認識するくせに、結果セットが変るのである。

これはconnectで自動作成させるテーブル定義上仕方ないことなのであるが。。

 

その他、BLOB、CLOBなどのバイナリ型が、

connect上はvarcharになるので、このあたりも場合によっては、注意が必要。

 

以上

投稿日時:2018年06月14日 23:16   カテゴリー:mariadb   [コメントがあればどうぞ]

10.3のパラメータ(innodb関連中心)を確認してみたところ、

10.2でなされたような大きな変更は少なく、

10.2でdepricatedになったものが、removedになったりしている感じであった。

 

10.3の目玉としては、

やはりPL/SQLへの対応なのであろうが、

個人的には、以下が嬉しい。

  • sequenceの導入 → nextvalができる
  • Instant ADD COLUMN → alter tableの時間抑制に繋がりそう

 

その他、spider enginにおいて、条件句のpush downも入ったようだ。

 

以上を踏まえると、10.3への移行する場合、

既に10.2を使っているのであれば、比較的低リスクで移行できる?

と感じています。

 

10.4の計画も見てみると、

innodb以外のストレージエンジンの機能拡張が候補になっていたりと、

MySQLとの乖離がどんどん大きくなるような気がするが。。

 

以上

投稿日時:2018年05月29日 00:10   カテゴリー:mariadb   [コメントがあればどうぞ]

先月のMySQL8のGAにつづき、

MariaDB10.3がGAされました。

https://mariadb.com/kb/en/library/changes-improvements-in-mariadb-103/

 

MySQL5.7もそんなにいじってないうちに8が出たので、

これから8を検証しようとしているうちに、10.3が出たのですが、

10.3では気になっていたJSONの改善はなさそうです。

 

そもそもMySQLでは5.7で導入されたJSONがNativeJSONのため、

登録時のvalidationが効くという特性がありました。

MariaDB10.2で導入されたJSONはText型のaliasのようで、

validationは効かないような感じです。(未検証です。すいません。)

ただ、MariaDBのドキュメント読む限り、Textのパースは高速と記載されています。

 

MySQL8ではJSONの部分更新機能が導入されました。

これにより、巨大なJSONの一部を更新しても、更新負荷を下げることが可能となり、

もちろん、バイナリログにもそのように記載されるとのことです。

このようなJSONの部分更新がMariaDB10.3でも入るかと期待してましたが、

そのような記載が見あたらず。。

そもそもdynamic columnsに部分更新があるのかどうかにさえ、今気付いた。。

 

というわけで、

  • MySQL8
  • MariaDB10.3

の2つのGAについて、まずはJSONまわりから挙動確認していこうと考えてます。

 

以上

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

10.1から10.2で変更になるパラメータを見てみた。

個人的に気になるものは以下の通り。

・max_allowed_packet
4MB -> 16MB

・sql_mode
NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION -> STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

・innodb_additional_mem_pool_size
removed

・innodb_autoinc_lock_mode
1 -> 2

・innodb_buffer_pool_dump_at_shutdown
off -> on

・innodb_buffer_pool_dump_pct
100 -> 25

・innodb_buffer_pool_load_at_startup
off -> on

・innodb_buffer_pool_size
Dynamic

・innodb_checksum_algorithm
innodb -> crc32

・innodb_compression_algorithm
none -> zlib

・innodb_file_format
Deprecated

・innodb_file_format_max
Deprecated

・innodb_flush_sync
new

・innodb_large_prefix
Deprecated

 

俯瞰してみると、これまで10.1では必ず設定していたパラメータが、

defaultで採用されているケースが多い。

そして、767byteを超えるインデックスについて扱っていた

large_prefixに関係するパラメータがdeprecatedになり、

defaultで3072byteまでインデックスサイズが拡張されるということか。。

 

もうちょい深読みしてみないと、上記の変更が生む弊害が読めないが、

往々にして、より扱いやすい方向に進んでいる気がする。

なお、上記のパラメータの多くはMySQL5.7でも採用されている。

 

以上

投稿日時:2017年08月30日 22:33   カテゴリー:mariadb, mysql   [コメントがあればどうぞ]

mysqlではインデックスは1つしか使えないと言われていたが、

実際はインデックスマージという機能があるため、

2つ同時に使うことは可能である。

 

ただ、インデックスマージはwhere句でのみ作用可能に思われるので、

whereとorder byで違うインデックスを使うのは無理なのではないかと思っている。

MySQL5.7でもMariaDB10.2でも、このあたりの記述が見当たらなかった。。

 

上記の理解であっているのか、非常に気になるところである。

進展があったら、書こうと思う。

 

以上

投稿日時:2017年07月23日 00:03   カテゴリー:mariadb, mysql   [コメントがあればどうぞ]

GaleraClusterでは、書き込みノードを1つに絞って、

デッドロックを回避したほうがいいとよく言われる。

maxscaleを使えば、書き込みノードを絞ることは簡単であるが、

単に3つのクエリーを実行するだけで、書き込みノードを絞れるので、記載しておく。

なお、Perconaも似たような方法をやっていた。

 


1.SHOW GLOBAL STATUS LIKE 'wsrep_local_state'; の結果が4である

2.SHOW VARIABLES LIKE 'read_only'; の結果がoffである

3.SHOW GLOBAL STATUS LIKE 'wsrep_local_index'; の結果が0である

 

以上、3つを満たした場合、書き込みノードとして判定してOK。

haproxyと組み合わせることも簡単なので、

どこかでhaproxyとの組み合わせについても記載しようと思う。

 

以上

投稿日時:2017年07月22日 23:33   カテゴリー:mariadb, mysql   [コメントがあればどうぞ]

以前の記事で、galeraの書き込み能力を向上させるために、

spiderと併用したらいいのではないかと記載した。

しかし、この二つの組み合わせるには、

xa transactions(二相コミット)をあきらめる必要がある。

 

そもそも、galera自体、xaには非対応であり、

また、xa transactionsはバイナリログに対して、クラッシュセーフではないようだ。

(MySQLのドキュメントには記述があったが、MariaDBには記載を見つけられなかった。。)

 

上記前提を踏まえたうえで、

galeraとspiderの共演を実現するためには、xaをあきらめることは必須だが、

そもそもの話として、実装上複数ノードのwriteを極小化しておく必要が十分にあると考えられる。

 

これまで、プログラム側では、begin,begin,commit,commitみたいな実装を平気でしていたが、

そもそもこれ自体が出来るだけ避ける必要のある実装であることを、

今回のgaleraとspiderの共演を実現するために調査していた過程で気づいた。。。

今更の話だが、commitは失敗しないだろうという気持ちがどこかにあり、commitの失敗をリカバリーすることが頭の中から抜けていたように思えて反省している。

 

とはいえ、とはいえ、spiderを挟むことで、

プログラムのシャーディング負担を軽減し、

さらにgaleraで高可用性を確保する組み合わせは、とても魅力的ではある。

 

どこかで、galeraとspiderを共演するために、必要な設定・注意事項等をまとめようと思う。

検証した結果の結論から先に書くと、spiderは受信したSQLを変化させて、バックに投げるため、

場合によっては、SQLの発行回数の増加や、参照取得行数の増加が発生する。

この変化パターンを正確につかんでおかないと、気づかないうちに高負荷をバックに与えてしまう可能性があるため、十分に注意したい。

どっかでこのあたりもまとめてみようと思う。

 

以上

投稿日時:2017年06月11日 23:07   カテゴリー:mariadb, mysql   [コメントがあればどうぞ]

MariaDBで準同期レプリケーションで、

猛烈に書き込み中に、MariaDBを停止させ、

単純にslaveを昇格させただけでは、ロストする。

binlogをmasterから救い出さないといけない。

mhaではbinlogを救い出すという処理があるようだが、

当方が使っていたMariaDB Replication Managerにはそのような機能がない。

 

これに対し、Galleraで同じことをやっても、

ロストしなかった。

 

もうちょっといろいろなパターンでやってみないと分からないが、

Galleraのデータ整合性は、準同期よりも1ランク高い気がしている。

ただ、Galleraは書き込み性能がイマイチなので、

フロントにSpiderを置いて、shardingすれば、

高可用性・高負荷耐性をもったシステムが作れそうな気がしている。

 

また進展あれば、記載したいと思う。

 

以上

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