Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb


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 ストレージエンジン」を参照してください。


User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
  Posted by z b on February 5, 2015
> the first time that the master uses a given MEMORY table after startup, it logs an event that notifies slaves that the table must to be emptied by writing a DELETE statement for that table to the binary log

Note that this can be problematic if you use binlog_do_db and have memory tables not listed there.
MySQL will still always write the DELETE query after a server restart, even if it's for a table not to be replicated.
I'm not sure whether this is intentional or a limitation, but I can't see it noted anywhere.
Sign Up Login You must be logged in to post a comment.