17.4.1.21 レプリケーションと MEMORY テーブル

マスターサーバーがシャットダウンして再起動すると、その MEMORY テーブルは空になります。マスターはこの影響をスレーブに複製するために、起動後に所定の MEMORY テーブルを最初に使用するときに、空にすべきテーブルの DELETE ステートメントをバイナリログに書き込むことで、そのテーブルを空にする必要があることをスレーブに通知するイベントのログを記録します。

スレーブサーバーがシャットダウンして再起動すると、その MEMORY テーブルは空になります。これによってスレーブはマスターとの同期を失うため、ほかの障害が発生したりスレーブが停止したりすることがあります。

• マスターから受け取る行形式更新および削除が「'memory_table' にレコードが見つかりません」で失敗する場合があります。

• INSERT INTO ... SELECT FROM memory_table などのステートメントがマスターおよびスレーブ上で異なる行セットを挿入することがあります。

MEMORY テーブルを複製するスレーブを再起動する安全な方法は、最初にマスター上の MEMORY テーブルからのすべての行をドロップまたは削除して、これらの変更がスレーブに複製されるまで待つことです。すると、スレーブを再起動しても安全です。

場合によっては、別の再起動方法を適用できることがあります。binlog_format=ROW のときは、スレーブを再起動する前に slave_exec_mode=IDEMPOTENT を設定すれば、スレーブの停止を回避できます。これによってスレーブは複製を継続できますが、MEMORY テーブルは依然としてマスター上のものと異なります。アプリケーションロジックが MEMORY テーブルの内容を安全に失うことができるようなものである場合 (たとえば、MEMORY テーブルがキャッシュに使用されている場合) は、これでかまいません。slave_exec_mode=IDEMPOTENT がすべてのテーブルにグローバルに適用されるため、MEMORY でないテーブルでほかのレプリケーションエラーを隠すことができます。

(上記の方法は MySQL Cluster には適用されません。slave_exec_mode は常に IDEMPOTENT で、変更できません。)

MEMORY テーブルのサイズは、max_heap_table_size システム変数の値によって制限され、これは複製されません (セクション17.4.1.34「レプリケーションと変数」を参照してください)。max_heap_table_size での変更は、変更後に ALTER TABLE ... ENGINE = MEMORY または TRUNCATE TABLE を使用して作成または更新された MEMORY テーブルに、またはサーバー再起動後にすべての MEMORY テーブルに反映されます。この変数の値をマスター上で増やしスレーブ上でそうしない場合は、マスター上のテーブルがスレーブ上のものより大きくなることができるため、挿入がマスター上で成功するけれどもスレーブ上で Table is fullエラーで失敗します:これは既知の問題です (Bug #48666)。このような場合、マスター上と同様にスレーブ上で max_heap_table_size のグローバル値を設定してから、レプリケーションを再開する必要があります。また、新しい値がそれぞれで完全 (グローバル) に反映されることを保証するために、マスターとスレーブの両方の MySQL サーバーを再起動することをお勧めします。

MEMORY テーブルに関する詳細は、セクション15.3「MEMORY ストレージエンジン」を参照してください。