主从复制和读写分离

MySQL 主从复制和读写分离：

主从复制：主MySQL上的数据，新增，修改库，表，表里的数据，都会同步到从MySQL上。

MySQL的主从复制的模式：（面试题）

1，异步复制：（MySQL的默认复制就是异步复制，最常用。只要执行完之后，客户端提交事务，主MySQL会立即把结果返回给从服务器，主服务器并不关心从服务器是否已经接受，并且处理。）

问题：主一旦崩溃，主MySQL的事务可能没有传到从MySQL，这个时候强行的把从提升为主，可能到新的主服务器数据不完整。（很少见。）

2，全同步复制，主库执行完成一个事务，所有的从库都执行了该事务之后才会返回客户端。

因为需要等待所有从库全部执行完成，性能必然下降。（对数据一致性，和数据完整性要求很好的场景。）

3，半同步复制：介于异步和全同步复制之间。主库执行完一个客户端提交的事务之后，至少等待一个从库接受并处理完成之后才会返回给客户端。半同步在一定程度上提高了数据的安全性。也会有一定延迟。

这个延迟一般是一个tcp/ip的时间：从发送到接受的时间，单位是毫秒ms

时间<1ms: round-trip time RTT

架构：主从复制和读写分离：

mysql1 主

mysql2 从

mysql3 从

test1 读写分离的服务器

test2 客户端

实验：

主从复制

主从服务器之间的时间也要同步：

安装 ntp工具

yum -y install ntp

改ntp配置文件：

数字越小，时间的精确度越高，设置fudge 8 时间层级是8 最高到15。

从本地获取时间源，不从网络获取

从服务器执行同步命令

生成中会加一个定时任务

每30分钟同步一次

查看时间：

改主配置文件：

log-bin=master-bin #添加，主服务器开启二进制日志

binlog_format = MIXED

log-slave-updates=true

#添加，允许slave从master复制数据时可以写入到自己的二进制日志

进入服务器，新建一个用户，并授权：

GRANT REPLICATION SLAVE ON . TO 'myslave'@'192.168.176.%' IDENTIFIED BY '123456';

FLUSH PRIVILEGES;

show master status;

靠位置点进行同步：

修改从数据库配置文件

每个id不能一样：

server-id = 2

relay-log=relay-log-bin

relay-log-index=slave-relay-bin.index

relay_log_recovery = 1

relay_log_recovery=1

默认是0，1开启中继日志的复制。从服务器出现异常或者崩溃时，从服务器会从主服务器的二进制

server-id = 3

relay-log=relay-log-bin

relay-log-index=slave-relay-bin.index

relay_log_recovery = 1

重启数据库

从服务器分别进入数据库：

mysql -u root -p123456；

和主进行同步：

CHANGE master to master_host='192.168.176.30',master_user='myslave',master_password='123456',master_log_file='master-bin.000001',master_log_pos=604;

启动同步：

start slave;

查看：

show slave status\G;

Slave_IO_Running: Yes #负责与主机的io通信

Slave_SQL_Running: Yes #负责自己的slave mysql进程

在主数据库创建库，表

从库也会跟着改变

面试题：如果slave io running no

1,网络问题

2，my.cnf 配置文件写错了

3，

4，防火墙和安全机制。

主从复制是单向的，只能从主复制到从服务器。

面试题：主从复制的延迟问题：

1，网络延迟

2，主从硬件设备（CPU主频，内存IO，硬件IO）。

3，同步复制而不是异步复制。

解决方案：

1，硬件方面，主库一般来说不需要动的太多，从库硬件配置要更好。提升随机写的性能。硬盘可以换成固态的，升级cpu的核数，扩容内存。尽量使用物理机（不要用云服务器。）4核8G，硬盘。

2，网络层面，主从服务器配置在一个局域网内，尽量避免跨网段和跨机房。

3，架构方面：读写分离，把写入控制在主库，从库负责读，降低从库的压力

4，配置方面 mysql配置。从配置文件的角度实现性能最大化

追求安全性的配置：

innodb_flush_log_at_trx_commit=1

每次事务提交时都会刷新事务日志。已确保持久性，最高级别的数据安全性，但是会响应性能，默认就是1

0就是事务提交时不会立刻刷新，而是每秒刷新一次。可以提高性能，但是发生故障会导致数据丢失。

2 事务提交时，事务日志不会写入硬盘而是保持在系统缓存，不会进行刷新。一定的安全性和性能。内存要求比较高。

sync_binlog=1

1，也是默认值，每次提交事务之后，直接把二进制日志刷新，以确保日志的持久性。占用比较高的性能。但是安全性高。

0，二进制日志写入到缓存，也不会刷新日志。故障发生也会丢失数据，内存的要求也提高了

3，每3个事务执行一次刷新磁盘。提高性能，但是一旦崩溃，数据会大量丢失。

追求性能化：

sync_binlog=0

innodb_flush_log_at_trx_commit=2

logs-slave-updates=0

从库的更新不会写入二进制日志（不建议）

innodb_buffer_pool_size 300M 500G

innodb存储引擎的缓冲池大小，设置的s值越高，可以提高innodb的性能。

更多的数据和索引都可以缓存在内存中。减少磁盘的访问次数。对系统内存要求比较高。

主从复制的一个工作过程：

1，主节点是数据记录发生变化都会记录在二进制日志。

