mysql 复制

从库连接的账户密码以纯文本的形式存储在赋值的元数据信息表，或者文件中。由参数 master_info_repository =file/table
启用gtid 相关信息保存在mysql.gtid_executed 表内 gtid_executed_compression_period 变量控制是否压缩表信息保存

GTID 由源的UUID和这个服务器上尚未使用的非零事务序列号组成。如果客户端事务未写入二进制日志(如只读事务…)则不会为其分配gtid

ln -s /usr /local/mysql5.7/bin/mysqlbinlog /usr/local/bin/mysqlbinlog
mysql

mysqlbinlog 默认读取 /etc/my.cn 配置文件，为避免未知字符集问题需注释[cline] 下的默认字符集参数

mysql 复制

mysql 支持两种复制方式，1 基于语句的复制 2 基于行的复制（与binlog的记录格式相关）
在主库记录二进制日志，在备库重放二进制日志。在同一时刻无法保证主从数据的一致，一些大的语句可能导致备库产生较大的延迟。
mysql 复制大部分是向后兼容的，新版本服务器可以作为老版本的备库，但反过来不一定可行，因为其可能无法解析新版本采用的新特性或语法。
复制带来的开销：通常每个备库会对主库增加一些负载（如网络IO开销），尤其当备库从主库读取旧的二进制文件时，可能造成更高的IO开销，

通过复制可以将读操作指向备库来获取更好的性能，但对于写操作，除非设计得当。否则不适合通过复制来扩展写操作。在一主多从环境下，写操作会被执行多次，这个时候系统性能取决于写入最慢的部分。

复制解决的问题： 1 数据分布 2 负载均衡 3 备份 4 高可用性和故障切换 5 mysql升级次测试

复制基本：在主库上记录binlog 将主库binlog发送到从库成为从库的中继日志，从库回放中继日志。
涉及主库写 binlog 线程，从库获取主库binlog IO线程，从库回放sql sql线程。
IO 线程能够独立于 SQL线程工作，允许这两个线程一步进行。
复制架构的限制： sql线程只有一个，获取到主库的事件在备库上却只能串行执行。这是许多工作的性能瓶颈所在。虽然有些针对该问题的解决方案但大多数然受限。

配置复制： 1 创建具有权限的账户， 2 配置主库，从库。 3 通知备库连接到主库并启动主从线程开始复制

1 创建复制账户 CREATE USER ‘repl’@’%.example.com’ IDENTIFIED BY ‘password‘; GRANT REPLICATION SLAVE ON . TO ‘repl’@’%.example.com’;
账户最少需要 REPLICATION SLAVE 权限读取 binlog
2

推荐的安全复制配置： sync_binlog =1 mysql 每次在事务提交前都会将binlog同步到磁盘。保证服务崩溃时不会丢失事件。
innodb_flush_logs_at_trx_commit =1 ；skip_slave_start; sync_master_info =1 从库执行一个事件即将,master_ifo 信息写入磁盘；sync_relay_log_info =1 ；
sync_relay_log =1 .
relay_log_purge 控制是否删除不需要的relay_log .

复制的原理：
基于语句的复制模式，实际上是把主库上执行的SQL 在备库上再重做一次。
优点：实现相对简单，理论上简单记录和执行语句，能够让主备同步一致，二进制内的事件更加紧凑。
基于语句的模式复制不会使用太大的带宽。同时 mysqlbinlog 也最适宜基于语句的二进制工具。遇见复制的问题时更好知道问题的源头
问题：语句的执行还依赖其他因素，如SQL语句的执行时间，数据的元数据信息，一些无法正确复制的语句如 current_user() 等，触发器，函数，存储过程在基于语句的模式下可能存在问题。非确定性行为都难以复制。
另外备库上更新是串行的这可能需要更多的锁。不是所有存储引擎都支持这类复制。

基于行的复制模式可以正确的复制每一行，一些语句可以被更加高效地复制。
由于没有那种模式对所有情况都是完美的，可根据情况设置会话级变量 binlog_format 控制二进制日志格式。
问题：由于语句并没有在日志内记录，因此无法判断执行了那些SQL，备库使用一种完全不同的方式进行数据变更，而不是执行sql . 因此当出现问题时可能很难找到问题所在。

复制文件： mysql-bin.00000X mysql-bin.index(mysql依赖这个文件，识别二进制文件)
mysql-relay-bin-inedx; master_info: 保存备库连接主库的信息；不能删除，否则备库重启将无法访问主库，这个文件同时以文本方式复制了用户密码，需注意文件访问权限。 relay-log-info 包含当前备库复制的二进制日志和中继日志的坐标。同样不可删除，否则备库重启后将无法获知从哪个位置开始复制，可能会导致重放已经执行过的语句。

复制过滤器： 1 主库端过滤需要记录的binlog binlog-do-db/binlog-ignore-db
2 备库端过滤需要重放的relay-log replicate-ignore-db/replicate-do-db/replicate-wild-do-table/replicate-wild-ignore-table/replicate-rewrite-db
—replicate-ignore-db 忽略某些库的binlog 日志应用。
—replicate-ignore-table 忽略某些表的binlog 日志应用。
—replicate-do-db 应用某些库的binlog 日志。
—replicate-do-table 应用某些表的binlog 日志。
—replicate-wild-do-table 使用通配符来匹配那些应用binlog日志的表。
—replicate-wild-ignore-table 使用通配符来匹配那些不能应用binlog日志的表。
—replicate-rewrite-db，能够实现主库与从库数据库名称不同的复制，比如主库数据库名为A，从库数据库名为B，实现主库A到从库B的复制。

使用过滤复制需要非常慎重，更好的办法是阻止一些语句记录binlog 使用 set sql_log_bin =0 ;

MySQL 复制细节

mysql 主从复制细节

mysql 复制