MySQL主从复制(一)

web一般是拒绝用户上传的,webdav可以实现数据上传

MySQL的扩展方式:

scale up:

scale out:

一、MySQL的扩展:

复制:每个node都有相同的数据集

从node请求主node的二进制日志,在本地进行重放实现

复制的作用:

数据分布:

负载均衡://读均衡,写操作不能负载均衡

数据备份://主node挂了,切换从为主 //冷备是最可靠的

高可用性能提升

可以写脚本实现故障转移。//mysql内部没有提供故障转移

MySQL升级测试:

【master】【slave】 //主从复制功能,主node必须启用二进制日志功能。

slave使用msyql协议请求master的二进制日志文件事件

master所有的写操作,除了在本地保存到数据库中,还会将写入[语句]保存到二进制日志

slave请求binary log的时候,可以指定位置,不指定的话

就从第一个文件的最开始,逐个发送给slave

从node收到master二进制日志后,保存到自己的中继日志中,记录读取到的位置[position]

master启动一个dump线程接受slave的请求,然后用dump线程响应客户端

slave留到中继日志中,然后在本地reply一次

二、复制相关线程:

主node:

主node的dump线程;为每个slave的I/O线程启动一个dump线程,用于向其发送binary log events

从node:

io thread:从node负责从master获取并保存到中级日志

sql thread: 读取并应用中级日志

从node需要保存binary log吗?

binary log:用于实现重放和恢复

但是一个slave可以其另外一个slave的master

//slave有自己的slave的话,该slave需要开启二进制日志

级联复制:

[master]--[slave]--[slave]

三、mysql复制的特点:

1.异步,主node并不需要等待从node返回写入结果

同步问题:一旦网络故障,master不能访问,将瘫痪

异步问题:通过slave未必能读到完整的数据

slave会落后于master的内容

好处:在master上操作失误,可以在slave上进行还原,slave切换为主

例如在master上误操作:drop tables

2.延迟:

master在二进制日志中写入的速度一定会慢于本地执行的速度

而slave获取二进制的速度也会慢于二进制日志的写入速度

本地执行>二进制日志>slave获取二进制日志

调度器/LB   //七层调度,能够识别sql语句的写和读操作,并且能够实现负载均衡

/   |\

[]   []   []

//调度器一般称为:r/w spliter :读写分离

从node不可避免的要落后于master,也可以把最新的请求,调度到master进行读

r/w spliter:检查状态

mysql的query cache:假如查询调度到同一个slave提高缓存命中率,但是损害LB效果

可以在[调度器/LB] + memcahed //

slave宕机:重新调度即可

master宕机:不能执行w操作。可以把一个slave提升为master

如何选取哪一个为主:

A:1,2,3

B:1,2,5

C:1,2,3,4

//选举哪一个呢?各有自己的

//恢复有很多问题,

在mysql 5.6之后,引入了gtid:全局事务id

在此之前tid都是本地的,无法判断哪一个slave完成的事务多

A要想成为master:从B获取5,从C获取4,然后自己成为master

//这种方案,不推荐,很难实现。需要结合gtid和oracle为mysql提供的大量的工具实现

其他方案:

corosync高可用mysql

[master][passive]   [slave][slave]

\ /

[共享存储]

//passive节点和master共享vip,故障转移即可

SAN:存储区域网络

passive和master可使用共享存储

但是共享存储:存在单点故障

drbd:分布式磁盘快识别,两个块设备实现跨主机同步

MySQL的内存和io消耗量比较大

硬件性能也非常好

到一定阶段就再扩展,性能可能不会上升,反而会下降

四、如何实现节点间数据同步 //scale out

方案一:共享存储

【LB】

/    \

[]     []

\   /

[  ] //共享存储,需要使用集群fs

//对数据施加锁,对于集群fs来说,他的扩展数量是有限的,到达4-8个,差不多到上线了

//该方案可看不可用

方案二:多个数据集

【LB】

/\

[][]

||

[][] //使用副本集,一个node rw,其他node只能读

//每一个node保存完整的数据副本,只有一个node接收w请求,其他节点都通过同步或者复制的机制事先复制。

双主模型:

A和B都即是主node也是对方的从node

[A][B]

[2][relay][file][2][relay][file]

//2:二进制日志

//A和B本地有数据文件、中继日志、二进制日志

通过serverid避免循环复制,根据serverid区分是自己传输给别人的。

A和B都能读和写

