mysqlのreplication関連リンクまとめ
...mysqlのreplication関連情報まとめ
こんにちは。小宮です。
なんだかmysqlのことを聞かれることが多い今日この頃なので、
聞かれたときコピペできるように聞かれがちなことが説明されてるリンクをまとめる試みです。
この記事だけ読んでも大したことはわかりませんのであしからずご了承ください。
（自分がすっかり忘れたときにも役立ちそうです。）・基本
現場指向のレプリケーション詳説
漢(オトコ)のコンピュータ道: MySQLレプリケーションを安全に利用するための10のテクニック
Art of MySQL Replication.
バイナリログに書かれるのは更新系のクエリです。
補足すると、I/Oエラーは、物理的にディスクが壊れた、ネットワーク的につながらない、レプリケーション用ユーザのIDとパスワードが間違っている、server_idが重複している
などの理由で起こることがあります。SQLエラーの主な原因は上記の最初のリンクに書いてありますが主に重複エラーが多い印象です。参考までに現在のreplicationまわりの設定値はだいたいこんなかんじです。
[shell]## replication (master/slave) log-bin=mysql-bin log-bin-index=mysql-bin.index binlog_format=mixed server-id = 133 relay-log=mysqld-relay-bin relay-log-index=mysql-relay-bin.index log_slave_updates=1 replicate-ignore-db=mysql,information_schema,performance_schema binlog-ignore-db=mysql,information_schema,performance_schema skip_slave_start read_only slave_net_timeout=120
## replication (for 5.6) gtid-mode = OFF enforce_gtid_consistency=false master-info-repository=TABLE relay-log-info-repository=TABLE relay_log_recovery=ON #sync-master-info=1 slave-parallel-workers=0 binlog-checksum=CRC32 #master-verify-checksum=1 #slave-sql-verify-checksum=1 binlog-rows-query-log_events=1 #log_bin_use_v1_row_events=ON #sync_binlog=1 report-port=3306 report-host = 192.168.1.133[/shell]
mysqlfailoverをデーモンになってから試してみた
...※ 古い記事ですのでご注意ください。
こんにちは。小宮です。
まだ使いたい人がいるかわかりませんが検証してみましたので載せておきます。
長い記事になりますのでお時間のあるときにどうぞ。mysqlfailoverを–forceつけず–daemon=startで起動させる
以前検証したときは
–forceつけないと動かなかったのと
デーモンで起動させるオプションは存在しなかった
というわけでそこを再度たしかめてみます。・構成：
192.168.1.133 komiya-test-mysql01 my1 192.168.1.155 komiya-test-mysql02 my2 192.168.1.150 komiya-test-mysql03 my3 192.168.1.241 komiya-test-mysql04 my4 manager 192.168.1.222 vip・インストール：
パッケージは公式とかこのへんからダウンロードできます。
とりあえずchefでmysql5.6とutility等を入れておきました。
ssh-copy-idとknife solo prepareして
nodeファイルのrunlistにdbロール指定して
knife solo cookしただけで以下と必要な設定ファイルが置かれて
server_idとかreport_hostとか自動的に入るようにしました。
参考にしたレシピはこちら。以下が関連パッケージです。
mysql-utilitiesはpythonで書かれたツールなのでmysql-connector-pythonが必要です。$ rpm -qa|grep -i mysql MySQL-shared-compat-5.6.15-1.linux_glibc2.5.x86_64 MySQL-test-5.6.15-1.linux_glibc2.5.x86_64 perl-DBD-MySQL-4.013-3.el6.x86_64 mysql-utilities-1.4.1-1.el6.noarch mysqltuner-1.1.1-1.el6.noarch MySQL-client-5.6.15-1.linux_glibc2.5.x86_64 MySQL-server-5.6.15-1.linux_glibc2.5.x86_64 MySQL-devel-5.6.15-1.linux_glibc2.5.x86_64 mysql-connector-python-1.1.4-1.el6.noarch mysqlreport-3.5-4.el6.noarch・replicaitonを組む
server_idはipアドレスの第4オクテットにしたので重複しないはず。
report_hostも自分のIPに自動的になってるはず。VPC上でPrivateIPアドレスを付け替える
...こんにちは。小宮です。
ちょっと前にAWSのVPC上でVIP(VirtualIPアドレス)を移動させる需要があって検証したのですが、
個人的にメモってただけだったのと、質問される機会が数回ありましたので簡単にですが投稿しておきます。なんらかのクラスタ構成をVPC上で扱う際、VPC上でPrivateIPアドレスを付け替える必要が生じた場合、
awsなので切替スクリプトをAPI使うように修正しないと内部はともかく外部から打ったPINGへの応答が帰ってこない。
つまりVIPが移動したことになりません。つまり、以下のような感じになります
落とすときは、IF落としてかつCLIも実行する
[shell]ifconfig eth0:1 down ec2-unassign-private-addresses –network-interface eni-4b649*** –secondary-private-ip-address 10.0.0.96[/shell] ※ec2-unassign-private-addressesの短縮バージョンはec2upip
起動するときも、IF起動かつCLI実行する
[shell]ifconfig eth0:1 up ec2-assign-private-ip-addresses –network-interface eni-70609*** –secondary-private-ip-address 10.0.0.96[/shell] ※ec2-assign-private-ip-addressesの短縮バージョンはec2apip切替元のENI：eni-4b649***
切替先のENI：eni-70609***参考：
VPC 内の EC2 インスタンス に複数EIPを付与する
ec2-assign-private-ip-addresses - Amazon Elastic Compute Cloud
ec2-unassign-private-ip-addresses - Amazon Elastic Compute Cloudもし、EIPが紐づいてるENIをデタッチ、アタッチしたい場合、以下のような感じ。(たぶん(自分で試してないです))
[shell]ec2-detach-network-interface ${eni_attach_id} ec2-attach-network-interface ${ENI_ID} –instance ${target_instance_id} –device-index ${TARGET_DEVICE_INDEX}[/shell]
加えて、ifupしてip route処理をするといいらしい。
[shell]ifconfig eth${TARGET_DEVICE_INDEX} upMysqlのHAとトラブル事例
...久しぶりの更新になります。プラットフォームの宮下です。
先日開催されました、July Tech Festa2013というイベントの中の1コマで何と私が発表をさせて頂きました。
その時使用した資料をアップしますので興味のある方は是非一読下さい。[slideshare id=24320385&doc=mysqlha-130716215401-phpapp02]
mysqlのHA構成のデザインパターン紹介を経験談を交えて話させて頂きました。
とても緊張してしまって肝心のトラブル事例がお話出来ませんでした。このブログでは、包み隠さずトラブルのレポートが出来ればと思います。
今回のテーマは、小宮先生のレポートを多分に活用させて頂いています。
次回こそは、私の成果を発表したいもんです。それではまた近いうちに更新します。
MHAの動作確認と切替検証
...MHAの動作確認と切替検証
前回のつづきです。以下の図のように切り替わるようテストします。
※本検証はマスタ1台、スレーブ2台、マネージャ1台構成。(多段構成は中間ノード障害時の復旧が猥雑になるので回避)
スレーブにmanagerを同居させるとpurge_relay_logsとかぶると上手く切り替わらない可能性があるようです。
※2台しかない場合で上手く切り替わらないことがあるようです。以下参考。
http://heartbeats.jp/hbblog/2013/05/mysql-mha-haproxy.html⑥ 起動前チェック
・sshの動作チェック
[shell] # masterha_check_ssh –conf=/etc/app1.cnf [/shell] OKな場合最終的に以下のように出力される
[shell] Tue Oct 23 15:02:22 2012 - [info] All SSH connection tests passed successfully. [/shell]
・replicationの動作チェック
[shell] # masterha_check_repl –conf=/etc/app1.cnf [/shell] OKな場合最終的に以下のように出力される(※mysql5.6からはMHAのバージョンによってはbinlog-checksum=NONEにしないとここで失敗するかもしれません)
[shell] MySQL Replication Health is OK. [/shell] ※失敗するパターン
レプリケーションのフィルタリングルールが合っていない
LVSとMHAマネージャが相乗りの場合、チェックタイミングが重複しホスト毎DBサーバに拒否されてしまう(要flush hosts;)MHA(MasterHighAvailabilityManager)の導入設定
...MHA(MasterHighAvailabilityManager)の導入設定 使用バージョン：mha4mysql-manager-0.53-0、MySQL-5.5
①簡単な利点などの解説
MHAとはmysqlのマスタ障害時に最新のスレーブをマスタとして他のスレーブの差分を補完しマスタの向き先を変えてくれるプロダクト。
Heartbeat+mon+mysqlに比べるとreplicationの再構成も行ってくれるので切り替わってもDBがシングルにならないのが利点。(3台以上の構成の場合)作者のスライド
公式サイト
MHAの制約：mysql5.0以上、SBR(ステートメントベースレプリケーション)の場合LOAD DATA INFILEを使えない
※マネージャはadminサーバ、ノードはDBサーバ(マスタ・スレーブ共通)② マネージャにてインストール ※以下、admサーバから実施
・インストール
[php]wget http://mysql-master-ha.googlecode.com/files/mha4mysql-node-0.53-0.noarch.rpm
wget http://mysql-master-ha.googlecode.com/files/mha4mysql-manager-0.53-0.noarch.rpm
yum –enablerepo=rpmforge install \
perl-Config-Tiny \ perl-Time-HiRes \ perl-Log-Dispatch \ perl-Parallel-ForkManager \ perl-Params-Validate
yum install perl-DBD-MySQL
rpm -ivh mha4mysql*
[/php] 入ってなかったら
[shell]yum install –enablerepo=remi mysql mysql-server perl-DBD-MySQL[/shell] ※マネージャはmysql-serverいらないかも
③ ノードにてインストール ※以下、dbサーバから実施
[shell]
