072015以前書いた「PacemakerでMySQLレプリケーション構成」のCentOS7+MariaDB環境用です。CentOS7になってMySQLがMariaDBになったこと、pcsコマンドのオプションが若干変更になっていることが主な変更点になります。最近のmysqlリソースエージェントでは、MySQLデータベースをMaster/Slaveセットとして構成することができます。DRBD同様、TakeoverによってReplicationのMaster/Slaveを入れ替えることが可能となります。7のPacemakerを使ってMariaDBデータベースをMaster/Slaveセットとして構成してみました。セットアップする環境は以下になります。PacemakerとCorosync一式はCentOS提供のパッケージをインストールしクラスター構成済みです。x86_64)レプリケーションの設定まずはPacemaker範囲外で、MariaDBをインストールしてレプリケーションを構成します。MariaDBのレプリケーション構成手順の詳細は公式ドキュメントを参照してください。https://mariadb.com/kb/en/mariadb/setting-up-replication/MariaDBのインストールおよび設定MariaDBをインストールし設定します。/etc/my.cnf/etc/my.cnfは[mysqld]セクションに以下を追加します。server-idは1とします。log-bin=mariadb-binserver-id=12号機も同様です。/etc/my.cnf/etc/my.cnfは[mysqld]セクションに以下を追加します。server-idは2とします。log-bin=mariadb-binserver-id=2レプリケーションユーザーの作成1号機側のみで作業します。MySQLを起動します。mariadb.serviceレプリケーションユーザーを作成します。'slavepass';アクセス元をもっと厳格に限定したい場合は、ホスト部分を環境にあわせて設定してください。mysqlリソースエージェントでは、通常のレプリケーション以外にもread-onlyに切り替える権限をもったユーザーが必要になるため、localhostでもレプリケーションユーザーを作成します。'slavepass';ユーザーを作成したら反映します。PRIVILEGES;これらの権限が必要な理由についてはリソースエージェントで以下のように説明されています。/></parameter>MariaDBを停止してデータベースファイル一式を2号機にコピーします。クラスターリソースのセットアップ最初にSlaveとして稼働させる2号機をStandbyにします。pcmk12クラスターリソースを登録します。RAの推奨値を設定しています。Master/Slaveセットを作成します。notify=trueクラスターリソースを開始します。mysql-clone1号機がMasterとして起動します。~]#2号機のStandbyを解除します。pcmk122号機がSlaveのレプリケーション構成としてMySQLが起動します。TOが実行されていることがわかります。pcmk11コマンドでMaster側をStandbyにするとMasterが切り替わります。pcmk11してStandby解除するとpcmk11はSlaveとして稼働を開始します。cib.xmlを見てみるとバイナリログの位置情報がcluster_property_setとして記録されていることがわかります。TOを実行する必要がないため、セットアップも非常に楽になります。262013最近のmysqlリソースエージェントでは、MySQLデータベースをMaster/Slaveセットとして構成することができます。DRBD同様、TakeoverによってReplicationのMaster/Slaveを入れ替えることが可能となります。6.4のPacemakerを使ってMySQLデータベースをMaster/Slaveセットとして構成してみました。セットアップする環境は以下になります。PacemakerとCorosync一式はCentOS提供のパッケージをインストールしクラスター構成済みです。x86_64)レプリケーションの設定まずはPacemaker範囲外で、MySQLをインストールしてレプリケーションを構成します。MySQLのレプリケーション構成手順の詳細は公式ドキュメントを参照してください。http://dev.mysql.com/doc/refman/5.1/ja/replication-howto.htmlMySQLのインストールおよび設定MySQLをインストールし設定します。/etc/my.cnf/etc/my.cnfは[mysqld]セクションに以下を追加します。server-idは1とします。log-bin=mysql-binserver-id=12号機も同様です。/etc/my.cnf/etc/my.cnfは[mysqld]セクションに以下を追加します。server-idは2とします。log-bin=mysql-binserver-id=2レプリケーションユーザーの作成1号機側のみで作業します。MySQLを起動します。startレプリケーションユーザーを作成します。'slavepass';アクセス元をもっと厳格に限定したい場合は、ホスト部分を環境にあわせて設定してください。mysqlリソースエージェントでは、通常のレプリケーション以外にもread-onlyに切り替える権限をもったユーザーが必要になるため、localhostでもレプリケーションユーザーを作成します。'slavepass';ユーザーを作成したら反映します。PRIVILEGES;これらの権限が必要な理由についてはリソースエージェントで以下のように説明されています。/></parameter>mysqlを停止してデータベースファイル一式を2号機にコピーします。クラスターリソースのセットアップ最初にSlaveとして稼働させる2号機をStandbyにします。pcmk12クラスターリソースを登録します。RAの推奨値を設定しています。Master/Slaveセットを作成します。notify=trueクラスターリソースを開始します。mysql-clone1号機がMasterとして起動します。~]#2号機のStandbyを解除します。pcmk122号機がSlaveのレプリケーション構成としてMySQLが起動します。TOが実行されていることがわかります。pcmk11コマンドでMaster側をStandbyにするとMasterが切り替わります。pcmk11してStandby解除するとpcmk11はSlaveとして稼働を開始します。cib.xmlを見てみるとバイナリログの位置情報がノードの属性として記録されていることがわかります。TOを実行する必要がないため、セットアップも非常に楽になります。EC2上で動かしているZabbixのテーブルサイズ推移を計測中です。pluginを使っています。Zabbixでの取得item数は110項目ほどで、9割方の項目がhistory=7/trends=365/delay=60の設定になっています。1週間経過してのデータ量推移は以下のようになりました。全テーブル分のデータを取得しているのでグラフが冗長ですが、Zabbixがデータを累積するのはhistory系とtrends系のテーブルですので、そちらに着目していただけるとわかりやすいかと思います。mysql_table_size推移file_sizes推移テーブルサイズ、ファイルサイズともにhistoryとhistory_uintが増加し続け、history保存期限の1週間を経過したところからほぼ横ばいになりました。10.10パッケージデフォルト)。言うと、レコード追加と削除の繰り返しでテーブルの断片化が進み、テーブルサイズは横ばいだがファイルサイズは増え続けるような状況を予想していたのですが、削除レコードの領域も上手に再利用されているようです。TYPE=InnoDBを実行して断片化解消しなきゃダメなのかな、と思っていたのですが、サイズ傾向だけで見る限りではそんな必要もなさそうです。😉EC2を1年以上継続利用する予定は今のところないのですが、気が向いたら1ヶ月後ぐらいに再度状況アップするかも知れません。