MySql主从复制简单案例实现

mysql的主从复制原理

在mysql主从复制架构中,有一台服务器作为MASTER服务器,该服务器负责所有的读请求和写请求。另外一台或多台作为slave服务器。当master上的某个应用程序发起写请求时,该请求会被内核响应并在内核中执行,然后在将其数据写入到磁盘中去。并且将此次的操作以事件的形式记录到二进制文件中去。此时master上的Binlog  dump thread等待slave上的I/O thread连接请求。一旦slave I/O thread连接上了master的Binlog dump thread,则Binlog dump thread会将本地二进制文件中更新的事件复制给slave。当slave上的I/O thread接受从master复制过来的二进制文件中的事件时,会将其事件写入到slave上的中继日志文件中。然后slave会调用本地的SQL thread重新应用(或回放)中继日志中的事件,然后在将其数据写入到slave上的磁盘中。这就是mysql的主从复制功能。

由于slave上更新的数据不能复制给master,因此,对于slave而言,不能执行写操作。

mysql的三中复制模式:

1)异步模式(mysql默认复制模式)、半同步和同步复制模式。(这里用到的是异步复制模式)


mysql主从复制具有以下功能:

1、实现mysql数据库的高可用性

2、可以辅助实现数据备份

3、可以异地容灾

4、实现服务器分摊负载,即通过mysql的读写分离来实现分摊负载。(这里只是简单的主从复制)

主从复制实现如下图所示:

上图原理说明:

1.Binlog dump thread:接受slave  I/O thread的连接请求,并将master上的二进制文件中更新的事件复制给slave I/O thread。

2.slave I/O thread:接受Binlog dump thread复制过来的时间,并将其写入到slave上的中继日志文件中。

3.slave SQL thread:读取中继日志文件中的事件重新应用(或回放),并将其数据写入到磁盘中去。

mysql的主从复制需要注意的事项:

一个master可以用于多个slave,而一个slave只能属于某一个master,在主从架构中,如果只有一个slave,那么在slave上重新回放中继日志文件中的事件会引起数据库的改变,因此,这个过程也会以事件的形式写入到二进制日志文件中去。由于二进制日志是用来做及时点还原的,且master保存着一份完整的数据,因此在slave上不需要开启二进制日志功能,但是master上必须要开启。如果有多个slave的情况下,在这多个slave中,有一个slave即当做master的slave又可以当做其他slave的master,那么此时这个slave上必须开启二进制日志功能。即此时这个slave即充当slave又充当master。

下面开始配置:

1.实验环境:

我用的是2台Centos 6.5x86_64

IP地址分别为:

master.fpj.com   192.168.3.85

slave.fpj.com    192.168.3.86

mysql的安装我这里就不说了,可以用编译安装,也可以yum直接安装,我这边用yum直接安装,版本是mysql-5.1.73(里面修改的datadir目录这里就不写出来了)。

2.配置主mysql服务

1)启用二进制日志

2)定义serverID

3)创建具有复制权限的帐号

3.配置从mysql服务

1.关闭二进制日志,启动中继日志

2.定义server-id

3.使用有复制权限的帐号连接Master服务器

4.启动I/O线程和sql线程

这里我直接start slave;直接启动I/O,SQL线程,也可以一个个启动;

下面就来查看下从服务器的状态:

4.我就来测试下master服务上新建一个fpjtest数据库:

最后去从服务器上看看 fpjtest有没有同步过来:

看上图已经同步过来了,说明mysql主从复制已经实现。

时间: 2024-10-20 01:31:31

MySql主从复制简单案例实现的相关文章

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_Mast

不停应用服务,在线建立或重做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主从复制-故障案例一

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.备库读取自身的中继日志中的事

mysql主从复制概述以及配置mysql5.7.10实现简单主从复制

什么是主从复制: 通过将Mysql的某一台主机的 数据复制到其它主机,复制过程中一个服务器充当主服务器(master),而一个或多个其它服务器充当从服务器(slave).进行复制时,所有对数据表的写操作必须在主服务器上进行.否则,因为主服务器不会同步从服务器的数据,会导致主从数据不一致的问题.mysql的主从复制功能是构建高性能大型应用服务器的基础 主从复制的作用: 1.辅助实现数据的备份 2.实现数据服务的高可用和异地容灾 3.实现多个服务器分摊负载 主从复制的实现原理: 实现整个复制过程主要

安卓版php服务器的mysql数据库增删改查简单案例

index.php文件: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html

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

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