mysqlbinlog  mysql-bin.000082  |more

                mysql>unlock tables;

可经过上边语句查看binlog的pos音讯和日志内容
mysql> show binlog events in  ‘mysql-bin.000081’ from 480140557 limit
10;       
Empty set (0.04 sec)
3.改动从库的一齐地点,实现数据再一次联合

   Master IP: 192.168.1。106
     Slave IP: 192.168.1。110
        在Master和Slave上安装Mysql
3》
Master(主)操作

 主库:

  1.景观描述:
    A 服务器(Master)
    B 服务器(Slave)
  在A 服务器上创办多少个库叫做aatest
  在B 服务器上查看是或不是同步,

刚处理完“挖矿”事件,在做最终七个MySQL
NBU备份的时候,开采从库相当,好奇的是怎么主从状态十二分未有报告急察方呢?先不管这么多了,处理了那一个标题再通盘告急内容。

***           排错:
    如果show slave
status\G;报错是因为未有找到正确的端口号,则足以在此个一向抬高定义
    master_port=3306,

此中–recursion-method有三种格局查看从库音信,这里运用的是hosts情势,需求在从库参预如下参数,方可在主库施行show
slave hosts查看从库的音信

**     4.3、步骤3:
    在备库上实施:
    mysql> select @@GTID_NEXT 先查询GTID_NEXT 的值
    mysql> STOP SLAVE; 先截止掉SLAVE
    Query OK, 0 rows affected (0.00 sec)
    mysql> SET @@SESSION.GTID_NEXT=
’59ebdf10-63c8-11e6-9d86-000c2916dc3f:32‘;将步骤2复制的粘附运营,
    Query OK, 0 rows affected (0.00 sec)
    mysql> BEGIN; COMMIT; 给叁个空的事务,然后在付出。
    Query OK, 0 rows affected (0.00 sec)
    Query OK, 0 rows affected (0.00 sec)
    mysql> SET SESSION GTID_NEXT = AUTOMATIC;
重新苏醒设置自动提交业务GTID。
    Query OK, 0 rows affected (0.00 sec)

 

  检查从服务器复制作用状态:***

基本同步不奇怪

                图片 1

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: xx.xx.xx.xx
                  Master_User: username
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000081
          Read_Master_Log_Pos: 480141113
               Relay_Log_File: mysql9017-relay-bin.000163
                Relay_Log_Pos: 480141259
        Relay_Master_Log_File: mysql-bin.000081
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 480141113
              Relay_Log_Space: 480141462
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin.000081' at 480141113, the last event read from './mysql-bin.000081' at 4, the last byte read from './mysql-bin.000081' at 4.'
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 17
1 row in set (0.00 sec)

*** *4.通过GTID的点子跳过事情,获得消除。**

1.反省从库状态以至读取、推行的binlog消息

                 图片 2

从库show slave status \G看见的错误音讯如下:

    # : vim /etc/my.cnf
    #log_slave_updates 注释掉这行
    server-id=1 将id号改为1
    #mysql –uroot –p –h localhost
    mysql>grant replication slave on \
.* to
‘admin’@’192.168.1.106’ identified by ‘123456’;
#给13slave实行授权复制
    mysql>flush tables with read lock;
    mysql>show master status;*

mysql> show global variables like '%sync_binlog%';                       
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| sync_binlog   | 0     |
+---------------+-------+
1 row in set (0.00 sec)

变动配置文件my.cnf设置sync_binlog=1

    mysql> START SLAVE;
    再查看show slave
status,就能够开采错误事务已经被跳过了。这种办法的法则超粗略,空事务产生的GTID参加到GTID_EXECUTED中,这一定于告诉
               备库,这一个GTID对应的事务已经管理了;**

6.innodb_flush_log_at_trx_commit参数扩大

***  1>通常的至极只要求跳过一步就能够恢复生机
      
 模拟故障,创制主从复制从前.在主上创造一个CC库,在开启主从复制,从的IO皆以为YES后,在主上创立三个gongda库,看看从库是还是不是同步成功?
   
 固然成功,接下去模拟故障.在主上校CC删除掉.在从看slave状态是还是不是就起来报错了??
  解决办法如下:
    > stop slave;
    >SET GLOBAL sql_slave_skip_counter = 1;
遇到错误直接跳过,继续回涨
    > start slave;

show slave status \G

6》漫不经心故障解决

观望主库binlog日志mysql-bin.000081最大的pos为480140557,但从库要读取的是’mysql-bin.000081′ at
480141113,分明从库要读的pos值比主库本身存在的pos值大,招致读取不到,进而退步。

**          (1)第三个是drop database aatest之上的:SET
@@SESSION.GTID_NEXT= ’59ebdf10-63c8-11e6-9d86-000c2916dc3f:31
     (2)第三个是drop database aatest之下的:SET @@SESSION.GTID_NEXT=
’59ebdf10-63c8-11e6-9d86-000c2916dc3f:32
            << 大家将第一个SET @@SESSION.GTID_NEXT=
’59ebdf10-63c8-11e6-9d86-000c2916dc3f:32 复制一下>>
    #160817 1:08:06 server id 1 end_log_pos 5484 CRC32 0x963858ea
GTID [commit=yes]

果然其值是 0,不积极同步binlog
cache的多少到磁盘,而依附于操作系统本身不定期把文件内容 flush 到磁盘。设为
1 最安全,在每种语句或工作后联手二遍 binary
log,即便在崩溃时也最多有失叁个口舌或业务的日记,但就此也最慢。这里安装为0,断电的情事下促成binlog
cache数据遗失未有写入主库的binlog,但binlog新闻已联合至从库。这种地方轻巧变成基本数据不相同等,所以就是复苏基本数据后,依旧要因此着力数据比较校验数据的生机勃勃致性。

    SET TIMESTAMP=1471367286/*!*/;
    drop database aatest
    /*!*/;
    # at 5565
    #160817 1:08:22 server id 1 end_log_pos 5613 CRC32 0x14d35459
GTID [commit=yes]
    SET @@SESSION.GTID_NEXT=
’59ebdf10-63c8-11e6-9d86-000c2916dc3f:32’/*!*/;

此处见到从库的io_thread已经终止,错误编号是1236,具体是由于读取主库的binlog日志地点(the first event ‘mysql-bin.000081’ at 480141113, the
last event read from ‘./mysql-bin.000081’ at
4卡塔 尔(英语:State of Qatar)不对招致基本战败创立失利。

     
  3>主键冲突、表已存在等错误代码如1062,1032,1060等,能够在mysql主配置文件内定
    略过此类卓殊并一连下条sql同步,那样也足以幸免过十大旨同步的极度中断
    [mysqld]
    slave-skip-errors = 1062,1032,1060

METHOD       USES
===========  =============================================
processlist  SHOW PROCESSLIST
hosts        SHOW SLAVE HOSTS
cluster      SHOW STATUS LIKE 'wsrep\_incoming\_addresses'
dsn=DSN      DSNs from a table
none         Do not find slaves

  检查从服务器复制作用状态:  排错:
    如果show slave
status\G;报错是因为未有找到科学的端口号,则能够在这里个一贯助长定义
    master_port=3306,

三、解决方案

                   
  注:Slave_IO及Slave_SQL进度必需平时运转,即YES状态,不然都以荒诞的情形(如:个中叁个NO均属不当)。

图片 3

  2.谬误场景描述起来:
    在B 服务器(Slave)将aatest删除掉.
    在A 服务器(Master)将aatest删除掉
  在个时候到B服务器使用show slave status\G;开采SQL 线程窒碍.***

Author

发表评论

电子邮件地址不会被公开。 必填项已用*标注