Table of Contents
- 2.1 How to Set Up Replication
- 2.1.1 Setting the Replication Source Configuration
- 2.1.2 Setting the Replica Configuration
- 2.1.3 Creating a User for Replication
- 2.1.4 Obtaining the Replication Source Binary Log Coordinates
- 2.1.5 Creating a Data Snapshot Using mysqldump
- 2.1.6 Creating a Data Snapshot Using Raw Data Files
- 2.1.7 Setting Up Replication with New Source and Replicas
- 2.1.8 Setting Up Replication with Existing Data
- 2.1.9 Introducing Additional Replicas to an Existing Replication Environment
- 2.1.10 Setting the Source Configuration on the Replica
- 2.2 Replication Formats
- 2.3 Replication with Global Transaction Identifiers
- 2.4 Replication and Binary Logging Options and Variables
- 2.5 Common Replication Administration Tasks
Replication between servers in MySQL is based on the binary logging mechanism. The MySQL instance operating as the replication source server (the source of the database changes) writes updates and changes as “events” to the binary log. The information in the binary log is stored in different logging formats according to the database changes being recorded. Replicas are configured to read the binary log from the source and to execute the events in the binary log on the replica's local database.
You cannot configure the source to log only certain events.
The source is “dumb” in this scenario. Once binary logging has been enabled, all statements are recorded in the binary log. Each replica receives a copy of the entire contents of the binary log. It is the responsibility of the replica to decide which statements in the binary log should be executed; you cannot configure the source to log only certain events. If you do not specify otherwise, all events in the source's binary log are executed on the replica. If required, you can configure the replica to process only events that apply to particular databases or tables.
Each replica keeps a record of the binary log coordinates: The file name and position within the file that it has read and processed from the source. This means that multiple replicas can be connected to the source and executing different parts of the same binary log. Because the replicas control this process, individual replicas can be connected and disconnected from the server without affecting the source's operation. Also, because each replica records the current position within the binary log, it is possible for replicas to be disconnected, reconnect and then resume processing.
The source and each replica must be configured with a unique ID
variable). In addition, each replica must be configured with
information about the source's host name, log file name, and
position within that file. These details can be controlled from
within a MySQL session using the
TO statement on the replica. The details are stored within
the replica's connection metadata repository, which can be either a
file or a table (see Section 5.2, “Relay Log and Replication Metadata Repositories”).
This section describes the setup and configuration required for a replication environment, including step-by-step instructions for creating a new replication environment. The major components of this section are:
For a guide to setting up two or more servers for replication, Section 2.1, “How to Set Up Replication”, deals with the configuration of the systems and provides methods for copying data between the source and replicas.
Events in the binary log are recorded using a number of formats. These are referred to as statement-based replication (SBR) or row-based replication (RBR). A third type, mixed-format replication (MIXED), uses SBR or RBR replication automatically to take advantage of the benefits of both SBR and RBR formats when appropriate. The different formats are discussed in Section 2.2, “Replication Formats”.
Detailed information on the different configuration options and variables that apply to replication is provided in Section 2.4, “Replication and Binary Logging Options and Variables”.
Once started, the replication process should require little administration or monitoring. However, for advice on common tasks that you may want to execute, see Section 2.5, “Common Replication Administration Tasks”.