mysql主从同步不一致后的解决方法

查看master的运行情况:

[[email protected]] mysql -uroot -p************
[[email protected]] mysql> show master status \G;
    *************************** 1. row ***************************
             File: mysql-bin.000014     //这个信息点要记住,下面用
         Position: 170017372            //这个信息点要记住,下面用
         Binlog_Do_DB: ipharmacare_admin
     Binlog_Ignore_DB: mysql,information_schema,performance_schema
    Executed_Gtid_Set:
    1 row in set (0.00 sec)

查看slave的运行情况:

[[email protected]] mysql -uroot -p************
[[email protected]] mysql> show slave status \G;
    *************************** 1. row ***************************
               Slave_IO_State:
              Master_Host: master.mysql.ipharmacare.org
              Master_User: slave
              Master_Port: 3306
            Connect_Retry: 60
              Master_Log_File: mysql-bin.000013
          Read_Master_Log_Pos: 1003623481
               Relay_Log_File: mysql-bin.000022
            Relay_Log_Pos: 36726417
        Relay_Master_Log_File: mysql-bin.000013
             Slave_IO_Running: No
            Slave_SQL_Running: No
              Replicate_Do_DB: ipharmacare_admin
          Replicate_Ignore_DB: mysql,information_schema,performance_schema
           Replicate_Do_Table:
           Replicate_Ignore_Table: ipharmacare_admin.tb_hospital,ipharmacare_admin.t_customer,ipharmacare_admin.t_license,ipharmacare_admin.tb_hospital_zone_license,ipharmacare_admin.tb_hospital_license
          Replicate_Wild_Do_Table: ipharmacare_admin.%
      Replicate_Wild_Ignore_Table:
               Last_Errno: 0
               Last_Error:
             Skip_Counter: 0
          Exec_Master_Log_Pos: 1003623481
              Relay_Log_Space: 1003624042
              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: 0
            Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
      Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
              Master_UUID: a8ddc479-8862-11e2-b6df-2761731e3dd6
             Master_Info_File: /mnt/mysql/master.info
                SQL_Delay: 0
          SQL_Remaining_Delay: NULL
          Slave_SQL_Running_State:
           Master_Retry_Count: 86400
              Master_Bind:
          Last_IO_Error_Timestamp:
         Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
            Auto_Position: 0
         Replicate_Rewrite_DB:
             Channel_Name:
           Master_TLS_Version:
    1 row in set (0.00 sec)

结论:由上可知数据同步延迟很多,且希望重新做主从,使得主从在数据上保持完全同步.

先进入主库,进行锁表,防止数据写入

[[email protected]] mysql> flush tables with read lock;

进行master数据备份

[[email protected]] cd /mnt/mysql/bakdata
[[email protected]] mkdir baksql
[[email protected]] cd baksql
[[email protected]] mysqldump ipharmacare_admin -uroot -p****** --opt> ipharmacare_admin.sql
或者:
mysqldump -uroot -p***** --default-character-set=utf8 ipharmacare_admin  > ipharmacare_admin.sql

打包数据(可选)

[[email protected]] 7za a ipharmacare_admin_20160505.7z ipharmacare_admin.sql

把mysql备份文件传到从库机器,进行数据恢复

[[email protected]] cd /usr/downloads/
[[email protected]] scp [email protected]:/mnt/mysql/bakdata/ipharmacare_admin_20160505.7z ./
[[email protected]] 7az x ipharmacare_admin_20160505.7z
[[email protected]] mysql -uroot -p*****;
[[email protected]] mysql> drop database ipharmacare_admin;
[[email protected]] mysql> CREATE DATABASE ipharmacare_admin DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
[[email protected]] msyql> source baksql.sql;

更新/设置同步进度点

 [[email protected]] change master to master_host=‘master.mysql.ipharmacare.org‘, master_user=‘slave‘, master_port=3306, master_password=‘************‘, master_log_file=‘mysql-bin.000014‘, master_log_pos=170017372;

注意:

1) 做了MySQL主从复制以后,使用mysqldump对数据备份时,一定要注意按照如下方式:
  [[email protected]] mysqldump –master-data –single-transaction –user=username –password=password dbname> dumpfilename
这样就可以保留file和position的信息,在新搭建一个slave的时候,还原完数据库,file和position的信息也随之更新,接着再start slave 就可以很迅速的完成增量同步。
2) 忘记主从复制时,对从库用户密码时,可以这样去重置:
  [[email protected]] GRANT REPLICATION SLAVE ON *.* TO ‘slave‘@‘slave.mysql.ipharmacare.org‘ IDENTIFIED BY ‘slave‘;
时间: 2024-11-10 11:42:21

