MySQLのスレーブを再起動しても勝手にレプリケーションが再開しないようにする

MySQLで、マスタ系を動かしたまま、スレーブの更新を一時的に止めたいという状況はよくあります。スレーブ群の中から一台だけサービスアウトし、STOP SLAVE;してテーブル変更やリペアテーブルしてからSTART SLAVE;するというやつです。

このSTOP SLAVE;ですが、MySQLプロセスを再起動すると勝手にSLAVEが再開してしまいます。ですので、テーブル変更時にうっかり（ディスク増強などのために）MySQLを再起動するといつの間にかレプリケーションが始まってウワーッとなります。悲しいですね。

my.confにこのようなレプリケーションの自動開始の抑制オプションがないか探してみましたが、ないようです。skip-networkingを有効にしておけばスタンドアローン化するかと思いましたが、これは「TCPをリッスンしない」オプションなので、リッスン側のマスターでレプリケーションを抑止するのに役にたっても、スレーブ側の抑止には役に立たないようです。

CHANGE MASTER TO構文でわざと存在しないホストをマスターに指定することも考えましたが、正しい設定をどこかにメモっておかなければならないので若干面倒くさいです。ですので、master.infoファイルを一時退避することで「MySQLのスレーブを再起動しても勝手にレプリケーションが再開しないようにする」が実現できることを確認しました。

mv master.info master.info.bk

mysql> show slave status\G;
Empty set (0.00 sec)

ERROR: 
No query specified

あんまり安全では無さそうですが、やむを得ずスレーブ停止中に再起動が必要になった時には自己責任でお試しください。あともっとマトモなやり方を知っていたら教えてください

追記

@ono_matope skip-slave-start

— Issei Narutaさん (@mirakui) 8月 12, 2012

ありがとうございます。

Dynamoの論文を訳した

Dynamo: Amazonの高可用性Key-value Store[和訳] — Gist

DynamoDBとかも出てきた事だし、MySQL以外のデータベースに興味が出て来たのでNoSQL的な流れの源流っぽいDynamoの論文を読んでみることにしました。十日くらい掛けて一通り読んだものの、時間がかかりすぎて何が書いてあったのか全く覚えていなかったので、論文の抄訳的なものをサラリと書き出して理解に努めようと思ったのだけど、残念ながらサラリとエッセンスを抽出出来るほど頭がよくなかったので、しょうがないのでカッとなって全訳しました。

 Dynamoは、「顧客は例えディスクが壊れていようが、ネットワーク経路が断線しようが、データセンターが竜巻で破壊されようが、彼らのショッピングカートを閲覧したり、アイテムを追加したりできるべきです」とか、その可用性のためにバージョン衝突とその調停を受け入れ、カートに追加したアイテムが消えたりはしないが、カートから削除したアイテムがいつの間にか復活する事態は許容する、みたいな決断をしているあたりがかっこいいなと思いました。

ECのデータ永続化に関してそんな設計に承認したりするのは怖くてそうだと思うのだけど、技術的な限界点とECサービスとしてのビジネス要件を高度に判断する企業なんだなーという印象を持ちました(ECサービスに関わったことがないので素人の見解です)。トランザクション処理や原子性保証が自明でないNoSQL時代においてスケールするシステムを構築するためには、そういった判断が重要になってくるのかなと思いました。

ところで落ち着いて読んでみたらDynamoとDynamoDBは思いのほか別物だったのでいま泣いてます。

VirtualBoxのディスクストレージ設定とIO性能

こんにちは、小野マトペです。

自宅サーバーをVirtualBox on Mac miniに移行してサービスする事が出来れば、面積、静音性、可搬性、サービス独立性の面で有利だと思って、いろいろやってる。VirtualBoxを選んだのは、無料だしライセンス的な面倒がなさそうだから。あとベンチマークも悪くなさそうだったから。

VirtualBox VMの仮想ストレージには色々な設定があるが、それぞれパフォーマンスにどのような影響を与えるか調べてみた。

調査項目

• Dynamically allocated : VirtualBoxのディスクストレージには、実際に使われてから動的に領域が確保される "Dynamically allocated"と、作成時に全領域を実際に確保してしまう"Fixed size"の二つのモードがある。当然動的確保する前者の方がIOが遅くなるが、マニュアルには「動的確保によるペナルティはわずかなのでDynamically allocated推奨」とか書いてあったが、動的確保で作ったディスクへのscpが妙に遅かったので、両者のベンチマークを取る事にした。
• ホストのI/Oキャッシュを使う：ゲストのI/OにホストOSのI/Oキャッシュを使ってI/Oを高速化するオプション。ただしゲスト側でフラッシュした筈の書き込みが実際にディスクイメージに書き込まれないので、当然危険。あとホストのメモリを食いつぶすので、複数ゲストの実行時にパフォーマンスが低下する

調査環境

• 物理ホスト：27-inch, Mid 2010 / 2.8 GHz Intel Core i5 / 16 GB / Mac OS X Server Lion 10.7.2
• VirtualBox：Oracle VirtualBox for Mac 4.1.8
• 仮想マシン：128GB SATA HDD/ 1024MB RAM / 1CPU / Scientific Linux 6.1 64bit

調査方法

• bonnie++ -s 2048M
• 大体の傾向が測れれば満足なので試行回数1。

調査結果

Sequential Outputに関しては固定の方が動的割り当てより2倍ほど速い感じ。固定割り当ての時にはホストI/Oキャッシュがとても効果的に働いていて、ホストOSの実行速度を上回っている。まあ、非同期I/Oになっているので当然と言えば当然。

Sequential Inputも、固定サイズ+ホストI/Oキャッシュが物理マシンの20%になっている以外は比較にならない感じで、ここまで遅かったっけ…。

Random Seek回数。これも固定サイズ+ホストI/Oキャッシュのときだけ異様に速くて、他がゴミのような値。

まとめ

シーケンシャルライトなら固定VMのが2倍速い。障害時にデータ破損してもよい AND VM台数が少ないならホストI/Oキャッシュ有効化すればライトとランダムアクセスはネイティブ以上の性能が出る。ただしリードは壊滅的。「物理マシンの半分くらいは出るんじゃないの？」ってたかをくくってたので、少し驚き。