Replication with Global Transaction Identifiers that it is possible to stop it; for information about provisioning replicas using GTIDs from a running source server, see Section 17.1.3.5, “Using GTIDs for Failover and Scaleout” . For information about changing GTID mode on servers online, see Section 17.1.4, “Changing GTID Mode on Online Servers” . The key steps in this startup process for the simplest possible GTID replication topology, consisting of one source and one replica, are as follows: The  mysqld  options necessary to start the servers as described are discussed in the example that follows later in this section. In the following example, two servers are already running as source and replica, using MySQL’s binary log position-based replication protocol. If you are starting with new servers, see Section 17.1.2.3, “Creating a User for Replication”  for information about adding a specific user for replication connections and Section 17.1.2.1, “Setting the Replication Source Configuration”  for information about setting the server_id  variable. The following examples show how to store  mysqld  startup options in server’s option file, see Section 4.2.2.2, “Using Option Files”  for more information. Alternatively you can use startup options when running  mysqld . Most of the steps that follow require the use of the MySQL  root  account or another MySQL user account that has the  SUPER  privilege.  mysqladmin shutdown  requires either the  SUPER  privilege or the SHUTDOWN  privilege. Step 1: Synchronize the servers.   This step is only required when working with servers which are already replicating without using GTIDs. For new servers proceed to Step 3. Make the servers read-only by setting the  read_only  system variable to  ON  on each server by issuing the following: mysql>  SET @@GLOBAL.read_only = ON; Wait for all ongoing transactions to commit or roll back. Then, allow the replica to catch up with the source. It is extremely important that you make sure the replica has processed all updates before continuing . If you use binary logs for anything other than replication, for example to do point in time backup and restore, wait until you do not need the old binary logs containing transactions without GTIDs. Ideally, wait for the server to purge all binary logs, and wait for any existing backup to expire. It is important to understand that logs containing transactions without GTIDs cannot be used on servers where GTIDs are enabled. Before proceeding, you must be sure that transactions without GTIDs do not exist anywhere in the topology. 3462 Important 1. If replication is already running, synchronize both servers by making them read-only. 2. Stop both servers. 3. Restart both servers with GTIDs enabled and the correct options configured. 4. Instruct the replica to use the source as the replication data source and to use auto-positioning. The SQL statements needed to accomplish this step are described in the example that follows later in this section. 5. Take a new backup. Binary logs containing transactions without GTIDs cannot be used on servers where GTIDs are enabled, so backups taken before this point cannot be used with your new configuration. 6. Start the replica, then disable read-only mode on both servers, so that they can accept updates.