СУБД 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: 0

mysql> SELECT * FROM test;
Empty set (0.00 sec)

Для включения СУБД BLACKHOLE, если вы собираете MySQL из исходного кода, вызовите CMake с опцией -DWITH_BLACKHOLE_STORAGE_ENGINE.

Чтобы ознакомиться с исходным кодом СУБД BLACKHOLE, обратитесь к каталогу sql дистрибутива MySQL.

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

СУБД BLACKHOLE поддерживает все типы индексов. То есть вы можете включать декларации индексов в определение таблицы.

Максимальная длина ключа составляет 1000 байт.

Проверить доступность СУБД BLACKHOLE можно с помощью команды SHOW ENGINES.

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

Предположим, что вашему приложению требуются правила фильтрации на стороне реплики, но передача всех данных бинарного журнала на реплику изначально приводит к слишком большому трафику. В таком случае можно настроить на хосте-источнике процесс репликации “фиктивный”, у которого СУБД по умолчанию — BLACKHOLE, как показано ниже:

Рисунок 15.1 Репликация с использованием BLACKHOLE для фильтрации

Источник записывает данные в свой бинарный журнал. Процесс “фиктивный” mysqld выполняет роль реплики, применяя желаемую комбинацию правил replicate-do-* и replicate-ignore-*, и записывает новый, отфильтрованный бинарный журнал. (См. Раздел 16.1.6, «Параметры и переменные репликации и бинарного журналика».) Этот отфильтрованный журнал предоставляется реплике.

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

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

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

СУБД BLACKHOLE учитывает транзакции в том смысле, что подтверждённые транзакции записываются в бинарный журнал, а отменённые — нет.

СУБД BLACKHOLE и столбцы с автоинкрементом

СУБД Blackhole — это СУБД, не выполняющая никаких действий. Любые операции, выполняемые над таблицей с использованием BLACKHOLE, не оказывают никакого эффекта. Это следует учитывать при рассмотрении поведения столбцов первичного ключа, которые автоматически увеличиваются. СУБД не увеличивает автоматически значения полей и не сохраняет состояние столбца автоинкремента. Это имеет важные последствия в репликации.

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

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

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

При репликации на основе строк значение, возвращаемое СУБД для строки, всегда будет одинаковым для каждой вставки. Это приводит к тому, что реплика пытается воспроизвести две записи журнала вставки с одинаковым значением для столбца первичного ключа, и поэтому репликация завершается ошибкой.

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

При использовании репликации на основе строк (binlog_format=ROW) поддерживается реплика, где отсутствуют последние столбцы в таблице, как описано в разделе Раздел 16.4.1.10, «Репликация с различными определениями таблиц на источнике и реплике».

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

Фильтрация столбцов источника может быть реализована с помощью СУБД 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;