マスターサーバーがシャットダウンして再起動すると、その 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 ストレージエンジン」を参照してください。