MySQLバイナリログの仕様 – OpenGroove
MySQLのバイナリログについて、うっすらまとめてみようかと。 RDBMSで更新ログまたはトランザクションログと呼ばれているログの機能は、 MySQLでは「バイナリログ」が担っている。 これらの内容は、「CREATE TABLE文やINSERT文といったデータベースの中身を 変更する操作を行った際の操作履歴を追跡できる形で記録した情報」であり、 コミットされたトランザクションの情報が保存される。 トランザクションログの中身はRDBMSによって異なり、「論理ロギング」と 「物理ロギング」がある。「論理ロギング」はSQL文レベルで変更履歴を管理し、 「物理ロギング」は変更があったデータブロックをバイナリイメージとして管理する。 MySQLのバイナリログは論理ロギングだが、OracleのREDOログやInnoDBログは 物理ロギングである。 バイナリログはデフォルトでは作成されないので、my.c
レプリケーション時の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
InnoDBデータファイルの仕様 – OpenGroove
InnoDBデータファイルの仕様について、覚え書き。 MySQLデータディレクトリ配下に生成される、ibdata1、ibdata2…といったファイル名 のデータファイルが、InnoDBデータファイルである。このInnoDBデータファイルに 格納されるものは、というと。 ・InnoDBテーブル ・インデックスデータ ・データディクショナリ（テーブルのレコード数などの統計情報） ・トランザクションのロールバックのためのデータ領域 （ロールバックセグメント） ・・・といったところである。 InnoDBデータファイルは複数作成することが可能で、それらをまとめて「システム表領域」と呼ぶ。 ちなみに「Oracleで言えば、SYSTEM表領域だけでデータベースを構築するようなイメージである」 ということだそうだ。、、、と聞いても、自分はよく分からないが（汗） データベース領域上には、ただ１つのシステム表
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
