To give a simple answer to your question, "No, replication does not kill the performance of your master."
The impact on your master from replication is typically very small compared to all of the other things it has to do, because the master only really has to accomplish two significant things in a replication environment:
- formulate and write events to the binlog on the local hard drive, and
- send a copy of every event it writes to the binlog to every connected slave
I do not consider writing the binary log to be a cost of replication, because you should always have binary logging turned on even if you're not replicating. It's an extremely valuable troubleshooting and recovery tool.
The cost of sending the replication events to the slave(s) is also negligible, because the slave is responsible for maintaining a persistent TCP connection to the master, which only has to copy the data onto the socket as the events occur. Beyond that, the master neither knows nor cares whether or when the slave gets around to executing them.
A partial exception to that last statement is semi-synchronous replication, which is not the default. In this mode, the master waits for at least one slave to acknowledge receipt and persistent storage (though not actual execution) of the binary log events from each transaction, before the master returns control to the client on each commit.
But in every case, the master is not responsible for actually executing the updates on the slave -- it just sends one of two things to the slave: either a copy of the actual input query that ran (in statement-based mode) or the data for the rows actually inserted/updated/deleted by each query (in row-based mode). In mixed mode, the query optimizer will decide which format to use on a per-event basis.