MySQL主从复制(笔记)

通常当服务器的性能达到瓶颈的时候,需要扩展,而扩展又分为以下两种

scale up(on):向上扩展,也叫垂直扩展,在同一个架构内增加cpu或内存,但是并不是说cpu和内存越多越好,因为在同一台服务器上,cpu和内存都会争用相同的总线或资源,所以在同一台服务器上,硬件配置增高对性能的影响大约呈下图方式,所以向上扩展的性能并不是线性上升的,并且代价比较大

image

scale out:向外扩展也叫水平扩展,,扩展服务器数量,使用多台服务器通过一个调度器来实现负载均衡以提高服务器响应,其模型如下

image

 

MySQL的复制功能就是让MySQL有了水平扩展的能力,对于MySQL来说,如图1-2,假如服务器1和服务器2分别是两台MySQl服务器,那么服务器1和服务器2就要保证其内部的数据是一样的.,那么如何实现两台服务器的数据是一样的呢?其一,可以让服务器1和服务器2共享一个文件系统,如:nfs,但是这样,数据都不是本地的,都需要经过套接字去nfs服务器读取文件,效能很低.其2,使用rsync+notifi的机制,当更新数据时,只更新服务器1的数据,当服务器1 的数据被更新时,会主动通知服务器2同步数据,这样,当用户需要读取数据的时候,服务器响应的数据都是本地服务器的,可以直接通过本地的磁盘I/O返回数据给用户,而不是通过网络I/O,这样返回数据就很快了,不过得注意,只能有一台服务器可以写,不然会乱掉的.而MySQL的主从服务器就是使用第二种策略.一台主服务器可以读写数据,一(或多台)台从服务器只能读数据

MySQL的复制模式工作方式,

当发生了任何修改或企图修改MySQL数据的操作,都会被记录在MySQL的主服务器的二进制日志文件中,从服务器的IO thread会从主服务器的二进制文件中不断的请求数据,存到自己的本地日志中,主服务器的binlog dump将IO thread请求的事件响应给从服务器,从服务器接收到日志后保存在本地的这个日志叫中继日志,然后再从中继日志中读取数据写入数据库中.当从服务器发现自己的数据已经是最新的了,就会转入睡眠模式,一旦主服务器有数据更新,会通过binlog dump唤醒从服务器的IO thread进程来继续同步数据,而从服务器从中继日志向数据库中写入数据是通过一个叫SQL thread线程完成的,如此一来,从服务器的二进制日志就没作用了.一般来说,服务器的模式只能是一主多从,而不是一从多主(多源复制).

MySQl的主从模式有两种

1.同步传输数据

       当主服务器发生修改操作,二进制文件日志写入成功时,会响应给用户.当主服务器把改变后的日志发送给从服务器,从服务器响应后,主服务器才响应给用户,写入成功,这种叫做同步传输.

2.异步传输数据

      当主服务器发生修改操作,二进制日志写入成功时,不理会从服务器是否接受到修改信息,首先响应用户,修改成功,这叫做异步传输

在这两种模式中,异步的性能要比同步高,并且系统默认也是异步,如果使用同步,从服务器如果发生故障,没有接收到修改信息,主服务器就会一直被阻塞,也就无法工作了

读写分离

我们之前说过,主服务器可以读写,从服务器只能读,假设有一台主服务器,多台从服务器,为了让从服务器分担主服务器的负担,我们的场景是:主服务器值负责写入数据,而所有的读操作都有从服务器完成,那么,当请求命令来的时候(如图1-3),如何判定该命令是读的命令还是写的命令呢?这时候需要一个读写分离器,由于mysql是工作在应用层,因此,读写分离器要能识别mysql的语句,也必须要工作在应用层.

image

读写分离器工具:

      amoeba:变形虫

      mysql-proxy:用的少,不稳定

双主模式:

     两台服务器A和B,A有一个中继日志和一个二进制日志,B也有一个中继日志和二进制日志,当A有数据变化时,B主机读取A的二进制日志保存在自己的中继日志中同时也保存在自己的二进制日志中,当B主机有数据变化时,A主机读取B主机的二进制日志保存在自己的中继日志中,同时也保存在自己的二进制日志中.这样一来不是就死循环了吗?因为任何改变的数据都会记录在二进制日志中,双方又都会不停的去读取对方的改变了的日志,那怎么办呢?这时就要靠server-id了,每一个服务器在复制时会保留对方的server-id,因此,如果A服务器再向B服务器的获取数据时,发现server-id就是自己的,就没有必要接受记录在本地了,这样就避免了死循环了,并且由于双方都能读写,那数据库中的表的自动增长字段如何避免重复呢?在双主模型中,只能A服务器使用单数(双数),B服务器使用双数(单数),才能避免自动增长字段的重复:如图1-4所示:

image

在双主模式下有一种情况会导致数据的不同步,并且是无法避免的,示例如下:

A: update t1 set Salary=salary+1000 WHERE Age>=30;

A库锁定第一个字段改第二个字段

B:  update t1 set Age=Age-3 WHERE Salary < 3000;

B库锁定第二个字段改第一个字段

实际上,双主模型中均衡了读请求,但是写的操作还是一样多

 

数据切割:

....不写了...听都听不懂...

示例:

注:主从的MySQL版本最好一致,如果不一致,主服务器的版本要低于从服务器的版本

场景1:在新环境,主从服务器都是新搭建的,如图1-5所示

image

1.修改主配置文件的二进制日志保存点,此步非必要步骤,只是为了提醒笔者要养成良好的习惯,二进制日志不要和数据文件放在一个盘

image

2.配置必须的配置文件

image

图1位置,就使用混合日志.图2位置,server-id必须和从服务器的server不一致

3.修改二进制日志文件的目录属主和属组信息,此步是容易遗漏点

image

4.启动主服务器的mysql服务,并查看端口

image

5.登录mysql并授权可执行复制操作的用户

image

图1位置,在实际生产环境中,主机名仅指定你需要授权的主机名.图2位置,密码不要设置的这么简单

6.配置从服务器

image

图1和图2位置需要注释掉二进制日志,图3位置的server-id不能和主服务器的一样,图4位置表示此服务器是从服务器

设置从服务器的只读属性

image

这是笔者后来添加的,有些地方不太一样,只是写出添加的方式而已

image

 

7.启动从服务器的mysql服务器

image

8.查看从服务器的中继日志是否启用

image

扩展阅读:CHANGE MASTER TO 命令的使用

image

9.增加主服务器

image

10.查看从服务器信息,这里的用户名错了,笔者改过一次,应该是小写的test

image

11.查看本地日志文件目录,只要启动复制就有日志文件了

image

12.启动从服务器,并查看本地日志,注意maridb是在 /var/log/

image

image

13.再次查看从服务器的状态

image

14.在主服务器上新建一个数据库lidefu,然后在从服务器上查看是否能同步该库

image

查看从服务器

image

你可能感兴趣的:(服务器,硬件,target,影响,blank)