SH2先生のRDB比較, ぶっ壊れ編

SH2 @sh2nd

個人的にそうなんだろうなあと思っていたことが書いてあって、とても腑に落ちた記事 / how oracle prevent "partial write" | Oracle Community https://t.co/nHcmvh5ZSA

SH2 @sh2nd

MySQLのinnodb_doublewrite、PostgreSQLのfull_page_writesのような、データブロックが半分しか書かれていない事態を想定した処理は、Oracle DatabaseはALTER TABLESPACE BEGIN BACKUPのときにのみ行う

SH2 @sh2nd

なのでサーバクラッシュ時にデータブロックが壊れていて、REDOを適用しただけでは直せないことがある。ただその場合Oracle Databaseはチェックサムで破損を検出し、ブロック・メディア・リカバリで該当データファイルだけを速やかに復旧させることができる。復旧はDBAが行う

SH2 @sh2nd

MySQLにはInnoDBのページ単位でリカバリする機能はないし、そもそもmysqldumpで論理バックアップしか取らないのことも多いので、partial writeによって壊れた場合はフルリストア、リカバリが必要になる

SH2 @sh2nd

ページが破損するたびにフルリストア、リカバリを行うのは大変なので、普段からinnodb_doublewriteで壊れないようにしている。Oracle Databaseは該当表領域がオフラインになるだけでインスタンスは動き続け、壊れたところだけピンポイントに直せる

SH2 @sh2nd

MySQL(InnoDB)でページ破損が見つかった場合は、Oracle Databaseと異なりインスタンス自体がダウンする。ただPercona Serverの場合は継続稼働するためのオプションが用意されている http://t.co/cmCajLysDR

SH2 @sh2nd

MySQL 5.7新機能のatomic writeとそれに対応したデバイス(ioDrive)を組み合わせることでinnodb_doublewriteを不要にできる。個人的にはMySQL Enterprise Backupでブロック・メディア・リカバリができるようになればいいと思う

SH2 @sh2nd

PostgreSQLについては、ブロックのチェックサムが付いたのが最新のPostgreSQL 9.3からで、デフォルトではOFFという事情がある。デフォルトでは壊れても検出すらできないのでfull_page_writesをOFFにすることは大変危険

SH2 @sh2nd

PostgreSQLとしては、チェックサムを有効にして、今後Oracle Databaseのようなブロック・メディア・リカバリ機能が提供されれば、full_page_writesをOFFにできる可能性が出てくる

SH2 @sh2nd

勉強終わり