zoukankan      html  css  js  c++  java
  • MySQL-Replication

    1. 复制工作原理

    主从复制过程存在三个线程,Master端的I/O dump thread,Slave的I/O thread和sql thread。Master端需要开启binlog日志,Slave端需要开启relay log。
         1)在slave端准备开始复制时,通过change master命令设置连接master参数
         2)主库将客户端接收的SQL的请求记录到binlog日志中,从库的I/O thread去请求主库的binlog给dump出来,之后IO线程负责监控并接收主库dump出来的二进制日志写入到自己的relay log(中继日志)文件中。
         3)主库通过I/O dump thread给从库的I/O thread传送binlog日志。
         4)在从库上SQL线程用于监控、读取并重放relay log中的日志,将数据写入到自己的数据库中,实现数据同步

    异步复制

    image

    半同步复制

    image

    2. 部署基于binlog+position主从异步复制

    这里在同一台虚机中部署,使用MySQL5.7.28+linux7

    2.1)初始化2个实例

    /ups/app/mysql/mysql3308/bin/mysqld --defaults-file=/ups/app/mysql/mysql3308/config/my.cnf.cnf --user=mysql 
    --basedir=/ups/app/mysql/mysql3308 --datadir=/ups/data/mydata/mysql3308 --initialize-insecure
    
    /ups/app/mysql/mysql3308/bin/mysqld --defaults-file=/ups/app/mysql/mysql3308/config/slave3309.cnf --user=mysql 
    --basedir=/ups/app/mysql/mysql3308 --datadir=/ups/data/mydata/slave3309 --initialize-insecure

    2.2)配置复制参数

    # open binary log mode
    log_bin = /ups/data/mydata/binlogs/b3308
    binlog-format = ROW
    expire_logs_days = 3
    max_binlog_size = 1024M
    log_slave_updates = ON
    relay_log = /ups/data/mydata/binlogs/r3309

    2.3) 启动服务

    # 启动服务 3309端口实例
    export MYSQL_HOME="/ups/app/mysql/mysql3308"
    MY_CONFIG="${MYSQL_HOME}/config/slave3309.cnf"
    ${MYSQL_HOME}/bin/mysqld_safe --defaults-file=${MY_CONFIG} &

    2.4)创建复制专用账号--所有实例

    create user 'sync'@'192.168.10.%' identified by 'sync';
    grant replication slave on *.* to 'sync'@'192.168.10.%';
    flush privileges;
    
    select user,host,authentication_string from mysql.user;

    2.5) 数据初始化

    -- master --master-data=2 让备份文件记录binlog及position号
    mysqldump --single-transaction -uroot -proot -P3308 -S /ups/app/mysql/mysql3308/logs/mysql3308.sock --master-data=2 --all-databases >all.sql
    
    -- slave 恢复主库传递过来的数据
    mysql -uroot -proot -P3309 -S /ups/app/mysql/mysql3308/logs/slave3309.sock < all.sql
    
    # 利用xtrabackup进行备份恢复
    -- master备份
    innobackupex -uroot -proot -P3308 -S /ups/app/mysql/mysql3308/logs/mysql3308.sock /ups/data/mydata/backup/all_$(date +%Y%m%d)
    innobackupex -uroot -proot -P3308 -S /ups/app/mysql/mysql3308/logs/mysql3308.sock --apply-log /ups/data/mydata/backup/all_$(date +%Y%m%d)
    -- 将上面文件传递到slave并恢复
    rm -rf data
    innobackupex  --defaults-file=/ups/app/mysql/mysql3308/config/slave3309.cnf --copy-back /ups/data/mydata/backup/all_$(date +%Y%m%d)
    chown mysql:mysql data
    chmod 700 data

    2.6)在从库执行change master语句配置连接主数据库连接参数,并默认情况下自动产生datadir/master.info文件和relay-log.info文件

    CHANGE MASTER TO
    MASTER_HOST='192.168.10.181',
    MASTER_USER='sync',
    MASTER_PASSWORD='sync',
    MASTER_PORT=3308,
    MASTER_LOG_FILE='b3308.000014',
    MASTER_LOG_POS=852;

    2.7)在从库执行启动复制线程

    -- 开启主从复制线程,slave I/O thread线程连接master,连接成功时,master会同时启动一个I/O dump线程
    start slave;
    
    # 单独启动线程
    start slave io_thread;
    start slave sql_thread;
    
    -- 检查
    show slave statusG;
    show master statusG;

    clipboard

    2.8)查看master.info和relay-log.info文件信息

    master.info文件记录的是IO线程相关的信息,也就是连接master以及读取master binlog的信息

    clipboard

    relay-log.info文件中记录的是SQL线程相关的信息

    clipboard

    3. 半同步复制

       MySQL5.5之后引入半同步复制功能,主从服务器必须同时安装半同步复制插件实现。在半同步复制方式下,客户端发起的请求必须确保从库接收完主库传递过来的binlog内容已经写入到自己的relay log后才会通知主库上面的等待线程,主库再给客户端回复反馈信息。如果等待超过参数(rpl_semi_sync_master_timeout)的时间,则关闭半同步复制,并自动转为异步复制模式,直到至少有一台从库通知主库已经接收到binlog信息为止。

        注意:生产环境不建议将半同步复制切换到异步复制,因此,会将rpl_semi_sync_master_timeout参数设置得很大。

    半同步复制重要参数包括:
         rpl_semi_sync_master_wait_point :参数用来控制半同步复制下主库在返回给session事务成功之前的事务提交方式。
             AFTER_SYNC:5.7之后新增参数,也是默认半同步方式。主库将每个事务写入binlog,并传递给从库,刷新到relay log中,主库开始等待从库的反馈,接收到从库回复之后再提交事务并返回ACK给客户端。
             AFTER_COMMIT:5.6版本默认值,主库将事务写入binlog,并传递给从库,刷新到relay log中,同时主库提交事务,之后主库开始等待从库反馈,只有收到从库反馈之后,主库才将ACK的结果反馈给客户端。
            
         rpl_semi_sync_master_enabled:在主库配置,确保主库的半同步复制功能开启。
         rpl_semi_sync_master_timeout:配置主库等待多少毫秒时间来保证接收备库的确认消息
         rpl_semi_sync_slave_enabled:在从库配置,确保从库的半同步复制功能开启。
         Rpl_semi_sync_master_no_tx:没有成功接收slave提交的次数
         Rpl_semi_sync_master_yes_tx:成功接收slave事务回复的次数

    3.1 半同步复制实验环境搭建

    1)安装插件

    # 检查是否支持动态安装加载插件
    select @@global.have_dynamic_loading;
    
    # 1. 动态加载插件
    -- master
    show variables like 'have_dynamic_loading';
    INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
    -- 动态方式启动,有需要可以写入my.cnf,确保每次启动mysql自动启动半同步复制
    set global rpl_semi_sync_master_enabled=on;
    
    -- slave 
    show variables like 'have_dynamic_loading';
    INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
    set global rpl_semi_sync_slave_enabled=on;
    
    # 检查插件安装情况
    show global variables like 'rpl_semi_sync%';
    show plugins;
    SELECT
        PLUGIN_NAME,
        PLUGIN_STATUS,
        plugin_library,
        load_option
    FROM
        INFORMATION_SCHEMA.PLUGINS
    WHERE
        plugin_library in ('semisync_master.so', 'semisync_slave.so');
    
    show plugins;
    
    # 2. 配置文件增加以下参数:
    # 半同步复制
    plugin-load="rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
    rpl_semi_sync_slave_enabled=on
    rpl_semi_sync_master_enabled=on
    
    

    2) 从库启动复制线程

    -- 重启从库IO线程,启动半同步复制
    stop slave io_thread;
    start slave io_thread;
    
    

    3)检查复制状态

    -- master查看半同步是否正常工作
    show global status like 'Rpl_semi_sync_%';

    clipboard

    4. 基于GTID复制

    GTID(Global Transaction ID),是一个已提交事务的编号,并且是一个全局唯一编号。GTID由server_uuid和事务id组成。server_uuid是在服务启动中自动生成(datadir/auto.cnf),而事务ID就是事务提交时有系统顺序分配的一个不重复的序列号。

    GTID意义
         1) GTID使用master_auto_position=1替代基于binlog和position号的主从复制方式,便于主从复制搭建;
         2) 通过UUID可以知道这个事务在哪个实例上提交
         3) 通过GTID可以极方便的进行复制结构上的故障转移,新主设置,再也不用不断地去找position和binlog

    工作原理:
         1) master更新数据时,会在事务前产生GTID,一同记录到binlog日志中。
         2) slave端的I/O线程将变更的binlog,写入到本地的relay log中。
         3) sql线程从relay log中获取GTID,然后对比slave端的binlog是否有记录。
         4) 如果有记录,说明该GTID的事务已经执行,slave会忽略。
         5) 如果没有记录,slave就会从relay log中执行该GTID的事务,并记录到binlog。
         6) 在解析过程中会判断是否有主键,如果没有就用二级索引,如果没有就用全部扫描


    GTID 使用中的限制条件
         1) 不能使用 create table tb2 as select * from tb1;
         2) 在一个事务中既包含事务表的操作又包含非事务表的操作;
         3) 不支持create temporary table or drop temporary table语句操作;
         4)使用GTID复制,从库跳过错误时,不支持执行sql_slave_skip_counter参数的语法

    4.1 实验环境搭建

    1)参数配置

    -- master
    gtid_mode=on
    enforce_gtid_consistency=on
    # bin-log configuration
    binlog_format               = ROW
    log_bin                     = /ups/data/mydata/binlogs/m3308
    max_binlog_size             = 1024M
    log_slave_updates           = ON
    expire_logs_days            = 3
    max_binlog_size             = 100m
    sync_binlog=1
    server_id = 3308001
    master_info_repository=TABLE
    relay_log_info_repository=TABLE
    
    -- slave 确认好 server_id 不能一样
    gtid_mode=on
    enforce_gtid_consistency=on
    
    # bin-log configuration
    binlog_format               = ROW
    log_bin                     = /ups/data/mydata/binlogs/s3309
    max_binlog_size             = 1024M
    log_slave_updates           = ON
    expire_logs_days            = 3
    max_binlog_size             = 100m
    sync_binlog=1
    server_id = 3309002
    relay_log = /ups/data/mydata/binlogs/r3309
    master_info_repository=TABLE
    relay_log_info_repository=TABLE

    2)启动复制线程

    # 在从库执行配置主从命令
    
    CHANGE MASTER TO
    MASTER_HOST='192.168.10.181',
    MASTER_USER='sync',
    MASTER_PASSWORD='sync',
    MASTER_PORT=3308,
    master_auto_position=1;

    clipboard

    4.2 GTID复制与Position复制切换

    1)GTID 切换 POS [mysql 5.7.6 gtid_mod支持动态修改]

    -- 1) 从库关闭主从复制并调整为传统复制
    stop slave;
    CHANGE MASTER TO
    master_auto_position=0,
    MASTER_HOST='192.168.10.181',
    MASTER_USER='sync',
    MASTER_PASSWORD='sync',
    MASTER_PORT=3308,
    MASTER_LOG_FILE='b3308.000014',
    MASTER_LOG_POS=852;
    start slave;
    
    -- 2) 主从服务器同时调整 GTID 模式为 on_permissive
    set global gtid_mode = on_permissive;
    -- 3) 主从服务器同时调整 GTID 模式为 off_permissive
    set global gtid_mode = off_permissive;
    -- 4)主从服务器同时调整 GTID 模式为 off
    set global gtid_mode = off;
    -- 5) 将 gtid_mode = off 和 enforce_gtid_consistency=off 写入配置文件my.cnf

    2)POSITION 切换到 GTID

    -- 1) 主从数据库上同时修改 enforce_gtid_consistency=warn ,确保errlog 不出现告警信息
    set global enforce_gtid_consistency=warn;
    -- 2) 主从数据库上同时修改 enforce_gtid_consistency=on ,确保GTID的一致性
    set global enforce_gtid_consistency=on;
    -- 3) 主从服务器同时调整 GTID 模式为 off_permissive
    set global gtid_mode = off_permissive;
    -- 4) 主从服务器同时调整 GTID 模式为 on_permissive
    set global gtid_mode = on_permissive;
    -- 5) 确认从的 Ongoing_anonymous_transaction_count 参数为0,(0意味着没有等待的事务)
    show global status like 'Ongoing_anonymous_transaction_count';
    -- 6) 主从服务器同时调整 GTID 模式为 on
    set global gtid_mode = on;
    -- 7) 查看当前配置
    show variables like '%gtid%';
    
    -- 8) 将传统复制模式改为GTID模式 -- slave
    stop slave;
    show slave statusG
    change master to master_auto_position = 1;
    or
    CHANGE MASTER TO
    MASTER_HOST='192.168.10.181',
    MASTER_USER='sync',
    MASTER_PASSWORD='sync',
    MASTER_PORT=3308,
    master_auto_position=1;
    start slave;

    5. 修改同步账号密码

    CHANGE MASTER TO MASTER_USER='sync', MASTER_PASSWORD='new passwd';

    6. 数据校验工具

    安装percona-toolkit工具包进行主从数据校验检查

    -- 主库执行命令
    [root@progs bin]# pwd
    /ups/app/mysql/percona-toolkit/bin
    [root@progs bin]# ./pt-table-checksum --help
    pt-table-checksum performs an online replication consistency check by executing
    checksum queries on the master, which produces different results on replicas
    that are inconsistent with the master.  The optional DSN specifies the master
    host.  The tool's L<"EXIT STATUS"> is non-zero if any differences are found, or
    if any warnings or errors occur.  For more details, please use the --help
    option, or try 'perldoc ./pt-table-checksum' for complete documentation.
    
    Usage: pt-table-checksum [OPTIONS] [DSN]
    
    Options:
    
      --binary-index                   This option modifies the behavior of --
                                       create-replicate-table such that the
                                       replicate table's upper and lower boundary
                                       columns are created with the BLOB data type
      --channel=s                      Channel name used when connected to a server
                                       using replication channels
      --[no]check-binlog-format        Check that the binlog_format is the same on
                                       all servers (default yes)
      --[no]check-plan                 Check query execution plans for safety (

  • 相关阅读:
    luogu P1486 [NOI2004]郁闷的出纳员
    Luogu P1894 [USACO4.2]The Perfect Stall
    关于中间6个月停更通知
    Luogu P1381油滴扩展
    没有上司的舞会(题解)
    幂的模运算(题解)
    闭合区域面积统计(题解)
    字符序列(题解)
    最大连续和(题解)
    排列问题
  • 原文地址:https://www.cnblogs.com/binliubiao/p/12594278.html
Copyright © 2011-2022 走看看