主从复制概念
|------------------------------------------------------------------------------|
| 主mysql上的数据，新增，修改库，表，表里的数据，都会同步到mysql上，查不在此类 主从复制是单向的，只能从主复制到从，从数据库无法复制到主数据库器 |
主从复制的工作过程
|---|--------------------------------------------------------------------------------|
| 1 | 主节点的数据记录发生变化都会记录在二进制日志 |
| 2 | Slave节点会在一定时间内对主库的二进制文件进行探测，看其是否发生变化，如果发生变化，从库他会开启一个I/O的线程请求master主库的二进制事件 |
| 3 | 主库会给每一个I/O的线程启动一个dump，用于发送二进制事件给从库，从库通过I/O线程获取更新，slave_sql负责将更新写入到从库本地，实现主从一至。 |
Mysql的主从复制的模式
|-------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 异步复制 | 异步复制：mysql的默认复制就是异步复制(不管发送结果)，只要执行完之后，客户端提交事务，主mysql会立即把结果返回从服务器，主mysql并不关心mysql是否已经接收，并且处理。 主一旦崩溃，主mysql的事务可能没有传到从mysql，这个时候强行把从服务器提升为主，可能到新的主mysql，数据不完整（很少见，工作当中都是异步复制） |
| 全同步复制 | 全同步复制：主库执行完成一个事务，要等待所有的从库都执行了该事务之后才会返回客户端，因为需要等待所有从库全部执行完成，性能必然下降。（对数据一致性，和数据完整要求很好的场景） |
| 半同步复制 | 半同步复制：介于异步复制和全同步复制之间，主库执行完一个客户端提交的事务之后，至少等待一个从库接收并处理完成之后，才会返回客户端。半同步在一定程度上提高了数据的安全性，也会有一定的延迟。 这个延迟一般是一个tcp/ip的往返时间。(从发送到接收的时间，单位是毫秒)，半同步复制最好在低延时的网络中使用。 这边会有一个专业名词：时间<1ms: round-trip time RTT |
mysql主从复制延迟如何解决
|------|---------------------------------------------------------------------------|
| 硬件方面 | 主库一般不需要动的太多，从库配置要更好，提升它的随机写能力性能，比如硬盘可以换成固态 升级cpu核数，扩大下内存，尽量使用物理机（不要用云服务器） |
| 网络层面 | 主从服务器都配置在一个局域网内，尽量避免跨网段和跨机房 |
| 架构方面 | 读写分离，把写入控制在主库，从库负责读，降低从库的压力 |
| 配置方面 | mysql配置从配置文件的角度实现性能最大化 |
追求安全性的双一设置
追求安全性的配置
|---|-----------------------------------------------------------|
| | innodb_flush_log_at_trx_commit=1 |
| 1 | 每次提交事务时都会刷新事务日志，以确保持久性，这是最高级别的数据安全性，但是会影响性能，默认就是1 |
| 0 | 0就是事务提交时不会立刻刷新，而是每秒刷新一次，可以提性能，但是发生故障会导致数据丢失。 |
| 2 | 2事务提交时，事务日志不会写入硬盘而是保存在系统缓存，也不会进行刷新，提供了一定的安全性能，但要求内存要求比较高 |
| | Sync_binlog=1 |
| 1 | 1也是默认值，每次提交事务之后，直接把二进制日志刷新到磁盘，以确保日志的持久性，但会占用比较高的性能，但是安全性高 |
| 0 | 会把日志写入到缓存，也不会刷新日志，故障发生也会丢失数据，内存的要求也提高了 |
| N | 每提交了N次事务执行一次刷新到磁盘，提高性能，但是一旦崩溃，数据会大量丢失 |
追求性能化
|---|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| | sync_binlog=0 |
| 0 | 设置为0表示二进制日志（binary log）写入操作系统缓存，但不进行物理刷新。 这提供了较高的性能，但在系统崩溃或断电时可能会导致未刷新的二进制日志数据的丢失 |
| 2 | innodb_flush_log_at_trx_commit=2: 设置为2表示事务提交时将事务日志写入操作系统缓存，但不进行物理刷新。 这提供了一定的性能提升，但在系统崩溃或断电时可能会导致未刷新的事务日志数据的丢失。 |
| | logs-slave-updates=0: 如果设置为0，表示不将从库的更新写入二进制日志。 这对于避免在主从复制中引入循环复制（circular replication）很有用 |
| | 增大 innodb_buffer_pool_size innodb_buffer_pool_size 控制 InnoDB 存储引擎的缓冲池大小。增大这个值可以提高 InnoDB 的性能， 因为更多的数据和索引可以缓存在内存中，减少了对磁盘的访问次数。但要注意， 设置得太大可能导致系统内存不足。 Innodb_buffer_pool_size 300M 500G Innodb 存储引擎的缓存池大小，设置的s数值越高，可以提高innodb的性能 |
主从复制的问题
|---|----------------------------------------------------|
| 1 | 只能在主库上发生变化，然后同步到从 |
| 2 | 复制过程是串行化过程，在从库上复制是串行的，主库的并行更新不能再slave从库上并行操作 |
| 3 | 核心意义：主从复制的设计目的就是为了实现读写分离，也就是在主库上写，在从库上查，读写分离，实现高可用 |
读写分离概念
|---|-------------------------------------------------|
| 1 | 要实现读写分离，必须要先实现主从复制 |
| 2 | 读写分离：所有的写入操作都在主库，从库只负责读（select）。如果有更新，是从主库复制到从库 |
为什么要有读写分离
|---|----------------------------------------------|
| 1 | 数据库在写入数据时比较耗时（mysql写1w条数据要3分30秒） |
| 2 | 数据库在读的时候，速度很快（读1w条只需要4.96秒） |
| | 读写分离之后，数据库的写入和读取是分开的，哪怕写入的数据量比较大，但是不影响查询的效率。 |
什么场景需要读写分离
|---|-------------------------------------------------------------------------|
| 1 | 数据库不是一定需要读写分离的，只有在某些程序在使用过程中，更新很少，查询较多，这种情况可以考虑读写分离，读和查的需求差不多，也可以考虑读写分离 |
| 2 | 生产库一般都会做读写分离 |
| 3 | 测试库一般不管 |
| 4 | 在工作当中，数据库的读写不会在同一个库中完成。既不安全也不满足高可用，也不能实现高并发。工作中都会做读写分离 |
Mysql读写分离的原理，如何实现的
|--------|-------------------------------------------|
| 根据脚本实现 | 在代码当中实现路由分类，select insert 进行路由分类，这类方法是最多的 |
| 特点 | 性能好，在代码中就可以实现，不需要额外的硬件设备 |
| 缺点 | 开发实现的，跟我们无关，如果大型的应用复杂的应用，设计改动的代码非常多 |
|-----------|----------------------------------------------------------------------------|
| 基于中间层代理实现 | Mysql-proxy：自带的开源项目，基于自带的lua脚本，这些lua脚本不是现成的，要自己写，如果你不熟悉他的内置变量写不出来 |
| Atlas | 360内部自己使用的代理工具，每天的读写请求承载量可以到几十亿条，还支持事务，还支持存储过程 |
| Amoeba | 阿米巴 ：陈思儒，之前在阿里就职，由java开发的一个开源团建，他不支持事务，也不支持存储过程，但是amoeba 还是用的最多的，功能比较强大的软件 |
出现Slave_IO_Running: NO 原因
|---|----------------------------------------------|
| 1 | 网络问题 |
| 2 | My.cnf 配置文件写错了 |
| 3 | 配置文件 CHANGE master to。。。 要么是文件名错了 ，要么是配置文件错了 |
| 4 | 防火墙策略问题 |
主从复制延迟问题
|---|----------------------------------|
| 1 | 网络问题 |
| 2 | 主从硬件问题（cpu主频频率也就是性能不够，内存IO，硬件IO） |
| 3 | 同步复制而不是异步复制 |
面试题
|--------------------------------|-----------------------------------------------------------------------------------|
| 主从复制原理 | 开发可以说脚本 运维一般用amoeba或者mycat |
| 如何查看主从复制是否成功 | show salve status\G 两个yes就ok 在主库创建表或库，看能否同步到从库 |
| 如果slave_IO_running no 排查思路是什么 | 85%配置文件 |
| show slave STATUS\G 能看到的信息有哪些 | IO和sql线程的状态信息 Master的服务器的ip地址，端口，事务开始的位置 最近一次的错误信息和错误的位置 最近一次的IO报错信息 最近一次sql报错的信息 |
| 主从复制的延迟如何解决 | |
架构主从复制和读写分离
主从复制
bash
#Mysql1为主,Mysql2为从,Mysql3为从,Test1作为读写分离的服务器,Test2作为客户端
#时间必须要同步
主mysql
systemctl stop firewalld
setenforce 0
yum -y install ntp
vim /etc/ntp.conf
#最后一行添加
server 127.127.233.0
#233为自己ip地址所在网段
fudge 127.127.233.0 stratum 8
#从本地获取时间源同步,不走网络,设置层级,数字越小,时间精确度越高,设置fudge 8,最高到15
wq!
systemctl restart ntpd
#时间同步完成之后的操作
vim /etc/my.cnf
log-bin=master-bin
#打开二进制日志，它是根据二进制日志进行同步的
binlog_format=MIXED
#如果并发量变高，会自动切换高并发
log-slave-updates=true
#允许从数据库复制数据时,可以从主数据库的二进制日志写到自己的二进制日志当中
wq!
systemctl restart mysqld
mysql -u root -p123456
grant replication slave on *.* to 'myslave'@'192.168.233.%' identifed by '123456';
#给从数据库授权,从库能够访问主数据库,给他定义一个用户名为myslave,从233这个网段中来,密码是123456
flush privileges;
show master status;
从mysql(1)
systemctl stop firewalld
setenforce 0
yum -y install ntp
systemctl restart ntpd
/usr/sbin/ntpdate 192.168.233.88
#两台从数据库的时间源指向主数据库的
crontab -e -u root
#生产当中会加一个定时任务，随时进行同步
*/30 * * * * /usr/sbin/ntpdate 192.168.233.88
#每三十分钟执行一次与主数据库进行时间同步
wq!
#同步完成之后可以多重执行 date 查看时间是否同步成功
从mysql(2)
systemctl stop firewalld
setenforce 0
yun -y install ntp
systemctl restart ntpd
/usr/sbin/ntpdate 192.168.233.88
crontab -e -u root
*/30 * * * * /usr/sbin/ntpdate 192.168.233.88
wq!