mysql主从复制

mysql主从复制

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

mysql的主从复制模式

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

主数据库一旦崩溃，主mysql的事务可能没有传到从mysql这个时候强行把从提升为主，可能到新的主mysql数据不完整（很少见，工作当中，异步复制）

2、全同步复制，主库执行完成一个事务，所有的从库都执行了该事务之后才会返回客户端。因为需要等待所有从库全部执行完成，性能必然下降（对数据一致性，和数据完整要求很好的场景。）

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

这个延迟一般是一个tcp/ip的往返时间，（主发送到接收的时间，单位是毫秒）,半同步复制最好在电视的网络中使用

时间<1ms: round-trip time RTt

log-slave-updates=true

#允许从服务器复制数据时，可以主的二进制日志写到自己的二进制日志当中

relay_log_recovery=1

默认是0，1开启中继日志的恢复，从服务器出现异常或者崩溃时，从服务器会从主服务器的二进制日志的争取读取和应用中继日志。同步。

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

start slave;

slave

Slave_IO_Running:Yes:负责和主库的IO通信

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

slave io running no

1、网络问题

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

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

要么时文件名错了，要么时位置偏移量不对

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

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

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、主从复制设计的目的就是为了在主库上些，在从库上查，读写分离实现在高可用。

读写分离；

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

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

为什么要有读写分离：

1、数据库在写入数据时，比较耗时（msyql写1万条数据 3分30秒）

2、但是在读的时候，速度很快（读1万条，4.96秒）

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

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

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

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

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

测试库一般不管

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

mysql读写分离的原理：

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

特点是性能好，在代码中就可以实现，不需要额外的硬件设备

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

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

mysql-proxy自带的开源项目，基于自带的lua脚本，这些lua脚本不是现成的，要自己写，不熟悉内置变量写不出来。

atlas ：360内部自己使用的代理工具不对外公开，每天的读写请求承载量可以到几十亿条，支持事务，支持存储过程。

amoeba开发人陈思儒 基于java开发的开源软件。不支持事务也不支持存储过程，但是Amoeba还是用的最多的功能比较强大的软件。

Amoeba：来实现读写分离

三个库上设置定时任务

架构主从复制和读写分离

MySQL：主 20.0.0.50

MySQL2：从 20.0.0.60

MySQL3：从 20.0.0.70

test1：读写分离的服务器 mycat 20.0.0.20

test3：客户端 20.0.0.30

设置主从数据库同步时间

主数据库操作：

Vim /etc/my.conf

两台从数据库：

到工具内部查看一下

yum install java -y

java -version

创建/apps文件夹，并解压mycat包至/apps下

tar zxvf Mycat-server-1.6.7.6-release-20210303094759-linux.tar.gz -C /apps/

设置变量环境

echo 'PATH=/apps/mycat/bin:$PATH' > /etc/profile.d/mycat.sh

source /etc/profile.d/mycat.sh

vim server.xml

vim schema.xml

mycat star

tail -f /apps/mycat/logs/wrapper.log

客户端yum install -y mariadb-server mariadb

systemctl start mariadb.service

 mysql -u root -p123456 -h 20.0.0.77