MySQLレプリケーションにおけるフェイルオーバー – OpenGroove
MySQLレプリケーションにおいて、スレーブをマスタとしてフェイルオーバーさせる時に やることをざっくりまとめてみた。 マスタでは障害等によりMySQLインスタンスが停止していることが前提。 マスタ1:スレーブ1構成の場合 1.マスタに昇格するスレーブにSTOP SLAVEを発行。 2.マスタに昇格するスレーブにRESET MASTERを発行。 3.スレーブに降格するマシンでCHANGE MASTER を実行し、 START SLAVEする。 もう少し詳しく書くと。 1.スレーブ側でIOスレッドでのバイナリログ受け渡しが完了する頃を見計らって、 STOP SLAVE IO_THREAD を発行。 mysql > STOP SLAVE IO_THREAD; “Has read all relay log”を確認できまるまで、SHOW PROCESSLIST の出力結果をチェックする。 2.ス
レプリケーション時のRESET MASTERとRESET SLAVE – OpenGroove
さっそく一部追記（2010/04/14)。 MySQLレプリケーションにおいて発行するコマンド、RESET MASTERとRESET SLAVE、 それぞれの動作・挙動についてうっすらとまとめておく。なお、どちらもスレーブ側で 実行するという前提で話を進める。 RESET MASTER RESET MASTER文はスレーブがマスタに昇格するフェイルオーバー時に発行する。 これにより、スレーブはマスタのバイナリログを読みに行くのをストップする。 具体的には以下の状態になる。 バイナリログインデックスファイルを空白にリセット。 インデックスファイルにリストされたすべてのバイナリログを削除。 バイナリログがすべて消えてなくなるのではなく、例えばbin-log.000019まであった バイナリログはリセットされ、bin-log.000001のみが存在する状態になる。 RESET SLAVE RES
MySQLバイナリログの仕様 – OpenGroove
MySQLのバイナリログについて、うっすらまとめてみようかと。 RDBMSで更新ログまたはトランザクションログと呼ばれているログの機能は、 MySQLでは「バイナリログ」が担っている。 これらの内容は、「CREATE TABLE文やINSERT文といったデータベースの中身を 変更する操作を行った際の操作履歴を追跡できる形で記録した情報」であり、 コミットされたトランザクションの情報が保存される。 トランザクションログの中身はRDBMSによって異なり、「論理ロギング」と 「物理ロギング」がある。「論理ロギング」はSQL文レベルで変更履歴を管理し、 「物理ロギング」は変更があったデータブロックをバイナリイメージとして管理する。 MySQLのバイナリログは論理ロギングだが、OracleのREDOログやInnoDBログは 物理ロギングである。 バイナリログはデフォルトでは作成されないので、my.c
InnoDBログとバイナリログの違い – OpenGroove
InnoDBログファイルとバイナリログファイルの違いについて。 両者の違いは「InnoDBログファイルはクラッシュリカバリ時に使用され、 バイナリログファイルはロールフォワードリカバリ時に使用される」と捉えているが、 そもそもそれぞれの本質は何かというと、、、細かい仕様は抜きにして、とりあえず概要を。 InnoDBログファイル（ib_logfile0,ib_logfile1） ひと言で言うと、InnoDBテーブルへの更新情報をコミットと同時に同期書き込みするファイル。 ※InnoDBデータファイルはコミット同時書き込みではない。 トランザクションログとも呼ばれる。ちなみにOracleではREDOログに相当する。 InnoDBログファイルは１つのデータベース領域に少なくとも2つ作成される。 ログそのものには障害に備えるミラーリング機能はない。 バイナリログファイル（bin-log.00000
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
