BLACKHOLE механизм хранения действует как "черная дыра", которая принимает данные, но выбрасывает их и не хранит их. Извлечения всегда возвращают пустой результат:

mysql> CREATE TABLE test(i INT, c CHAR(10)) ENGINE =
        BLACKHOLE;Query OK, 0 rows affected (0.03 sec)mysql> INSERT
        INTO test VALUES(1,'record one'),(2,'record two');Query OK, 2 rows affected (0.00 sec)Records: 2  Duplicates: 0  Warnings: 0mysql> SELECT * FROM test;Empty set (0.00 sec)

Включать BLACKHOLE механизм хранения, если Вы создаете MySQL из источника, вызывает CMake с -DWITH_BLACKHOLE_STORAGE_ENGINE опция.

Исследовать источник на BLACKHOLE механизм, загляните sql каталог исходного распределения MySQL.

Когда Вы создаете a BLACKHOLE таблица, сервер создает файл формата таблицы в каталоге базы данных. Файл начинается с имени таблицы и имеет .frm расширение. Нет никаких других файлов, связанных с таблицей.

BLACKHOLE механизм хранения поддерживает все виды, индексирует. Таким образом, можно включать, индексируют объявления в табличном определении.

Можно проверить ли BLACKHOLE механизм хранения доступен с SHOW ENGINES оператор.

Вставляет в a BLACKHOLE таблица не хранит данных, но если оператор, базируемое двоичное журналирование включается, SQL-операторы, регистрируется и тиражируется в ведомые серверы. Это может быть полезно как повторитель или фильтровать механизм.

Предположите, что Ваше приложение требует, чтобы ведомая сторона, фильтрующая правила, но передающая весь двоичный файл, регистрировала данные к ведомому устройству, сначала приводит к слишком большому количеству трафика. В таком случае возможно установить на ведущем узле "фиктивный" ведомый процесс, механизм хранения значения по умолчанию которого BLACKHOLE, изображенный следующим образом:

Ведущее устройство пишет в его двоичный журнал. "Макет" mysqld обрабатывает действия как ведомое устройство, применяя требуемую комбинацию replicate-do-* и replicate-ignore-* правила, и записи новый, фильтруемый двоичный собственный журнал. (См. Раздел 16.1.4, "Репликация и Двоичные Опции Журналирования и Переменные".) Этот фильтруемый журнал обеспечивается для ведомого устройства.

Фиктивный процесс фактически не хранит данных, таким образом есть небольшие издержки обработки, понесенные, выполняя дополнительный процесс mysqld на ведущем узле репликации. Этот тип установки может быть повторен с дополнительными ведомыми устройствами репликации.

INSERT триггеры для BLACKHOLE таблицы работают как ожидалось. Однако, потому что BLACKHOLE таблица фактически не хранит данных, UPDATE и DELETE триггеры не активируются: FOR EACH ROW пункт в триггерном определении не применяется, потому что нет никаких строк.

Другие возможные применения для BLACKHOLE механизм хранения включает:

BLACKHOLE механизм осведомлен о транзакции, в том смысле, что фиксировавшие транзакции пишутся двоичному журналу, и назад прокрученные транзакции не.

Механизм черной дыры и Столбцы автоприращения

Механизм Черной дыры не является никаким-op механизмом. Любые операции, выполняемые на таблице, используя Черную дыру, не будут иметь никакого эффекта. Это должно родиться в памяти, рассматривая поведение столбцов первичного ключа что автоматический инкремент. Механизм не будет автоматически постепенно увеличивать значения полей, и не сохраняет автоматическое полевое состояние инкремента. У этого есть важные импликации в репликации.

Рассмотрите следующий сценарий репликации, где все три из следующих условий применяются:

В этом сценарии репликация перестанет работать с двойной ошибкой записи на столбце первичного ключа.

В операторе базируемая репликация, значение INSERT_ID в контексте событие всегда будет тем же самым. Репликация поэтому перестанет работать из-за попытки, вставляют строку с двойным значением для столбца первичного ключа.

Последовательно основанная репликация, значение, которое механизм возвращает для строки всегда быть тем же самым для каждого, вставляет. Это приведет к ведомому устройству, пытающемуся воспроизводить два, вставляют записи журнала, используя то же самое значение для столбца первичного ключа, и таким образом, репликация перестанет работать.

Фильтрация столбца

При использовании построчной репликации, (binlog_format=ROW), ведомое устройство, где последние столбцы отсутствуют в таблице, поддерживается, как описано в Разделе раздела 16.4.1.9, "Репликация с Отличающимися Табличными Определениями на Ведущем устройстве и Ведомом устройстве".

Эта фильтрация работы над ведомой стороной, то есть, столбцы копируются в ведомое устройство прежде, чем они будут отфильтрованы. Есть по крайней мере два случая, где это не является требуемым, чтобы скопировать столбцы в ведомое устройство:

Основная фильтрация столбца может быть достигнута, используя BLACKHOLE механизм. Это выполняется в пути, подобном тому, как основная табличная фильтрация достигается - при использовании BLACKHOLE механизм и --replicate-do-table или --replicate-ignore-table опция.

Установка для ведущего устройства:

CREATE TABLE t1 (public_col_1, ..., public_col_N,                 secret_col_1, ..., secret_col_M) ENGINE=MyISAM;

Установка для доверяемого ведомого устройства:

CREATE TABLE t1 (public_col_1, ..., public_col_N) ENGINE=BLACKHOLE;

Установка для недоверяемого ведомого устройства:

CREATE TABLE t1 (public_col_1, ..., public_col_N) ENGINE=MyISAM;