There are no hard-and-fast rules for such Slaves. Let's look at two scenarios
Some standardize all DB Servers to have the same configuration. The rationale behind this is promote a Slave to a Master should have to fail over to it.
A scaled down Slave being used as a data backup. No reads from that Slave.
COMPARISON OF SLAVES
For a Slave whose sole job was backup and simple data redundancy, using less optimization is fine but can come at a premium. How so ?
If you have Master that has high write volume, this can result in MySQL Replication having lots of Replication Lag (Seconds_Behind_Master > 0 and increasing). This can occur when a Master has 20 INSERTs, UPDATEs, and DELETEs happening in parallel. Those 20 commands are serialized in the Master's binary logs and are serially processed by the SQL thread on the Slave. If you scale down the hardware and MySQL config settings on the Slave too much, that Replication Log can get worse than the aforementioned serialization of updates.
The volume of writes on the Master should be inversely proportional to scale down of the Slave:
- the higher the volume of writes on the Master
- the less the scale down of the Slave
- the lower the tolerance for Replication Lag (preferably none)
- the lower the volume of writes on the Master
- the more the scale down of the Slave
- the higher the tolerance for Replication Lag (expected to be infrequent)
In this context, scale down means
- less RAM required
- less need for CPU/cores
- lower cache settings
- lower max_connections
UPDATE 2015-02-02 12:53 EST
Based on the question in your comment about writes, you can increase the following on the Slave