MySQL 5.1.53リリース

出てます。今回は13件のバグ修正が行われており、そのうちレプリケーションに関するものが8件となっています。レプリケーションに関するバグ修正を確認しておきましょう。

マスタがMySQL 5.1でスレーブがMySQL 5.5、かつ行ベースレプリケーションを利用している場合、SET PASSWORD文を実行するとレプリケーションが失敗していました。MySQL 5.1からMySQL 5.5へのレプリケーションを行ベースで行う場合は、MySQL 5.1.53以降、およびMySQL 5.5.7以降を使用してください。(Bug#57098)
MyISAMテーブルに対してALTER TABLE文を実行し、カラムの名前のみを変更するなどしてそのサイズについては変更が行われなかった場合、バイナリログが破損してしまいレプリケーションが失敗することがありました。(Bug#56226)
STOP SLAVE文が実行されると、通常スレーブ側のSQLスレッドは現行のトランザクションをロールバックしてただちに停止します。これはそのトランザクションがトランザクション対応のテーブルを更新するだけ、という場合の挙動です。しかし、トランザクションがCREATE TEMPORARY TABLE文あるいはDROP TEMPORARY TABLE文を含む場合、これらの文はロールバックすることができません。一時テーブルはユーザーセッションが続いている限り存続するものなので、ロールバックを実行してもなおスレーブがリセットされるまでは残っているのです。そのためスレーブを停止後に続けてSTART SLAVE文を実行すると、SQLスレッドは先ほどのトランザクションを再度実行しようとし、「一時テーブルがすでに存在します」などのエラーを出力して停止してしまっていました。今回の修正によって、現行のトランザクションがCREATE TEMPORARY TABLE文あるいはDROP TEMPORARY TABLE文を含んでいる場合、SQLスレッドは現行のトランザクションが完了するのを待ってから停止するようになりました。(Bug#56118)
同じ名前を持つ通常のテーブルと一時テーブルがある場合、更新処理は一時テーブルの方にのみ適用されます。ただしこの場合でも(CREATE TEMPORARY TABLE ... SELECTではなく)CREATE TABLE ... SELECT文は通常のテーブルを作成します。このような文がMIXEDモードでレプリケーションされ、かつその文が文ベースのレプリケーションにとって安全でなく行ベースとしてレプリケーションされた場合、更新処理が誤って一時テーブルの方に適用されていました。(Bug#55478)
スレーブでmax_binlog_cache_sizeを超えるサイズのトランザクションを実行しようとすると、スレーブはクラッシュします。このときER_TRANS_CACHE_FULLというエラーが返され、サーバは該当の文をロールバックすることになりますが、トランザクション全体をロールバックする必要はありません。しかし、スレーブのSQLスレッドはどのようなエラーが発生した場合でも、トランザクション全体をロールバックしてしまっていました。(Bug#55375)
リレーログの設定をCHANGE MASTER TO文で変更した際、I/Oキャッシュがクリアされていませんでした。そのためスレーブがキャッシュから古いデータを読み込もうとして、レプリケーションが失敗することがありました。(Bug#55263)
バイナリログにSlave_log_eventという本来は現れないはずのイベントが記録されることがあり、これをスレーブ側のSQLスレッドが読み込むとスレーブがクラッシュしていました。(Bug#38718)
mysql.tables_privテーブルをレプリケーションする際、Grantorカラムの内容がレプリケーションされておらず、スレーブ側で空になっていました。(Bug#27606)

相変わらずレプリケーション機能が枯れていないのですが、ここまでリリースノートを追いかけてきた中で、バグを極力踏まないための設計方針というものは見えてきたのではないかと思います。

マスタとスレーブでMySQLのメジャーバージョンが異なる際は、十分な試験を行うこと
マスタとスレーブで、同じテーブルに対し異なるストレージエンジンを使用しないこと
あるトランザクション内でアクセスする複数のテーブルについて、ストレージエンジンを統一すること
一時テーブルは極力使わないこと、使う場合には既存のテーブルと同じ名前をつけないこと
MySQLのパラメータはマスタとスレーブで極力揃えること

ご参考になれば幸いです。