If a relay slave (a.k.a. Distribution Master) is using nothing but the BLACKHOLE storage engine for application tables, you really should not have to tune anything for MyISAM or InnoDB since there are no data or index pages to cache.
You will have a nominal amount of disk I/O (mostly reads) since the
.frm file for every BLACKHOLE is still accessed for metadata purposes. This same behavior also happens to MEMORY tables. I wrote a post about this. I helped the person asking the question realize that dropping and creating MEMORY tables created disk I/O.
I presume you are not going to drop and add tables all that often since the relay slave needs to remain all BLACKHOLE. Nevertheless, CPU and Memory should not be a big factor on a relay slave. You should be concerned with the following on the Relay Slave:
- Sufficient Disk Space for Binary and Relay Logs
- Fast Enough Disk for Writing
- Setting sync_binlog=1 in
my.cnf for flushing binlogs thoroughly
- Rotation of Binary Logs (setting a proper expire_logs_days)
- Avoid replicating the following:
- storage-engine specific
ALTER TABLE statement that BLACKHOLE can't work with
ALTER TABLE statements not accepted by BLACKHOLE, InnoDB, and MyISAM
- creating tables with
ENGINE=MyISAM because you want all tables in the relay slave to remain BLACKHOLE.
I have addressed this scenario before
UPDATE 2014-08-11 11:47 EDT
Additional Clarification : A pure Relay Slave (Distribution Master) should never have MyISAM and InnoDB tables present. Suppose you run
CREATE TABLE (...) ENGINE=InnoDB; on the Master. The Relay Slave will attempt to create the InnoDB table on the Relay Slave. If the Relay Slave has
skip-innodb configured, it could possibly end up as a MyISAM table. You want to avoid that because it will increase disk I/O and InnoDB or MyISAM activity.
If the Relay Slave has both
default-storage-engine=BLACKHOLE configured, you would have to run a create table with identifying the storage engine (
CREATE TABLE (...);).