读请求被负载了,写请求虽然被LB了,但是实际还是需要A和B都写入

目的:冗余,不用做读写分离了,实现了HA

双主模型可能会导致数据不一致?

两个节点互为条件的,

tom 20岁

A:年龄>=20的工资翻倍

B:年龄大于20的,减去2岁,

那么最后怎么合并

MMM:双主模型解决方案

MHA:现在用的较多

percona:Galera-Cluster:在块级别实现复制 //较可靠的方案

mysql的主从复制:

1.异步复制

2.主从复制不一致比较常见

复制架构:

1.M/S

2.M/M

3.环状复制:每一个node都是上家的slave,又是下家的master

一主多从,一从再从:级联复制

一从只能有一个主

现在一从可以多主,可以从两个master复制不同的数据库

Mairadb 5.6 之后的版本,支持最后进行汇聚

主从

master需要接受w请求,并且启动n个线程,分发二进制日志给各slave

//master的压力依然有点大

如果master只需要复制一份二进制日志

级联可以实现

master->slave1-->[A,B] //slave1负责读和二进制日志分发

master->black hole引擎->[A,B] //black hole引擎所在node不存储数据,只负责分发二进制日志

二进制日志事件记录格式:

STATEMENT 基于语句的

ROW 基于行的,最好的方案,但是最占用空间

MIXED 混合模式,这种方案

演示的模型:

主从、主主、半同步复制(google)、复制过滤

半同步复制:

一主多从

master接受到请求后,至少等待一个从node同步完成,并告诉master数据已经存储ok,才会返回给client ok

//一个slave同步,其他异步:半同步模型

复制过滤:

主从复制架构中,主有10个库,但是从只想复制5个库

过滤器:可以在主node过略,也可以在slave实现

主:二进制日志记录的时候,只记录指定的库,因此从只能获取有限的二进制日志

从:浪费带宽,我只要5个,但是你给我发送10个

五、实现主从复制

192.168.100.67 master

192.168.100.68 slave

配置过程:

master:

1.启动二进制日志

2.为当前node设置一个全局唯一的id号

3.创建一个有复制 权限的用户账号

replication slave,replication client //权限

slave:

1.启动中继日志

2.位当前node设置一个全局唯一的id号

3.使用有复制权限的用户账号连接至master,并启动复制线程

master

vim my.cnf

[mysqld]

log-bin=mysql-bin   //注意log_bin和log-bin都可以使用,建议统一

server-id=1

innodb_file_per_table=ON

skip_name_resolve=ON

systemctl start mariadb.service

mysql> show global variables like ‘%log%‘

查看log_bin是否启用

mysql> show logs //查看二进制日志

mysql> show variables like ‘%server%‘

mysql> grant replication slave,replication client on *.* to ‘repluser‘@‘172.16.%.%‘ identified by ‘replpass‘;

注意卡其3306端口的防火墙

slave:

relay_log=reley_log

relay_log_index=relay-log.index

server-id=7 //

innodb_file_per_table=ON

skip_name_resolve=ON

systemctl start mariadb.service

mysql> show gloabl variables like ‘%log%‘;

rely_log = rely_log //日志开启

mysql> show global variables like ‘%server%‘;

change master to master_host=‘192.168.100.67‘,master_user=‘repouser‘,master_password=‘repopass‘,maser_log_file=‘master-bin.00003‘,master_log_pos=245;

master_user= //

master_host= //主机

master_port= //端口

master_password=

master_connect_retry= //多长时间重连一次,假如不能连接的话

master_log_pos= //复制的二进制日志的位置

master_heartbeat_period= //多长时间进行一次心跳检测

ignore_server_ids= //忽略哪些server id 的

show slave status //查看自己的状态

help start //启动复制线程

start slave; //默认启动sql_thread和io_thread

show slave staus ; //stop slave关闭线程

master:

crete database mydb;

show master status //查看二进制文件到哪一步了

slave:

show slave status;

//查看复制到哪里了

时间: 2024-10-10 12:26:08

MySQL主从复制(一)的相关文章

mysql主从复制与读写分离

MySQL主从复制与读写分离 MySQL主从复制(Master-Slave)与读写分离(MySQL-Proxy)实践 Mysql作为目前世界上使用最广泛的免费数据库,相信所有从事系统运维的工程师都一定接触过.但在实际的生产环境中,由单台Mysql作为独立的数据库是完全不能满足实际需求的,无论是在安全性,高可用性以及高并发等各个方面. 因此,一般来说都是通过 主从复制(Master-Slave)的方式来同步数据,再通过读写分离(MySQL-Proxy)来提升数据库的并发负载能力 这样的方案来进行部

