The simple answer is No.
In Mysql replication, Master copies the bin log files to slaves, and after that, it's work is over. Now the Slave will run the bin files and execute them, but there won't be any performance on Master.
There might be scenario where you are using full synchronous replication, in which master will wait for the slave to execute the query, but again it won't impact the performance in terms of memory or CPU, but the master will wait for the query to be executed.
Also, for your second question, Phil already answered it, that ssh sends data through encryption which uses a lot of CPU, hence if you want other ways, use the other methods which are described by Phil.
You can safely write to a schema on the slave if that schema does not exist on the master or if you correctly use replication filters to prevent its replication to the slave.
"Correctly" is the important word in that sentence. Refer to this page:
https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html
Check the --replicate-do-db and other filter settings, and note that the behavior changes based on whether binlog events are formatted as rows or as statements. When statement-based replication is being used, replication filters only apply to the database in use as the current database. When row-based replication is used, the filters are applied regardless of current database.
Be sure you get this right, otherwise, you could have a situation like this:
replicate-ignore-db=monkey
binlog_format=STATEMENT
Then you do this:
USE zebra;
TRUNCATE monkey.tablex;
Guess what? tablex just got truncated on both master and slave. However, if you had this instead:
replicate-ignore-db=monkey
binlog_format=ROW
and did the same TRUNCATE on the master, monkey.tablex would not be truncated on the slave.
Note that this all applies according the binlog_format in use at the time the event is logged, and since binlog_format can be changed on a per-session basis, you can get some surprises unless you know exactly what's going on.
Having said all that, if the schema you're writing to does not even exist on the master, then you have nothing to worry about, other than the fact that you can't have read_only or super_read_only set on the slave if you plan on writing to it, so you can't count on it preventing write activity.
Best Answer
I like this presentation by Giuseppe Bianchi. Starting on page 5 it contains a desctiption of the TLS protocol - segment size, header size, HMAC overhead. As for the handshake, the impact on replication should be negligible. It will only occur on connection, and there may be a key exchange going on every hour, depending on the configuration. As for the compression, I'd go with what the book says. Or you can try gzipping your binlog file, as the ratio will likely be application-specific. (This may not be accurate if the compression is initialized per packet, not once for the replication stream.) On performance - type "openssl speed" in the command line, you'll get a benchmark of the throughput of different ciphers on your computer. Find the relevant ones and calculate the utilization given the throughput you expect from the replication stream.