SHOW MASTER STATUS\G
SHOW REPLICA HOSTS;
SHOW REPLICA STATUS\G
SELECT @@SERVER_ID;
Must be different for each instance in the replication topologySELECT @@INNODB_FLUSH_LOG_AT_TRX_COMMIT;
Recommended Setting: 1SELECT @@SYNC_BINLOG;
Recommended Setting: 1SELECT @@SKIP_NETWORKING;
Must be 0 for replication to workIf you just have 1 replica then this should be enough...
STOP REPLICA;
If you have more than 1 replica.. On the new Master to be...
STOP REPLICA;
RESET BINARY LOGS AND GTIDS;
On the other Slaves...
STOP REPLICA;
CHANGE REPLICATION SOURCE TO SOURCE_HOST='MyNewMaster';
START REPLICA;
TODO
TODO
Master-master replication (with load balancer) introduces the possibility that two or more servers can replicate concurrent changes to each other. To prevent key conflicts by using the auto_increment_offset and auto_increment_increment configuration variables, to ensure AUTO_INCREMENT values will be unique to each server.
auto-increment-increment = 2
auto-increment-offset = 2 or 1
Appropriate load balancers would be:
keepalived
haproxy
heartbeat + mon
mysql-proxy
F5 Big-IP
java conection pools
the safest option is to use one server as active for both writes and reads, second will be treated as standby
no synchronous replication - if application can handle replication lag between servers it is possible to scale out reads
difficult to extend - this is only 2 server setup