Documentation Home
MySQL Utilities 1.5 Manual
Related Documentation Download this Manual
PDF (US Ltr) - 1.5Mb
PDF (A4) - 1.5Mb
EPUB - 366.9Kb
HTML Download (TGZ) - 288.4Kb
HTML Download (Zip) - 300.5Kb

MySQL Utilities 1.5 Manual  /  ...  /  How Do I Provision a Slave?

3.2.1 How Do I Provision a Slave?

When working with replication, one of the common tasks is adding a new slave for scale out. Although adding a new slave has been simplified with utilities like mysqlreplicate, provisioning the slave (copying data and getting replication started properly) can be a challenge if done manually.

Fortunately, we have two utilities - mysqldbexport and mysqldbimport - that have been designed to work with replication so that when the export is generated, you can include the proper replication control statements in the output stream.


Perform slave provisioning using mysqldbexport and mysqldbimport.

Example Execution

shell> mysqldbexport --server=root:root@localhost:13001 --all --export=both --rpl=master --rpl-user=rpl:rpl > data.sql
shell> mysqldbimport --server=root:root@localhost:13002 data.sql

# Source on localhost: ... connected.
# Importing definitions from data.sql.
ERROR: The import operation contains GTID statements that require the global gtid_executed 
system variable on the target to be empty (no value). The gtid_executed value must be reset 
by issuing a RESET MASTER command on the target prior to attempting the import operation. 
Once the global gtid_executed value is cleared, you may retry the import.

shell> mysql -uroot -proot -h --port=13002 -e "RESET MASTER"
shell> mysqldbimport --server=root:root@localhost:13002 data.sql

# Source on localhost: ... connected.
# Importing definitions from data.sql.
CAUTION: The following 1 warning messages were included in the import file:
# WARNING: A partial export from a server that has GTIDs enabled will by default include 
the GTIDs of all transactions, even those that changed suppressed parts of the database. 
If you don't want to generate the GTID statement, use the --skip-gtid option. To export all 
databases, use the --all and --export=both options.


There are several operations listed here. The first one we see is the execution of the mysqldbexport utility to create a file that includes an export of all databases as designated with the --all option. We add the '--export=both' option to ensure we include the definitions as well as the data.

We also add the --rpl=master option which instructs mysqldbexport to generate the replication commands with respect to the source server being the master. Lastly, we include the replication user and password to be included in the CHANGE MASTER command.

Next, we see an attempt to run the import using mysqldbimport but we see there is an error. The reason for the error is the mysqldbimport utility detected a possible problem on the slave whereby there were global transaction identifiers (GTIDs) recorded from the master. You can see this situation if you setup replication prior to running the import. The way to resolve the problem is to run the RESET MASTER command on the slave as shown in the next operation.

The next operation is a rerun of the import and in this case it succeeds. We see a warning that is issued any time there are replication commands detected in the input stream whenever GTIDs are enabled.

Permissions Required

The user used to read data from the master must have the SELECT privilege on all databases exported. The user on the slave must have the SUPER privilege to start replication.

Tips and Tricks

The warning issued during the import concerning GTIDs is to ensure you are aware that the process for gathering the proper GTIDs to execute on the slave include transactions from all databases. Thus, if you ran a partial export that includes the replication commands and you have GTIDs enabled, you should use the --skip-rpl option to skip the replication commands and restart replication manually.

Should your data be large enough to make the use of mysqldbexport impractical, you can use mysqldbexport to generate the correct replication commands anyway by using the --export=definitions option. This will generate the SQL statements for the objects but not the data. You can then use the replication commands generated with your own backup and restore tools.

You can use the option --rpl=slave to generate a output stream that considers the source server a slave and uses the source servers master settings for generating the CHANGE MASTER command.

User Comments
Sign Up Login You must be logged in to post a comment.