mysql主从同步不一致后的解决方法的相关文章

mysql 主从数据不一致 Slave_SQL_Running: No 解决方法

在slave服务器上通过如下命令 mysql> show slave status\G; 显示如下情况: Slave_IO_Running: Yes Slave_SQL_Running: No 表示slave不同步 解决方法一(忽略错误,继续同步): 1.先停掉slave mysql> stop slave; 2.跳过错误步数,后面步数可变 mysql> set global sql_slave_skip_counter=1; 3.再启动slave mysql> start sla

mysql主从同步延迟原因及解决方法

MySQL主从延迟原因以及解决方案:谈到MySQL数据库主从同步延迟原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作(mysql5.6版本之前),主库对所有DDL和DML产生binlog,binlog是顺序写,所以效率很高. slave的Slave_IO_Running线程会到主库取日志,效率会比较高,slave的Slave_SQL_Running线程将主库的DDL和DML操作都在slave实施.DML和DDL的IO操作是随机的,不是顺序的,因此成本会很高,还可

MySQL主从同步延迟原因及解决办法

MySQL主从延迟原因以及解决方案:谈到MySQL数据库主从同步延迟原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作(mysql5.6版本之前),主库对所有DDL和DML产生binlog,binlog是顺序写,所以效率很高. slave的Slave_IO_Running线程会到主库取日志,效率会比较高,slave的Slave_SQL_Running线程将主库的DDL和DML操作都在slave实施.DML和DDL的IO操作是随机的,不是顺序的,因此成本会很高,还可

一次由于字符集问题引发的MySQL主从同步不一致问题追查

近期业务准备上线一个新功能,灌入数据之后突然发现主从同步停止,报错如下: Error 'Duplicate entry '66310984-2014-04-18 00:00:00--122815.sh' for key 'PRIMARY'' on query. Default database: 'bill'. Query: 'INSERT INTOBOND3311(OBJECTID,BONDID,BONDNAME,DECLAREDATE,F001D,F002D,F003N,F004N,F005

mysql主从同步常见异常及恢复方法

1. 一般的异常只需要跳过一步即可恢复 >slave stop; >SET GLOBAL sql_slave_skip_counter = 1; >slave start; 2.断电导致主从不能同步时,通主库的最后一个bin-log日志进行恢复 在主库服务器上,mysqlbinlog mysql-bin.xxxx > binxxxx.txt tail -n 100000  binxxxx.txt > tail-binxxxx.txt vim tail-binxxxx.txt

《Mycat学习笔记》 第三篇. MySql 主从同步异常后,主从切换

1)系统环境说明 MySql 5.5 主从节点 127.0.0.1:3306   主结点,为验证主从切换效果,手动停止服务 127.0.0.1: 3307    从结点 1 127.0.0.1:338     从结点 2 ,为验证主从切换效果,在主结点停止后,新增两个记录. MyCat 1.5 schema.xml 配置 具体配置说明,参考上篇: <Mycat学习笔记> 第二篇. MySql 读写分离与日志分析——主从多结点 <dataHost name="localhost1

mysql 主从同步失败后

环境: centos6.4 mysql5.1 主:mysql1 从:mysql2 在mysql1上: 1.1.先锁表,避免在重新设置同步的这段时间内有新的数据写入. flush tables with read lock; 1.2.备份数据库 mysqldump -u root -p data1 > data1.sql 1.3. 把备份的数据库传到mysql2上去 1.4.删除原来的日志文件 cd /var/lib/mysql mv master-bin-0000* /backup    //移

mysql主从数据库不同步的3种解决方法

mysql主从数据库不同步的3种解决方法 今天发现Mysql的主从数据库没有同步 先上Master库: mysql>show processlist; 查看下进程是否Sleep太多.发现很正常. show master status; 也正常. mysql> show master status; +-------------------+----------+--------------+-------------------------------+ | File | Position |

如何实现 MySQL 的读写分离?MySQL 主从复制原理的是啥?如何解决 MySQL 主从同步的延时问题?

高并发这个阶段,肯定是需要做读写分离的,啥意思?因为实际上大部分的互联网公司,一些网站,或者是 app,其实都是读多写少.所以针对这个情况,就是写一个主库,但是主库挂多个从库,然后从多个从库来读,那不就可以支撑更高的读并发压力了吗? 如何实现 MySQL 的读写分离? 其实很简单,就是基于主从复制架构,简单来说,就搞一个主库,挂多个从库,然后我们就单单只是写主库,然后主库会自动把数据给同步到从库上去. MySQL 主从复制原理的是啥? 主库将变更写入 binlog 日志,然后从库连接到主库之后,