Mysql主从复制排错案例一

MYSQL主从复制排错案例一:

问题:主从无法同步
现象:MASTER: mysql> show master status;
              Empty set (0.00 sec)
      SLAVE:  mysql> show slave status \G;
              Slave_IO_Running: Connecting
              Slave_SQL_Running: Yes
              Seconds_Behind_Master: NULL
              Last_IO_Errno: 1045
              Last_IO_Error: error connecting to master ‘[email protected]:3306‘
              - retry-time: 60  retries: 86400
问题排查过程:

一 、 MASTER :[[email protected] ~]# egrep "log-bin|server" /etc/my.cnf 
                      # The MySQL server
                       server-id       = 1
                         #log-bin=mysql-bin    //没有开启
            SLAVE: [[email protected] ~]# egrep "log-bin|server" /etc/my.cnf
                          # The MySQL server
                           server-id       = 3
                           #log-bin=mysql-bin
 二、.开启MASTART log-bin日志,重新启动mysql数据库
                              MASTER: mysql> show master status;
                                mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |      107 |              |                  |
+------------------+----------+--------------+------------------+
                            SLAVE:     mysql> show slave status \G;
                             Slave_IO_Running: Connecting
                                 Slave_SQL_Running: Yes
   三、查看master.info 和relay-log.info信息

SLAVE:  [[email protected] data]# cat master.info 
                        18
                          mysql-bin.000001
                            348
                            192.168.254.253
                              rep
                             oldboy123
                              3306
                                60
                                 0
 
                             [[email protected] data]# cat relay-log.info 
                           ./localhost-relay-bin.000005
                             4
                              mysql-bin.000001
                                348
                              8

MASTER上的log-bin的POS点107,SLAVE上的log-bin的POS点348,两边不一致。
 四、. 在master.info中用户名为rep,在MASTER端没有找到该用户注册的信息。
                 mysql> select host,user from mysql.user;
 五、.重新注册用于同步的用户
                 grant replication slave on *.* to ‘rep‘@‘192.168.254.250‘ identified by ‘oldboy123‘;
 六、 在SLAVE重新注册CHANGE MASTER TO

mysql> CHANGE MASTER TO 
                     -> MASTER_HOST=‘192.168.254.253‘,
                      -> MASTER_PORT=3306,
                        -> MASTER_USER=‘rep‘,
                       -> MASTER_PASSWORD=‘oldboy123‘,
                        -> MASTER_LOG_FILE=‘mysql-bin.000002‘,
                         -> MASTER_LOG_POS=107;
                          mysql> start slave;

七、.mysql> show slave status \G;
                    Slave_IO_Running: Yes
                    Slave_SQL_Running: Yes
八、.测试:MASTER:  mysql> create database mama;
                          Query OK, 1 row affected (0.00 sec)
                     SLAVE: mysql> show databases;
                                         mama
问题:由于虚拟机测试环境,没有把MASTER数据库变为只读,备份主库。直接同步到从库,这样后果丢失数据。在出现问题之前创建新的数据库没有同步过来。 生产环境下要先备份主库。

时间: 2024-08-24 06:47:45

Mysql主从复制排错案例一的相关文章

MySql主从复制简单案例实现

mysql的主从复制原理 在mysql主从复制架构中,有一台服务器作为MASTER服务器,该服务器负责所有的读请求和写请求.另外一台或多台作为slave服务器.当master上的某个应用程序发起写请求时,该请求会被内核响应并在内核中执行,然后在将其数据写入到磁盘中去.并且将此次的操作以事件的形式记录到二进制文件中去.此时master上的Binlog  dump thread等待slave上的I/O thread连接请求.一旦slave I/O thread连接上了master的Binlog du

不停应用服务,在线建立或重做mysql主从复制的案例,包含一般模式和GTID模式

mysql主从嘛,绝大多数公司都有用到,GTID发展到现在也是越来越多人用,停止应用服务来做主从,略显low了,现在都流行在线做,不影响业务,多实际是吧,不啰嗦了,现在就来看看案例. 先说明,案例分两种方案,实现的意义是一样的,一种是mysqldump方式,一种是xtrabackup方式,视乎实际情况,因为有些业务不一定能用xtrabackup的. 先说mysqldump方式, 因为mysql自带,不需要再做些什么,比较方便易用,不过需要强调一下,数据量太大的话,mysqldump就略显不足了,

MySQL主从复制故障案例一

  案例一: 在M-S 一主一从 状态下,从库不小心写入,导致主从同步出现故障 故障模拟: in slave : 先创建一个数据库 crate database  buttongbu; in master 同样创建数据库, crate database  buttongbu; 此时在从库查看 in slave show slave status\G ,发现error出现,错误代码1007 解决方法: 方法一: stop slave; set global sql_slave_skip_count

MySQL主从复制故障案例二

案例二: 一主多从的架构下,主库master宕机 解决思路: 1,登录从库 show processlist: 查看两个线程的更新状态 结果说明: 之前主从同步正常 分别登录其余2个从库32,33查看: cat   /data/3306/data/master.info cat   /data/3307/data/master.info 比较,那个POS最大,说明更接近主库,那么我们就选举此slave作为新的master. 或者利用半同步技术,直接选举实时同步了的这个库为新的master 如果,

MySQL 主从复制排错

MySQL

mysql主从复制-故障案例一

1.从库上看到如下错误 mysql> show slave status\G; *************************** 1. row ***************************                Slave_IO_State: Waiting for master to send event                   Master_Host: 172.18.10.11                   Master_User: rep     

实现MySQL主从复制、双主模型的简单案例

写在前面:如果此文有幸被某位朋友看见并发现有错的地方,希望批评指正.如有不明白的地方,愿可一起探讨. MySQL复制的基本原理 MySQL复制解决的基本问题 让一台MySQL服务器的数据与其他MySQL服务器的数据保持同步. MySQL复制的工作原理 MySQL复制的工作原理图如下所示(图来自高性能MySQL第3版) MySQL主从复制的基本步骤: 1.启动主库上的二进制文件,并把数据更改记录到二进制日志中: 2.备库将主库上的二进制日志复制到自身的中继日志中: 3.备库读取自身的中继日志中的事

2-16 mysql主从复制

2-16 mysql主从复制 1. 部署MYSQL主从同步 <M-S> 环境:mysql版本一致,均为5.7.18 master xuegod4  ip  192.168.10.34   数据库密码 yourpasswd slave  xuegod5  ip  192.168.10.35   数据库密码 yourpasswd 1.1 配置主数据库xuegod4 1.1.1 创建需要同步的数据库: mysql> create database HA; mysql> use HA; m

【大型网站技术实践】初级篇:搭建MySQL主从复制经典架构 一、业务发展驱动数据发展

一.业务发展驱动数据发展 随着网站业务的不断发展,用户量的不断增加,数据量成倍地增长,数据库的访问量也呈线性地增长.特别是在用户访问高峰期间,并发访问量突然增大,数据库的负载压力也会增大,如果架构方案不够健壮,那么数据库服务器很有可能在高并发访问负载压力下宕机,造成数据访问服务的失效,从而导致网站的业务中断,给公司和用户造成双重损失.那么,有木有一种方案能够解决此问题,使得数据库不再因为负载压力过高而成为网站的瓶颈呢?答案肯定是有的. 目前,大部分的主流关系型数据库都提供了主从热备功能,通过配置