42-4 mysql主从复制

04 mysql主从复制架构及实现 实战:主主复制 [[email protected] ~]# systemctl stop mariadb.service  [[email protected] ~]# systemctl stop mariadb.service [[email protected] ~]# rm -rf /var/lib/mysql/* [[email protected] ~]# rm -rf /var/lib/mysql/* [[email protected] ~]

MySQL主从复制、读写分离、高可用集群搭建

MySQL主从复制.读写分离.高可用集群搭建  一.服务介绍   1.1 Keepalived     Keepalived,见名知意,即保持存活,其目的是解决单点故障,当一台服务器宕机或者故障时自动切换到其他的服务器中.Keepalived是基于VRRP协议实现的.VRRP协议是用于实现路由器冗余的协议,VRRP协议将两台或多台路由器设备虚拟成虚拟设备,可以对外提供虚拟路由器IP(一个或多个),即漂移IP(VIP). 1.2 ProxySQL ProxySQL是一个高性能,高可用性的MySQL

MySQL主从复制介绍

1.1 MySQL主从复制原理介绍 MySQL的主从复制是一个异步的复制过程(虽然一般情况下感觉是实时的),数据将从一个MySQL数据库(我们称之为Master)复制到另一个MySQL数据库(我们称之为Slave),在Master与Slave之间实现整个主从复制的过程是由三个线程参与完成的,其中有两个线程(SQL线程和IO线程)在Slave端,另外一个线程(I/O线程)在Master端. 要实现MySQL的主从复制,首先必须打开Master端的binlog记录功能,否则就无法实现.因为整个复制过

mysql主从复制延迟问题的相关知识与解决方案

一.如何监控发生了主从延迟? 在从库机器上,执行show slave status,查看Seconds_Behind_Master值,代表主从同步从库落后主库的时间,单位为秒,若同从同步无延迟,这个值为0. Mysql主从延迟一个重要的原因之一是:mysql是以单线程串行执行. 主从复制数据时,在从服务器上的mysql,是一个线程在同步数据. 串行的方式,它是指,执行一个后才继续执行下一个.如果一个卡住了,要等待时间,才会继续下一个.串行与并行是相反的. 二.同步延迟发生的场景 当主库的TPS并

生产环境 MySQL主从复制(同步)

服务器信息 1.主服务器信息 [email protected]:~$ lsb_release -a No LSB modules are available. Distributor ID:  Ubuntu Description:     Ubuntu 14.04.4 LTS Release:   14.04 Codename:  trusty [email protected]:~$ mysql -V mysql  Ver 14.14 Distrib 5.5.50, for debian-

linux笔记 第四十课 mysql主从复制

1.MYSQL复制的基础概念 2.MYSQL复制的实现 3.MYSQL复制架构及双主模型演示 4.MYSQL复制监控/常见问题及解决方案 5.MariaDB  GTID及多源复制 6.MariaDB  GTID读写分离及mysql-proxy的使用 一.MySQL主从复制的基础知识 二.MySQL主从复制实现(以mariadb 5.5.36为例) 实验环境:主服务器(node1)172.16.100.7 从服务器(node2)172.168.100.8 软件:mariadb-5.5.36-lin

浅谈mysql主从复制的高可用解决方案

1.熟悉几个组件(部分摘自网络)1.1.drbd     —— DRBD(Distributed Replicated Block Device),DRBD号称是 "网络 RAID",开源软件,由 LINBIT 公司开发.DRBD 实际上是一种块设备的实现,主要被用于Linux平台下的高可用(HA)方案之中.他是有内核 模块和相关程序而组成,通过网络通信来同步镜像整个设备,有点类似于一个网络RAID的功能.也就是说当你将数据写入本地的DRBD设备上的文件系统 时, 数据会同时被发送到网

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主从复制--mysql-5.5异步、半同步配置

背景介绍 mysql5.5之前版本,mysql主从复制比较简单 mysql5.6:gtid,multi-thread replication master 1 启用二进制日志 log-bin = master-bin log-bin-index = master-bin.index 2 选择一个唯一的server id server-id = [0~2^32] 3 创建具有复制权限的用户 replication slave,复制的从节点 replication client,联系master,获