The BLACKHOLE Storage Engine Inserts into a  BLACKHOLE  table do not store any data, but if statement based binary logging is enabled, the SQL statements are logged and replicated to replica servers. This can be useful as a repeater or filter mechanism. Suppose that your application requires replica-side filtering rules, but transferring all binary log data to the replica first results in too much traffic. In such a case, it is possible to set up on the replication source server a “dummy”  replica process whose default storage engine is  BLACKHOLE , depicted as follows: The source writes to its binary log. The “dummy” mysqld  process acts as a replica, applying the desired combination of  replicate-do-*  and  replicate-ignore-*  rules, and writes a new, filtered binary log of its own. (See Section 17.1.6, “Replication and Binary Logging Options and Variables” .) This filtered log is provided to the replica. The dummy process does not actually store any data, so there is little processing overhead incurred by running the additional  mysqld  process on the replication source server. This type of setup can be repeated with additional replicas. INSERT  triggers for  BLACKHOLE  tables work as expected. However, because the  BLACKHOLE  table does not actually store any data,  UPDATE  and  DELETE  triggers are not activated: The  FOR EACH ROW  clause in the trigger definition does not apply because there are no rows. Other possible uses for the  BLACKHOLE  storage engine include: The  BLACKHOLE  engine is transaction-aware, in the sense that committed transactions are written to the binary log and rolled-back transactions are not. • BLACKHOLE  is essentially a “no-op”  storage engine, so it could be used for finding performance bottlenecks not related to the storage engine itself. •Measurement of the overhead from binary logging, by comparing performance using  BLACKHOLE  with and without binary logging enabled. •Verification of dump file syntax. Figure 16.1 Replication using BLACKHOLE for Filtering 3419