• 主从复制 日常管理与维护


    =====MySQL 主从复制====

    一.异步复制:
    1.环境准备:
    主库:开启binlog 关闭iptable
    从库:开启binlog 关闭iptable 并且没有用户数据
    主从库server_ID 不同
    port 不同
    2.进入主库:
    在主库上创建用户并授权给从库使用:
    grant replication slave on *.* to'xiaozou'@'192.168.1.250'identified by 'xiaoqun';

    查询主数据库状态,并记下FILE及Position的值,这个在后面配置从服务器的时候要用到。
    show master status;

    3.进入从库:
    change master to
    master_host='192.168.1.178', =====> 主库ip
    master_port=3311, =====> 主库端口
    master_user='backup', =====> 用户名
    master_password='backup', =====> 密码
    master_log_file='mysql-bin.000012',====> binlog file 值
    master_log_pos=120; =====> position 值


    start slave; =========> 启动slave 同步主库;

    mysql> show slave statusG
    =================>
    检查主从同步,如果您看到Slave_IO_Running和Slave_SQL_Running均为Yes,则主从复制连接正常。



    报错: Last_IO_Error: Got fatal error 1236 from master
    when reading data from binary log: 'Slave can not handle replication events
    with the checksum that master is configured to log;
    the first event 'mysql-bin.000016' at 862,
    the last event read from './mysql-bin.000016' at 862,
    the last byte read from './mysql-bin.000016' at 120.'

    解决: 自己手动删除了 除了mysql-bin.index, 的binlog日志 导致 mysql 无法启动
    后面将mysql-bin.index 也删除了 mysql正常启动

    二:半同步复制

    在主从复制搭建成功的基础上:
    select * from mysql.plugin ; 在主从库 上看有没有安装插件;没有就安装插件

    在主库上安装插件 semisync_master.so : install plugin rpl_semi_sync_master SONAME 'semisync_master.so';

    在从库上安装插件 semisync_slave.so : install_plugin rpl_semi_sync_slave SONAME 'semisync_slave.so';

    在主库上设置参数: set global rpl_semi_sync_master_enabled=1; (1是打开半复制) ;
    在从库上设置参数: set global rpl_semi_sync_slave_enabled=1;
    在从库上设置参数之后要重启IO_THREAD

    测试半同步复制是否成功:
    在主库上:show status like '%semi_sync%';
    看rpl_semi_sync_master_status 是否为 ON ON 是半同步状态开启;
    看rpl_semi_sync_master_yes_tx 值为0 表示主库上目前有0个事务是通过半同步复制到从库上面的;
    看rpl_semi_sync_master_no_tx 值为几 表示主库上目前有几个事务不是通过半同步复制到从库上面的;
    实践测试:
    在主库上执行一个事务 然后查看yes_tx 值有没有变成之前值加一



    三:主要复制启动选项:
    1.如果从库要作为其他服务器的主库则需要打开从库上的--log-slave-updates 用来控制从库上的更新操作是否写入二进制日志中
    经常和参数--log-bin 一起使用
    2.master-connect-retry 这个参数控制主从库的链接丢失之后的重试的时间 默认为60s
    3.read-only 用该参数启动数据库时,数据库只接受超级用户的更新操作;

    4.replicate-do-db、replicate-do-table、replicate-ignore-db、replicate-ignore-table 用这些参数启动从数据库可以指定从主数据库复制到从数据库的表

    5.参数--slave-skip-error=err_code1,err_code2.../all
    上面的参数是控制从数据库在复制过程中遇到binlog 中的错误SQL时能够直接跳过这条SQL语句 大大减少了人工的干预;







    ============日常管理与维护==============
    1.检查从库的复制状态: show slave status;
    主要看 slave_io_running 和slave_sql_running 这俩条是否为yes
    前者是表示 此进程负责从库(slave)从主库(master)上读取的binlog日志并写入从库的中继日志(relay_log)中去
    后者是表示 此进程是负责slave 读取relay-log中的日志并执行;

    2.主从库的同步维护: 如果时间长了主从库的差距较大 这时需要手动同步主从数据库:
    1> 在主库上FLUSH TABLES WITH READ LOCK; (会阻塞主数据库上的所有的更新的操作)
    2> 在主库上show master status;
    记录输入的日志名和偏移量;
    3> 在从库上执行下面的sql语句:
    select master_pos_wait('mysql-bin.000004','234');
    查看反馈值:返回0 表示同步成功;返回-1表示超时退出;
    4> 在主库上执行 UNLOCK TABLES; 解锁##!!!重要

    3.从库复制出错的处理:
    1> 从库复制出错时 手动跳过出错的事务 之后手动同步:
    stop slave;
    set global sql_slave_skip_counter = 1/2 ;
    如果来自主库的更新语句不使用AUTO_INCREMENT或者
    不使用LAST_INSERT_ID()时 则后面为1.否则是2 ;
    ###详情见《深入浅出的mysql》p566
    2> 从库上恢复时如果出现‘log event entry exceeded max_allowed_packet’ 报错 ;表示有大文本记录无法通过网络5进行传输,
    这时需要在主从库上增加max_allowed_packet的参数的大小(默认为1MB
      SET @@global.max_allowed_packet=16777216;设置为16M
    在my.cnf中设置max_allowed_packet=16M 保证下次数据库启动参数依据生效)
    3> 多主一从的复制构架


    4.查看从库的复制进度:1> 在从库上show processlist G 看 time值 time 值单位为秒 表示复制上一条主库的操作是多少秒之前的更新

    如有错误,望费心指出。 感激涕零。
  • 相关阅读:
    跟我一起了解koa(四)
    快速定位隐蔽的sql性能问题及调优【转载】
    PV,UV,IP
    ActiveMQ的安全机制使用及其源代码分析 [转]
    ActiveMQ中的安全机制 [转]
    ESB、SOA、EAI异同【转】
    磁盘 I/O 性能监控指标和调优方法
    PLS-00306:错误解决思路
    浅谈PetShop之使用存储过程与PLSQL批量处理(附案例)
    关于SQLSQL Server的三值逻辑简析
  • 原文地址:https://www.cnblogs.com/zouxiaopq/p/6286257.html
Copyright © 2020-2023  润新知