【Mysql】mysql公开课之-mysql5.7复制特性

GTID的基础知识

  1. BEGIN;
    INSERT INTO innodb_tbl(…);
    INSERT INTO myisam_tbl(…);
    COMMIT;

  • 在事务中使用临时表
  • BEGIN;
    INSERT INTO innodb_tbl(…);
    CREATE TEMPORARY TABLE temp1;
    ...
    COMMIT;



  • 小技巧
    1. 启用GTID前,检测系统中是否有GTID不支持的语句/事务,提前处理。
       全局系统变量enforce-gtid-consistency
       OFF 不检测是否有GTID不支持的语句/事务
       WARN 当发现不支持的语句/事务时,返回警告,并在日志中记录警告信息。
       ON 当发现语句/事务不支持GTID时,返回错误。                     ----所以上面报错了
       在线上的数据库服务器或测试环境中,开启WARN模式。
    2. +---------+------+---------------------------------------------------------------+
      | Level | Code | Message |
      +---------+------+---------------------------------------------------------------+
      | Warning | 1786 | Statement violates GTID consistency: CREATE TABLE ... SELECT. |
      +---------+------+---------------------------------------------------------------+
      2016-07-11T10:48:34.627976Z 2 [Warning] Statement violates GTID consistency: CREATE TABLE ... SELECT.

      处理完GTID不支持的语句后,再启用GTID。

    在线升级h为gtid可以参考这篇文章
    1. 连接:
    2. http://blog.itpub.net/29096438/viewspace-2060975/



    MySQL5.7多线程并发复制
    1. 基本搭建过程可参如下文档:
    2. http://www.innomysql.com/article/16317.html
    3. http://www.innomysql.com/inNOSQLmysql并行复制的实现与配置/

    4. mysql5.6多线程复制:基于datababase/schema的
    5. mysql5.7多线程复制:继承5.6的同时,基于事务执行的逻辑时钟(Logical Clock)的并发(5.7以来)

    6. 具体区别如下:
       两种类型的并发
         基于库(Database/Schema)的并发(5.6以来)
           Binlog中记录语句使用的所有的库的名字。
           不同库上的事务可以并发执行,同库的事务顺序执行。
         基于事务执行的逻辑时钟(Logical Clock)的并发(5.7以来)。
           Binlog中记录事务执行时的相对顺序信息。
           基本原理是锁的冲突检测,因此也叫基于锁的并发机制。


      基于锁的并发复制的原理
      待续。。。。



    7. 在线快速切换为并发复制:
      1. mysql> STOP SLAVE SQL_THREAD;
      2. mysql> SET GLOBAL slave_parallel_workers = 8; #并发线程数量
      3. mysql> SET GLOBAL slave_parallel_type = “ LOGICAL_CLOCK” ; #or DATABASE      
      4. mysql> START SLAVE SQL_THREAD
       注意:如果主5.6 从5.7使用LOGICAL_CLOCK的模式可能会出现如下类型错误
      1. Last_Errno: 1756

      2. Last_Error: … The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details).
      3. 参考文档:http://imysql.com/2016/06/02/mysql-faq-5-6-to-5-7-replicaton-failure.shtml




    MySQL-5.7的半同步复制

    1. 先了解一下什么是半同步,什么是同步,什么是异步

    2. 同步复制:  直到所有的slave都commit了事务之后,此时才返回信息给客户端;缺点:完成一个事务的延迟可能很大

    3. 半同步复制:
    4.            5.7无损半同步:master在收到slave的应答之后才commit事务    更多详细信息可参考文档:http://mp.weixin.qq.com/s?__biz=MzIwNzEzNDkxNQ==&mid=400915320&idx=1&sn=58dcc499cbcedcd827002acd77c30d60&scene=4#wechat_redirect
    5.            5.6半同步:master在commit之后才等待salve的应答

    6. 异步复制:  Master将事件写入binlog,但并不知道Slave是否或何时已经接收且已处理。在异步复制的机制的情况下,如果Master宕机,事务在Master上已提交,但很可能这些事务没有传到任何的Slave上。假设有Master->Salve故障转移的机制,此时Slave也可能会丢失事务




    网页名称:【Mysql】mysql公开课之-mysql5.7复制特性
    转载来于:http://scyanting.com/article/jhgdos.html

    其他资讯