Replication with Global Transaction Identifiers There are several variants of this method, the difference being in the manner in which data dumps and transactions from binary logs are transfered to the replica, as outlined here: Copying data and transactions to the replica.   Executing the entire transaction history can be time- consuming when the source server has processed a large number of transactions previously, and this can represent a major bottleneck when setting up a new replica. To eliminate this requirement, a snapshot of the data set, the binary logs and the global transaction information the source server contains can be imported to the new replica. The server where the snapshot is taken can be either the source or one of its replicas, but you must ensure that the server has processed all required transactions before copying the data. 3465 Data Set 1. Create a dump file using  mysqldump  on the source server. Set the mysqldump  option  --master-data  (with the default value of 1) to include a  CHANGE REPLICATION SOURCE TO  |  CHANGE MASTER TO  statement with binary logging information. Set the  --set-gtid- purged  option to  AUTO  (the default) or  ON , to include information about executed transactions in the dump. Then use the  mysql  client to import the dump file on the target server. 2. Alternatively, create a data snapshot of the source server using raw data files, then copy these files to the target server, following the instructions in Section 17.1.2.5, “Choosing a Method for Data Snapshots” . If you use  InnoDB  tables, you can use the mysqlbackup  command from the MySQL Enterprise Backup component to produce a consistent snapshot. This command records the log name and offset corresponding to the snapshot to be used on the replica. MySQL Enterprise Backup is a commercial product that is included as part of a MySQL Enterprise subscription. See Section 30.2, “MySQL Enterprise Backup Overview”  for detailed information. 3. Alternatively, stop both the source and target servers, copy the contents of the source’s data directory to the new replica’s data directory, then restart the replica. If you use this method, the replica must be configured for GTID-based replication, in other words with gtid_mode=ON . For instructions and important information for this method, see Section 17.1.2.8, “Adding Replicas to a Replication Environment” . Transaction History If the source server has a complete transaction history in its binary logs (that is, the GTID set  @@GLOBAL.gtid_purged  is empty), you can use these methods. 1. Import the binary logs from the source server to the new replica using  mysqlbinlog , with the  --read-from-remote-server and  --read-from-remote-master  options. 2. Alternatively, copy the source server’s binary log files to the replica. You can make copies from the replica using  mysqlbinlog  with the --read-from-remote-server  and  --raw  options. These can be read into the replica by using  mysqlbinlog > file  (without the  -- raw  option) to export the binary log files to SQL files, then passing these files to the  mysql  client for processing. Ensure that all of the binary log files are processed using a single  mysql  process, rather than multiple connections. For example: