MariaDB Slave cause "Copying to tmp table"
Not MariaDB Slave, the Query Cache.

It appears that the first Profile came from a machine where the identical query had already been stored in the Query Cache.  Hence, the query took only a fraction of a millisecond to simply deliver the old resultset to the client.

The second server apparently has not seen the identical query recently, so it had to work on the query (open tables, optimize, use a tmp table, etc).  This took a lot longer.

Addenda

The Query Cache works this way:


If a query is in the QC, and exactly the same query shows up to be run, the resultset is delivered very rapidly from the QC.  However,
When any modification to the tables(s) involved occurs, the all entries in the QC for that table(s) are purged.
Replication is a stream of modifications.


For this reason, then QC is rarely worth turning on for Production servers with a lot of write traffic.

So, I deduce that the some modification (INSERT, UPDATE, etc) occurred to that table, thereby invalidating the entry in the QC before that second copy of the SELECT was presented.

If the stream of changes from Replication had only touched other tables, then the second query would have been just as fast as the first.