スマートスタイル TECH BLOG|データベース&クラウドの最新技術情報を配信

MariaDB ServerからMariaDB ColumnStoreへのレプリケーションについて

先日MariaDB ColumnStore 1.2.4のリリースノートにInnoDB EngineテーブルからMariaDB ColumnStoreへのレプリケーション実装を確認しました。
今回は、同機能についての機能検証を行いたいと思います。

MariaDB ColumnStore 1.2.4 Release note

Add hidden switch for MariaDB async replication

Allow simple replication to ColumnStore

DWHへのレプリケーションが業務データベースより簡単に行えるようになると、様々な可能性が広がるかと思います。
これも、ColumnStoreがMariaDB Serverのストレージエンジンであるからこそ為せる技かと思います。

なお、この機能はInnoDBストレージエンジンのテーブルをマスタ、ColumnStoreストレージエンジンのテーブルをスレーブとした構成を意味します。

環境

今回は以下の環境を使用しました。

Hostname Software OS Desc
mariadb1 MariaDB Server 10.3.16 CentOS 7.5 Master server
um1 MariaDB ColumnStore 1.2.5 CentOS 7.5 User module(Slave)
pm1 MariaDB ColumnStore 1.2.5 CentOS 7.5 Performance Module

MariaDB ColumnStore 1.2.4は一部の機能に問題があったため現在ではRelease Removedのステータスとなっています。
検証の際にはMariaDB ColumnStore 1.2.5をご利用ください。

SystemConfig.ReplicationEnabled

MariaDB Serverからのレプリケーションを許可するためにReplicationEnabledオプションを有効化する必要があります。
Active Parent OAM(通常PM1) で以下のように設定を行い、再起動します。

設定が行われていることを確認します

テストテーブルの作成

InnoDB とColumnStoreにおけるテーブル定義に幾つかの差異があります

  • ColumnStoreにはインデックスが無い
  • ColumnStoreにはnvarcharが無い
  • auto_incrementの構文の違い
  • その他

そのためレプリケートするテーブル定義は事前に類似のものとして作成しておきます。

もし運用中にテーブルを追加する場合は

  • MariaDB Server側でバイナリログを出さない(set sql_log_bin=0)
  • ColumnStore側でレプリケーションエラーをスキップする(set global sql_slave_skip_counter=1)

等の工夫が必要になりそうです。

mariadb1

um1

mariadb1

um1

レプリケーション設定

MariaDB ColumnStoreのUM1のserver-idが1となっているため、MariaDB Server側のserver-idを10としました。
またこの機能は現在のところSTATEMENT Based Replicationでのみ動作しますので、binlog_formatを変更します。
ROW Based Replicationを行った場合、UM側のmysqldがSignal 6を受けてクラッシュし続ける状態となりましたのでご注意ください。

mariadb1

レプリケーション用ユーザを作成します。

mariadb1

現在のポジションを確認しておきます

mariadb1

レプリケーションの開始

ColumnStoreでレプリケーションを設定します。

um1

レプリケーションテスト

まずはInnoDB側でinsertを実行します

mariadb1

ColumnStore側でも反映されたことが確認できました

um1

マルチソースレプリケーションのテスト

DWHはデータを蓄積するためのデータベースですので、複数データソースがあることが一般的です。
通常のMariaDBではマルチソースレプリケーションが使用可能ですので、ColumnStoreでも可能かテストしてみました。
2台目のマスタとしてmariadb2を構築、起動しています。

um1

各サーバにテーブルを作成します。
CREATE TABLE時には set sql_log_bin = 0 を実行するのを忘れないようにしてください。

mariadb1

mariadb2

um1

um1

mariadb1, mariadb2

※ @@hostnameを使用していない理由としてはSTATEMENTベースの場合、スレーブのhostnameとなるためです。

um1

マルチソースレプリケーションについては同機能のチケットで触れられておりませんでしたが概ね正常に動作したようです。

しかしながら、MariaDB ColumnStoreはInnoDBと比較して1行ごとの更新は非常に遅いため、想定通り顕著にレプリケーション遅延が発生しました。

スレーブサーバ Second_behind_masterの最大値
MariaDB Server 20
MariaDB ColumnStore 139

replicate_do_db等のレプリケーションフィルタで更新するテーブルを絞る、更新はLOAD DATA INFILEで一度に行う等の工夫が必要そうです。

その他の注意点

  • 現在本機能はMulti-UM環境で正常に動作しないようです
  • 本来業務データベースとDWH、行指向データベースと列指向データベースでは最適なスキーマ構造が異なります。VIEWをColumnStore側に作成する等の工夫が必要です。
  • ColumnStoreは少量のデータであっても比較的大きなデータファイルを初期作成しますのでレプリケーションによって細かいテーブルが増えると不要にストレージが消費されます。
  • replicate-do-db/replicate-do-table等レプリケーションフィルタを設定する事が必要になるかもしれません。
  • INSERTに限らずUPDATEやDELETE等の処理もレプリケートされ、これらを除外するフィルタは基本機能ではありません。

まとめ

通常のレプリケーションがMariaDB ColumnStoreで可能となったのは大きな進歩です。

しかしながら、データベース特性の違いによる問題や、ROW Based Replicationができない等、課題はまだまだあるようです。

次期リリースであるMariaDB Columstore 1.4では様々な課題が解決されることを期待しつつ、まずは限定的に試すのがよいでしょう。


MariaDB

 

Return Top