【MySQL】AFTER_SYNCとかいうイケメン

5.7からのデフォルトはAFTER_SYNC、それまでの設定はAFTER_COMMITに該当する

準同期レプリケーション動作時のレプリケーション方式で、AFTER_SYNCはLossless型と言われている。
5.6までは、rpl_semi_sync_master_wait_pointというパラメータ自体なかった。

AFTER_COMMITでは、Slave側のストレージエンジンへのCOMMITが完了する前にクライアントへOKを返す。
あくまで、Slave側へのリレーログへの書き込みが完了したらクライアントへOKを返すので、データベースの状態は、常に一致しているとは言い切れない。
なので、Slaveが追従しているタイミングで、Masterが切り替わった場合、それまでに発行されてたクエリがないことになってしまう。

一方、AFTER_SYNCでは、COMMITする前にACK(受信確認)を待つようになっている。
ということは、Master上でCOMMITしたトランザクションは、SlaveでもCOMMITしたといえる。
なので、原則的にデータベースの内容は完全一致するはず。というすごくイケてるパラメータ。
(のはず。であっているよね( ^ω^)・・・)

【MySQL】Master稼働状態のままSlaveのレプリケーションを復旧

Master側での操作

Slave側での操作

【MySQL】非同期型レプリケーション

MySQLのレプリケーション方式である非同期型レプリケーションについて勉強したので自分なりにまとめてみたぞ。

① クラアイント(アプリケーション)からMasterノードにコミット実行
② コネクションスレッドが、データへの書き込み&バイナリログへの書き込みを実行(どちらか片方のみ実行されるということはない(原始性保証))
③ ②が正常終了したことをクライアントへ応答する
※①-③はMasterノードで一貫されて行われる動作
④ SlaveのI/Oスレッドがバイナリログの更新情報を受け取る
⑤ I/Oスレッドがリレーログに書き込む
⑥ SQLスレッドがリレーログを読み込む
⑦ SQLスレッドがリレーログを読み取った順にデータへ書き込んでいく

なので、非同期型レプリケーションはMySQLのデフォルトであるものの、Masterノードがクラッシュした場合、それがコミットしたトランザクションがスレーブに転送しきれずにいる場合もあり得る。
Pacemaker/Corosyncなどでのクラスタリング環境にて、Masterノードへのコミットが常時行われている状態でのフェイルオーバーはデータロストの危険性がある。
このデータロストを担保するためには、準同期レプリケーションを採用するという手がある。
準同期レプリケーションでは、クライアントからのコミットをMasterノードで一旦完結させずに、Slaveのリレーログへの書き込みが完了した時点で、応答を返す。
データの一貫性は非同期型よりも勝っているが、毎回Slaveからの応答を待つため、その分がオーバーヘッドになり単純な反応速度は非同期型に劣る。

【MySQL】スロークエリログを有効化

スロークエリログはSQLの実行に時間がかかったクエリをログ出力できるよ。
ログを出力するということはI/Oが増加するが、細かなデバッグがしやすくなるよ。
わりと構築中はONにしておいて、トラブルシュートし、それが解消したらOFFにするのが王道らしい。

my.cnfか、my.cnf.d内のファイルに記載する
以下は0.5秒以上SQLの実行に時間を要した場合出力される

DBにログインし、見てみる

【MySQL】「[ERROR] –initialize specified but the data directory has files in it.」が出力され、起動しない

journaldでメッセージを見てみると以下のようなメッセージががが・・・

どうやら、「validate_password=off」を初回起動時からmy.cnfなりに設定していると起動しないっぽい。
普通に手動インストールしていれば、my.cnfはデフォ状態で起動するだろうから、自動化しようとしたりしていると突っかかるかもしれない。
なので、消すなりコメントアウトしてあげる。ちなみに、コメントアウトして再インストールしないとダメっぽい気がする・・・

この機能いらなくない??

【MySQL】Inoodbのチューニング後mysqldが起動しなくなった

my.cnfに「innodb_data_file_path=ibdata1:1G:autoextend」を設定したら、起動しなくなった件。
この設定自体は、ibdata1を1GBで用意して、足りなくなったらibdata2とかを作成し自動拡張するというもの。

で、すでにmysqlを起動している場合、ibdata1が1GBじゃないサイズで作成されていて、そのファイルとのサイズ不一致で起動してこなくなるみたい。

このサイトとかを見ると、ファイルダンプ→ibdata再作成→リストアといった方法をとっているのだけど、結局うまくいかず。。。
http://www.ilovex.co.jp/blog/system/projectandsystemdevelopment/mycnfinnodbmysql.html

なので、mysqlのインストール前から、/etc/my.cnfをセットした状態でインストールしてみたらいけました。