In GTID-based replication, how the expansion of a read-only instance?
As used herein, mysqldump tool Master node on a data backup, note a critical parameter: - set-gtid-purged [= name], this parameter represents the backup file, which has already been performed GTID, and when change master, replication It will be after these GTID.
--set-gtid-purged[=name]
Add 'SET @@GLOBAL.GTID_PURGED' to the output. Possible
values for this option are ON, OFF and AUTO. If ON is
used and GTIDs are not enabled on the server, an error is
generated. If OFF is used, this option does nothing. If
AUTO is used and GTIDs are enabled on the server, 'SET
@@GLOBAL.GTID_PURGED' is added to the output. If GTIDs
are disabled, AUTO does nothing. If no value is supplied
then the default (AUTO) value will be considered.
mysqldump command is as follows:
$ bin/mysqldump --user=root --password='123456' --socket=/home/mysql/mysql3309/tmp/mysql.sock --default-character-set=utf8mb4 --events --routines --triggers --force --hex-blob --quick --single-transaction --set-gtid-purged=ON --databases db1 lg > /tmp/bak/data.sql
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.
Observation backup file data.sql, will find place two worth noting:
• When using the backup file to import data, the session-level system variable @@ SESSION.SQL_LOG_BIN set to 0, that does not generate binary log.
SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
SET @@SESSION.SQL_LOG_BIN= 0;
...
SET @@SESSION.SQL_LOG_BIN = @MYSQLDUMP_TEMP_LOG_BIN;
• Set up a global system variable @@ GLOBAL.GTID_PURGED.
SET @@GLOBAL.GTID_PURGED='0c34233d-b2e1-11e9-85cf-080027f22add:1-2,
32a0c858-b59f-11e9-b069-0800270c3d91:1-2,
447e96e1-b59f-11e9-95fe-0800270c3d91:1-2,
4fdc13e1-b59e-11e9-b5e0-080027f22add:1-9,
b8282f18-b59e-11e9-83b0-0800270c3d91:1-5';
Also it sets @@ GLOBAL.GTID_EXECUTED, which is based on the copy where to start. To be exact, @@ GLOBAL.GTID_EXECUTED is empty, you can set @@ GLOBAL.GTID_PURGED, otherwise an error as follows. Meanwhile @@ GLOBAL.GTID_EXECUTED @@ GLOBAL.GTID_PURGED be arranged and have the same value.
ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
Query OK, 1 row affected (0.00 sec)
Before importing the backup data, observed value of @@ GLOBAL.GTID_PURGED, and the new @@ GLOBAL.GTID_EXECUTED Slave node.
[[email protected]][(none)]> select @@GLOBAL.GTID_PURGED;
+----------------------+
| @@GLOBAL.GTID_PURGED |
+----------------------+
| |
+----------------------+
1 row in set (0.00 sec)
[[email protected]][(none)]>
[[email protected]][(none)]> select @@GLOBAL.GTID_EXECUTED;
+------------------------+
| @@GLOBAL.GTID_EXECUTED |
+------------------------+
| |
+------------------------+
1 row in set (0.00 sec)
After import the data, and then observed.
[[email protected]][(none)]> source /tmp/bak/data.sql;
...
[[email protected]][lg]> select @@GLOBAL.GTID_PURGED;
+-------------------------------------------------+
| @@GLOBAL.GTID_PURGED |
+-------------------------------------------------+
| 0c34233d-b2e1-11e9-85cf-080027f22add:1-2,
32a0c858-b59f-11e9-b069-0800270c3d91:1-2,
447e96e1-b59f-11e9-95fe-0800270c3d91:1-2,
4fdc13e1-b59e-11e9-b5e0-080027f22add:1-9,
b8282f18-b59e-11e9-83b0-0800270c3d91:1-5 |
+-------------------------------------------------+
1 row in set (0.00 sec)
[[email protected]][lg]> select @@GLOBAL.GTID_EXECUTED;
+-------------------------------------------------+
| @@GLOBAL.GTID_EXECUTED |
+-------------------------------------------------+
| 0c34233d-b2e1-11e9-85cf-080027f22add:1-2,
32a0c858-b59f-11e9-b069-0800270c3d91:1-2,
447e96e1-b59f-11e9-95fe-0800270c3d91:1-2,
4fdc13e1-b59e-11e9-b5e0-080027f22add:1-9,
b8282f18-b59e-11e9-83b0-0800270c3d91:1-5 |
+-------------------------------------------------+
1 row in set (0.00 sec)
Finally, you can change master.
CHANGE MASTER TO
MASTER_HOST='10.0.2.6',
MASTER_USER='repl',
MASTER_PASSWORD='123456',
MASTER_PORT=3309,
MASTER_AUTO_POSITION = 1;
Note that in some special scenarios, you may need to manually set @@ GLOBAL.GTID_PURGED.
In GTID-based replication, how to set it cascading replication, replication topology as required, wherein the arrow represents the direction of copying data in parentheses portion does not exist.
S <- M (-> M' -> S')
Establishing if the first M '-> S' replication relationship, using mysqldump backup data on M, and then introduced M ', data is from M' Copy to S 'do, known from the above, provided @@ SESSION import the data. SQL_LOG_BIN = 0, so the data will not be 'replicated to S' from M, and this is not the same Position-based replication, i.e. a manner not set SQL_LOG_BIN.
$ bin/mysqldump --user=root --password='123456' --socket=/home/mysql/mysql3309/tmp/mysql.sock --default-character-set=utf8mb4 --events --routines --triggers --force --hex-blob --quick --single-transaction --set-gtid-purged=OFF --master-data=2 --databases db1 lg > /tmp/bak/2data.sql
Therefore, the correct idea is to use the backup data while restoring M 'and S', and create M '-> S', and finally establishing M -> M '.
For Failover, there is no need to specify site information, you can directly change master, much simpler than Position-based replication. Also, by introducing the previous articles, you can also find GTID-based replication to copy than Position-based data consistency in terms of more stringent, unlike Position-based replication casual designated sites, the replication process if no error, it you can continue.
PS: When using xtrabackup backup data, the above idea is completely established.