云平台MySQL主从同步配置说明

一、云管理服务器初始化 Step 1. 关闭数据库 shell> mysqladmin -uusername -p shutdown

Step 2. 在my.cnf中更改如下选项。 [mysqld] server-id=1 gtid_mode=on enforce-gtid-consistency=on innodb_flush_log_at_trx_commit=1 sync_binlog=1 master_info_repository=TABLE relay_log_info_repository=TABLE log-slave-updates=on log0bin= skip-slave-start #复制进程就不会随着数据库的启动而启动 slave_skip_errors = ddl_exist_errors

binlog_format = row auto-increment-increment = 2 #必须要 auto-increment-offset = 1 #必须要

说明： master_info_repository # master info log 文件记录了备节点的连接信息，例如用户名，密码等,同时包括主节点信息

relay_log_info_repository # 记录了备节点应用 relay log 文件的进度情况 log_bin #这里指定的bin.log 默认路径是/var/lib/mysql/mysql-bin.000001，显示格式是名字加点6位数字，最后一个不一定是1，可以指定绝对路径

sync_binlog 默认为0，为0时当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘 为n时，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘，这里改为1， 为0时的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。而当设置为1的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。 从以往经验和相关测试来看，对于高并发事务的系统来说，"sync_binlog"设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

gtid_mode #网上是说了必须主从必须要设置一致才行，要么都on，要么都off，启勇gtid是为了方便回滚，具体的不了解，这里选择启用，毕竟是新特性5.6以下的不要配

enforce_gtid_consistency #强制gtid一致性

log_slave_updates #slave更新是否记入日志

binlog_format #二进制格式改为行row模式，三种模式statement语句模式,row行模式，mixed混合模式

transaction-isolation #读事务的隔离级别

innodb_autoinc_lock_mode #自增互斥方式，默认为1 innodb_autoinc_lock_mode = 0 (“traditional” lock mode：全部使用表锁) innodb_autoinc_lock_mode = 1 (默认)(“consecutive” lock mode：可预判行数时使用新方式，不可时使用表锁) innodb_autoinc_lock_mode = 2 (“interleaved” lock mode：全部使用新方式，不安全，不适合replication)

slave_skip_errors 跳过错误 auto-increment-increment = 2 auto-increment-offset = 1 主键大于2时，每次递增1

Step 3. 启动MySQL数据库

二、线下场库初始化

Step 1. 为从库访问主库设立用户和权限 mysql>use mysql; mysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'slavepass'; mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; mysql> flush privileges;

Step 2. 关闭数据库， shell> mysqladmin -uusername -p shutdown

Step 3. 在my.cnf中更改如下选项。 注：mysql-bin可以自定义，park_database_name为实际使用的停车场数据库名，server-id保证在云管理系统中唯一，由谁来分配？ [mysqld] log-bin=mysql-bin server-id=1111111111 gtid_mode=on enforce-gtid-consistency=on binlog_format=row innodb_flush_log_at_trx_commit=1 sync_binlog=1 binlog-do-db=webpark Lllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll [mysqld] log-bin=mysql-bin server-id=1111111 gtid_mode=on enforce-gtid-consistency=on binlog_format=row innodb_flush_log_at_trx_commit=1 sync_binlog=1 binlog-do-db=webpark

Step 4. 启动MySQL数据库

三、云管理增加线下场库

Step 1. mysql> CHANGE MASTER TO > MASTER_HOST = host, > MASTER_PORT = port, > MASTER_USER = user, > MASTER_PASSWORD = password, > MASTER_AUTO_POSITION = 1 > FOR CHANNEL 'CHANNEL_NAME'; 注：CHANNEL_NAME 需要唯一，可以结合场库ID使用

Step 2. mysql>START SLAVE FOR CHANNEL 'CHANNEL_NAME';

DDL语句始终是基于语句的复制，即使设置成基于行的复制，也是如此 基于语句复制时注意： 跨数据库的操作语句需要注意，可以规定禁止跨数据库进行操作。（场库只有一个主库） 例：--binlog-do-db=prices 禁止使用如下语句： USE prices; UPDATE sales.january SET amount=amount+1000; 此语句会将对sales库的更改也记录到日志中 USE prices; 只对prices库操作，不要对其他库操作。

创建表的操作： USE prices; CREATE TABLE `prices`.`a` ... 必须先使用USE prices;prices为需要同步的库

GTID方式注意事项： 不能使用CREATE TABLE ... SELECT语句 不能在事务中使用CREATE TEMPORARY TABLE和 DROP TEMPORARY TABLE语句；可以在事务外执行，但必须设置autocommit=1 使用GTID和非GTID的MySQL实例是不能复制数据的，要么都是GTID,要么都是普通的 在数据库运行时，不能使用mysql_upgrade 尽量使用事务存储引擎InnoDB,主从引擎一致 RESET SLAVE不能够按预想的那样执行相应操作

异常恢复 mysql -uroot -padmin@1880 -e "stop slave for channel '$parkname';" mysql -uroot -padmin@1880 -e "reset slave for channel '$parkname';" mysql -uroot -padmin@1880 -e "reset master;" mysql -uroot -padmin@1880 -e "create database if not exists $parkname;" mysqldump --opt $parkname --host='127.0.0.1' -uroot -P$[ 63000 + i ] -paaa | mysql -padmin@1880 -C $parkname mysql -uroot -padmin@1880 -e "change master to master_host='127.0.0.1',master_user='repl',master_password='slavepass',master_auto_position=1,master_port=$[ 63000 + i ] for channel '$parkname';" mysql -uroot -padmin@1880 -e "start slave for channel '$parkname';" sleep 5;//多个连续执行时，必须得等，否则新的reset master会导致错误

四、异常处理： 1、从机 Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Slave has more GTIDs than the master has, using the master's SERVER_UUID. This may indicate that the end of the binary log was truncated or that the last binary log file was lost, e.g., after a power or disk failure when sync_binlog != 1. The master may or may not have rolled back transactions that were already replica'