2，slave节点会一定时间内对主库的二进制文件进行探测，看其是否发生变化，如果有变化，从库会开启一个I/O线程，请求主库的二进制事件。

3，主库会给每一个I/O的线程启动一个dump。用于发送二进制事件给从库，从库通过I/O线程获取更新，slave_sql负责将更新写入到从库本地。实现主从一致。

主从复制的问题：

1，只能在主库上发生变化，任何同步到从。

2，复制过程是串行化过程，在从库上复制是串行的，主库的并行更新不能在库上并行操作。

3，主从复制的设计目的就是为在主库上写，在从库上查看。读写分离，实现高可用

mysql主从复制

若主从版本不一致，从的版本一定要高于主，保证可以向下兼容

因为若主的版本更新，低版本的从无法兼容的

读写分离：

要实现读写分离，必须要实现主从复制。

读写分离：所有的写入操作在主库，从库只负责读。（select）。如果有更新，是从主库复制到从库。

为什么要有读写分离：

1，数据库在写入数据时，比较耗时（mysql写一万条数据 3分钟）

2，数据库在读的时候，速度很快（读一万，5秒）

读写一旦分离，数据库的写入和读取是分开的，哪怕写入的数据量比较大，但是不影响查询的效率。

在什么场景下需要读写分离：

只有在某些程序在使用数据库过程中，更新少，但是查询比较多，这种情况可用考虑读写分离。

读和查的需求差不多，也可以考虑读写分离。

生产库一般都会做读写分离

测试库一般不管。

在工作中，数据库的读写不会在同一个库中完成。即不安全，也不能满足高可用，也不能实现高并发。工作中读会做读写分离。

mysql读写分离的原理：

1，根据脚本实现。在代码中实现路由分类。select insert 进行路由分类。这种方式是最多的。

性能好，在代码中可用实现，不需要额外的硬件设备

缺点：开发实现的，跟我们无关。如果大型的复制的应用，设计改动的代码非常多。

2，基于中间代理层实现：

mysql-proxy自带的开源项目，基于自带的lua脚本。这些lua脚本不是现成的，，要自己写，不熟悉他的内置变量写不出来的 atlas 360内部做自己代理工具。每天的读写请求承载量可用到几十亿条。支持事务，支持存储过程。

3，Amoeba 陈思儒，之前在阿里就职。是由java开发的一个开源团建。不支持事务，也不支持存储过程。但是Amoeba还是用的最多的功能比较强大的软件。

实验：

mysql1 主

mysql2 从

mysql3 从

test1 读写分离的服务器 Amooeba

test2 客户端

修改java环境

查看java环境：java -version

基于 jdk1.5开发的，官方推荐的

更换java环境

cd /opt/

cp jdk-6u14-linux-x64.bin /usr/local/

cd /usr/local/

chmod +x jdk-6u14-linux-x64.bin

./jdk-6u14-linux-x64.bin

//按yes，按enter

mv jdk1.6.0_14/ /usr/local/jdk1.6

vim /etc/profile

在最后一行添加

export JAVA_HOME=/usr/local/jdk1.6

export CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib

export PATH=$JAVA_HOME/lib:$JAVA_HOME/jre/bin/:$PATH:$HOME/bin

export AMOEBA_HOME=/usr/local/amoeba

export PATH=$PATH:$AMOEBA_HOME/bin

使文件立即生效：source /etc/profile

java -version

安装amoeba

在opt目录下创建amoeba目录

mkdir /usr/local/amoeba

解压

tar zxvf amoeba-mysql-binary-2.2.0.tar.gz -C /usr/local/amoeba/

赋权

chmod -R 755 /usr/local/amoeba/

执行：

/usr/local/amoeba/bin/amoeba

显示 amoeba start|stop说明安装成功

在三台数据库给用户amoeba赋权

grant all on *.* to amoeba@'192.168.176.%' identified by '123456';

flush privileges;

在amoeba服务器修改配置文件：

cd /usr/local/amoeba/conf/

配置用户信息：

配置数据库信息：

备份

cp amoeba.xml amoeba.xml.bak

改配用户信息：

vim amoeba.xml

--30行--

amoeba

--32行--

123456

--115行--

master

--117-去掉注释-

master

slaves

修改数据库信息：

cp dbServers.xml dbServers.xml.bak

vim dbServers.xml

--23行--注释掉 作用：默认进入test库 以防mysql中没有test库时，会报错

--26--修改

amoeba

--28-30--去掉注释

123456

--45--修改，设置主服务器的名Master

--48--修改，设置主服务器的地址

192.168.233.21

--52--修改，设置从服务器的名slave1

--55--修改，设置从服务器1的地址

192.168.233.22

--58--复制上面6行粘贴，设置从服务器2的名slave2和地址

192.168.233.23

--65行--修改

--71行--修改

slave1,slave2

启动Amoeba软件：

/usr/local/amoeba/bin/amoeba start &

查看8066端口是否开启

netstat -anpt | grep java

测试读写分离：

客户端安装 mariadb

yum install -y mariadb-server mariadb

systemctl start mariadb.service

修改三台mysql生成日志文件

最后一行添加：

general_log=ON

general_log_file=/usr/local/mysql/data/mysql_general.log

三台库打开日志

tail -f /usr/local/mysql/data/mysql_general.log

在客户端对表进行写入时三个日志都会有显示

查看表只有一台从库有记录，而且会轮询记录：