The BLACKHOLE storage engine discards all data written to it but records operations in the binary log, useful for replication filtering and testing.
The BLACKHOLE storage engine accepts data but does not store it and always returns an empty result.
A table using the BLACKHOLE storage engine consists of a single .frm table format file, but no associated data or index files.
This storage engine can be useful, for example, if you want to run complex filtering rules on a slave without incurring any overhead on a master. The master can run a BLACKHOLE storage engine, with the data replicated to the slave for processing.
Although the plugin's shared library is distributed with MariaDB by default, the plugin is not actually installed by MariaDB by default. There are two methods that can be used to install the plugin with MariaDB.
The first method can be used to install the plugin without restarting the server. You can install the plugin dynamically by executing or :
The second method can be used to tell the server to load the plugin when it starts up. The plugin can be installed this way by providing the or the options. This can be specified as a command-line argument to or it can be specified in a relevant server in an :
You can uninstall the plugin dynamically by executing or :
If you installed the plugin by providing the or the options in a relevant server in an , then those options should be removed to prevent the plugin from being loaded the next time the server is restarted.
, , and statements all work with the BLACKHOLE storage engine. However, no data changes are actually applied.
If the binary log is enabled, all SQL statements are logged as usual, and replicated to any slave servers. However, since rows are not stored, it is important to use statement-based rather than the row or mixed format, as and statements are neither logged nor replicated. See .
Some work with the BLACKHOLE storage engine.
BEFORE for statements are still activated.
for and statements are not activated.
with the FOR EACH ROW clause do not apply, since the tables have no rows.
Foreign keys are not supported. If you convert an table to BLACKHOLE, then the foreign keys will disappear. If you convert the same table back to InnoDB, then you will have to recreate them.
If you convert an table which contains to BLACKHOLE, then it produces an error.
Because a BLACKHOLE table does not store data, it will not maintain the value. If you are replicating to a table that can handle AUTO_INCREMENT columns, and are not explicitly setting the primary key auto-increment value in the query, or using the statement, inserts will fail on the slave due to duplicate keys.
The maximum key size is:
3500 bytes (>= , , , and )
1000 bytes (<= , , , and ).
This page is licensed: CC BY-SA / Gnu FDL
INSTALL SONAME 'ha_blackhole';[mariadb]
...
plugin_load_add = ha_blackholeUNINSTALL SONAME 'ha_blackhole';CREATE TABLE table_name (
id INT UNSIGNED PRIMARY KEY NOT NULL,
v VARCHAR(30)
) ENGINE=BLACKHOLE;
INSERT INTO table_name VALUES (1, 'bob'),(2, 'jane');
SELECT * FROM table_name;
Empty set (0.001 sec)