第二十三天：MYSQL集群Cluster

标签：log 第二十三 数据库 MySQL Cluster 复制 master MYSQL 节点

一、MySQL 主从复制

 1、主从复制架构和原理

读写分离 复制：每个节点都有相同的数据集，向外扩展，基于二进制日志的单向复制 2、复制架构 （1）一主一从复制架构

 （2）一主多从复制架构

3、主从复制原理

 

 主从复制相关线程

主节点： dump Thread：为每个Slave的I/O Thread启动一个dump线程，用于向其发送binary log events 从节点： I/O Thread：向Master请求二进制日志事件，并保存于中继日志中 SQL Thread：从中继日志中读取日志事件，在本地完成重放 跟复制功能相关的文件： master.info：用于保存slave连接至master时的相关信息，例如账号、密码、服务器地址等 relay-log.info：保存在当前slave节点上已经复制的当前二进制日志和本地relay log日志的对应关系 mysql-relay-bin.00000#: 中继日志,保存从主节点复制过来的二进制日志,本质就是二进制日志  4、各种复制架构 　　一Master/一Slave 　　一主多从  　　从服务器还可以再有从服务器 　　Master/Master 　　一从多主:适用于多个不同数据库 　　环状复制 复制需要考虑二进制日志事件记录格式 　　STATEMENT（5.0之前）, Mariadb5.5 默认使用此格式 　　ROW（5.1之后，推荐）,MySQL 8.0 默认使用此格式 　　MIXED: Mariadb10.3 默认使用此格式 5、实现主从复制配置
 （1）主节点配置：  　　启用二进制日志

[mysqld]
log_bin=/data/logbin/mysql-bin

　为当前节点设置一个全局惟一的ID号

[mysqld]
server-id=#
log-basename=master  #可选项，设置datadir中日志名称，确保不依赖主机名

　查看从二进制日志的文件和位置开始进行复制

 　　SHOW MASTER STATUS;  创建有复制权限的用户账号

GRANT REPLICATION SLAVE  ON *.* TO 'repluser'@'HOST' IDENTIFIED BY 'replpass';
#MySQL8.0 分成两步实现
mysql> create user repluser@'10.0.0.%' identified by '123456';
mysql> grant replication slave on *.* to repluser@'10.0.0.%';

（2）从节点配置：

 启动中继日志

[mysqld]
server_id=# #为当前节点设置一个全局惟的ID号
log-bin
read_only=ON #设置数据库只读，针对supper user无效
relay_log=relay-log #relay log的文件路径，默认值hostname-relay-bin
relay_log_index=relay-log.index  #默认值hostname-relay-bin.index

使用有复制权限的用户账号连接至主服务器，并启动复制线程

CHANGE MASTER TO MASTER_HOST='masterhost', 
MASTER_USER='repluser', 
MASTER_PASSWORD='replpass', 
MASTER_LOG_FILE='mariadb-bin.xxxxxx', 
MASTER_LOG_POS=#
MASTER_DELAY = interval; #可指定延迟复制实现访问误操作,单位秒

START SLAVE [IO_THREAD|SQL_THREAD];
SHOW SLAVE STATUS;

#查看 relaylog 事件
SHOW RELAYLOG EVENTS in 'relay-bin.00000x';

如果主节点已经运行了一段时间，且有大量数据时，如何配置并启动slave节点 　　通过备份恢复数据至从服务器 　　复制起始位置为备份时，二进制日志文件及其POS  

6、主从复制相关

（1）限制从服务器为只读

read_only=ON
#注意：此限制对拥有SUPER权限的用户均无效

（2）在从节点清除信息

RESET SLAVE #从服务器清除master.info ，relay-log.info, relay log ，开始新的relay log
RESET SLAVE  ALL #清除所有从服务器上设置的主服务器同步信息，如HOST，PORT, USER和
PASSWORD 等

（3）复制错误解决方法

可以在从服务器忽略几个主服务器的复制事件，此为global变量，或指定跳过事件的ID 注意: Centos 8.1以上版本上的MariaDB10.3主从节点同时建同名的库和表不会冲突，建主键记录会产 生冲突

#系统变量，指定跳过复制事件的个数
SET GLOBAL sql_slave_skip_counter = N
#服务器选项，只读系统变量，指定跳过事件的ID
[mysqld]
slave_skip_errors=1007|ALL

（4）START SLAVE 语句，指定执到特定的点

START SLAVE [thread_types]
START SLAVE [SQL_THREAD] UNTIL   MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = 
log_pos
START SLAVE [SQL_THREAD] UNTIL   RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = 
log_pos
thread_types:
   [thread_type [, thread_type] ... ]
thread_type: IO_THREAD | SQL_THREAD

（5）保证主从复制的事务安全

在master节点启用参数：

sync_binlog=1 #每次写后立即同步二进制日志到磁盘，性能差
#如果用到的为InnoDB存储引擎：
innodb_flush_log_at_trx_commit=1 #每次事务提交立即同步日志写磁盘
sync_master_info=# #次事件后master.info同步到磁盘

在slave节点启用服务器选项：

skip-slave-start=ON #不自动启动slave

在slave节点启用参数：

sync_relay_log=# #次写后同步relay log到磁盘
sync_relay_log_info=# #次事务后同步relay-log.info到磁盘

7、实现级联复制

 需要在中间的从服务器启用以下配置 ，实现中间slave节点能将master的二进制日志在本机进行数据库

更新，并且也同时更新本机的二进制，从而实现级联复制  

[mysqld]
server-id=18
log_bin
log_slave_updates      #级联复制中间节点的必选项,MySQL8.0此为默认值,可以不要人为添加,其它
版本默认不开启
read-only

8、主主复制

主主复制：两个节点，都可以更新数据，并且互为主从 容易产生的问题：数据不一致；因此慎用 考虑要点：自动增长id 配置一个节点使用奇数id

auto_increment_offset=1   #开始点
auto_increment_increment=2 #增长幅度

另一个节点使用偶数id

auto_increment_offset=2
auto_increment_increment=2

主主复制的配置步骤： (1) 各节点使用一个惟一server_id (2) 都启动binary log和relay log (3) 创建拥有复制权限的用户账号 (4) 定义自动增长id字段的数值范围各为奇偶 (5) 均把对方指定为主节点，并启动复制线程 9、半同步复制 默认情况下，MySQL的复制功能是异步的，异步复制可以提供最佳的性能，主库把binlog日志发送给从库即结束，并不验证从库是否接收完毕。这意味着当主服务器或从服务器端发生故障时，有可能从服务器没有接收到主服务器发送过来的binlog日志，这就会造成主服务器和从服务器的数据不一致，甚至在恢复时造成数据的丢失 半同步复制默认设置

rpl_semi_sync_master_wait_point=after_commit

 缺点

缺点1： 幻读
当用户提交一个事务，该事务已经写入redo日志和binlog日志，但该事务还没写入从库，此时处在waiting slave dump处，此时另一个用户可以读取到这条数据，而他自己却不能；
缺点2：数据丢失一个提交的事务在waiting slave dump处crash后，主库将比从库多一条数据

增强半同步复制(MySQL5.7新增功能)

#MySQL8.0的默认值
rpl_semi_rsync_master_wait_point=after_sync

 优点

改善1：解决幻读
当用户发起一个事务，该事务先写入二进制后，再向从库进行同步，由于还没有完成提交，此时其他用户无法读取到该数据，解决了幻读
改善2：解决数据丢失一个事务在waiting slave dump处crash掉后，可以通过观察从库上是否存在主库的last gtid值，如果
存在，这条数据正常恢复，如果不存在则删除主库的那条多余的GTID值，然后恢复，保证了数据的完整性

#查看插件文件
[root@centos8 ~]#rpm -ql mysql-server |grep semisync
/usr/lib64/mysql/plugin/semisync_master.so
/usr/lib64/mysql/plugin/semisync_slave.so
#master服务器配置
[root@master ~]#vim /etc/my.cnf.d/mysql-server.cnf
[mysqld]
server-id=8
log-bin
rpl_semi_sync_master_enabled=ON     #修改此行,需要先安装semisync_master.so插件后,再重启,否则无法启动
rpl_semi_sync_master_timeout=3000   #设置3s内无法同步，也将返回成功信息给客户端
#slave服务器配置
[root@slave1 ~]#vim /etc/my.cnf.d/mysql-server.cnf
[mysqld]
server-id=18
rpl_semi_sync_slave_enabled=ON #修改此行,需要先安装semisync_slave.so插件后,再重启,否则无法启动
[root@slave2 ~]#vim /etc/my.cnf.d/mysql-server.cnf
[mysqld]
server-id=28
rpl_semi_sync_slave_enabled=ON #修改此行,需要先安装semisync_slave.so插件后,再重启,否则无法启动
#主服务器配置:
mysql>INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; #永久安装插件
mysql>UNINSTALL PLUGIN rpl_semi_sync_master ;
mysql>SHOW PLUGINS; #查看插件
mysql>SET GLOBAL rpl_semi_sync_master_enabled=1; #临时修改变量
mysql>SET GLOBAL rpl_semi_sync_master_timeout = 3000;  #超时长1s,默认值为10s
mysql>SHOW GLOBAL VARIABLES LIKE '%semi%';

　　 

10、复制过滤器 让从节点仅复制指定的数据库，或指定数据库的指定表 复制过滤器两种实现方式： (1) 服务器选项：主服务器仅向二进制日志中记录与特定数据库相关的事件 缺点：基于二进制还原将无法实现；不建议使用 优点: 只需要在主节点配置一次即可 注意：此项和 binlog_format相关

vim /etc/my.cnf
binlog-do-db=db1 #数据库白名单列表，不支持同时指定多个值，如果想实现多个数据库需多行实现
binlog-do-db=db2 
binlog-ignore-db= #数据库黑名单列表

(2) 从服务器SQL_THREAD在relay log中的事件时，仅读取与特定数据库(特定表)相关的事件并应用于本 地 缺点：会造成网络及磁盘IO浪费,在所有从节点都要配置 优点: 不影响二进制备份还原 从服务器上的复制过滤器相关变量

项不支持多值,只能分别写多行实现
replicate_ignore_db= #指定复制库黑名单
replicate_do_table= #指定复制表的白名单
replicate_ignore_table= #指定复制表的黑名单
replicate_wild_do_table= foo%.bar%  #支持通配符
replicate_wild_ignore_table=

11、GTID复制

GTID（Global Transaction ID 全局事务标识符） MySQL 5.6 版本开始支持,但不太成熟,建议使用 MySQL5.7以上版本的GTID功能 MySQL5.6版本出现没有默认开启，5.7中即使不开启也有匿名的GTID记录。 开启GTID功能可以支持多DUMP线程的并发复制,而且在MySQL5.6实现了基于库级别多SQL线程并发。在MySQL5.7利用 GTID的 Logic clock 逻辑时钟。保证了同库级别下的事务顺序问题。即可以实现基于事务级别的并发回放。从而大大减少了同步的延迟 同时GTID具有幂等性特性,即多次执行结果是一样的 利用 GTID复制不像传统的复制方式（异步复制、半同步复制）需要找到binlog文件名和POS点，只需知道master的IP、端口、账号、密码即可。开启GTID后，执行change master tomaster_auto_postion=1即可，它会自动寻找到相应的位置开始同步 GTID 优点: 　　保证事务全局统一 　　截取日志更加方便。跨多文件，判断起点终点更加方便 　　判断主从工作状态更加方便 　　传输日志，可以并发传输。SQL回放可以更高并发 　　主从复制构建更加方便 GTID 架构 　　

 GTID服务器相关选项

gtid_mode #gtid模式
enforce_gtid_consistency #保证GTID安全的参数

GTID配置范例

1. 主服务器 

vim /etc/my.cnf
server-id=1
gtid_mode=ON
enforce_gtid_consistency
log-bin=mysql-bin  #可选
systemctl restart mysqld
mysql> grant replication slave on *.* to 'repluser'@'10.0.0.%' identified by 
'magedu';

2. 从服务器

vim /etc/my.cnf
server-id=2
gtid_mode=ON
enforce_gtid_consistency
systemctl restart mysqld
#如果主服务器和从服务器数据不一致,需要先将主库数据备份还原至从库,再执行下面操作
mysqldump -A --master-data=2 > /backup/full.sql
mysql>CHANGE MASTER TO MASTER_HOST='10.0.0.100',
 MASTER_USER='repluser',
 MASTER_PASSWORD='magedu',
 MASTER_PORT=3306,
 MASTER_AUTO_POSITION=1;  #使用GTID
  
mysql>start slave;
#注意观察:Retrieved_Gtid_set和Executed_Gtid_Set这两个值,对比主节点执行show master 
status的值,如果相同表示同步完成

12、复制的监控和维护

（1）清理日志

PURGE { BINARY | MASTER } LOGS   { TO 'log_name' | BEFORE datetime_expr }
RESET MASTER TO # #mysql 不支持
RESET SLAVE [ALL]

（2）复制监控

SHOW MASTER STATUS
SHOW BINARY LOGS
SHOW BINLOG EVENTS
SHOW SLAVE STATUS
SHOW PROCESSLIST

（3）从服务器是否落后于主服务

Seconds_Behind_Master：0

（4）如何确定主从节点数据是否一致 

percona-toolkit

  二、MySQL 中间件代理服务器 1、关系型数据库和 NoSQL 数据库 数据库主要分为两大类：关系型数据库与 NoSQL 数据库。 关系型数据库，是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据。主流的 MySQL、Oracle、MS SQL Server 和 DB2 都属于这类传统数据库。 NoSQL 数据库，全称为 Not Only SQL，意思就是适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。主要分为临时性键 值存储（Redis、memcached）、永久性键值存储（ROMA、Redis）、面向文档的数据库 （MongoDB、CouchDB）、面向列的数据库（Cassandra、HBase），每种 NoSQL 都有其特有的使用场景及优点。 Oracle，mysql 等传统的关系数据库非常成熟并且已大规模商用，为什么还要用 NoSQL 数据库呢？主要是由于随着互联网发展，数据量越来越大，对性能要求越来越高，传统数据库存在着先天性的缺陷， 即单机（单库）性能瓶颈，并且扩展困难。这样既有单机单库瓶颈，却又扩展困难，自然无法满足日益增长的海量数据存储及其性能要求，所以才会出现了各种不同的 NoSQL 产品，NoSQL 根本性的优势在 于在云计算时代，简单、易于大规模分布式扩展，并且读写性能非常高 RDBMS和NOSQL的特点及优缺点：

 2、数据库切分方式

 简单来说，就是指通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库（主机） 上面，以达到分散单台设备负载的效果。 数据的切分（Sharding）根据其切分规则的类型，可以分为两种切分模式。 一种是按照不同的表（或者 Schema）来切分到不同的数据库（主机）之上，这种切可以称之为数据的垂直（纵向）切分；另外一种则是根据 表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分 到多台数据库（主机）上面，这种切分称之为数据的水平（横向）切分。 垂直切分的最大特点就是规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小， 业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不 同的数据库中。 根据不同的表来进行拆分，对应用程序的影响也更小，拆分规则也会比较简单清晰。 水平切分于垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中， 对于应用程序来说，拆分规则本身就较根据表名来拆分更为复杂，后期的数据维护也会更为复杂 一些。 （1）垂直切分

 一个数据库由很多表的构成，每个表对应着不同的业务，垂直切分是指按照业务将表进行分类，分布到不同的数据库上面，这样也就将数据或者说压力分担到不同的库上面，如下图： 

 垂直切分的优缺点：

优点： 　　拆分后业务清晰，拆分规则明确 　　系统之间整合或扩展容易 　　数据维护简单 缺点： 　　部分业务表无法 join，只能通过接口方式解决，提高了系统复杂度 　　受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高 　　事务处理复杂  （2）水平切分

 既然数据做了拆分有优点也就优缺点。

优点： 　　拆分规则抽象良好，join 操作基本都可以数据库完成 　　不存在单库大数据，高并发的性能瓶颈 　　应用端改造较少 　　提高了系统的稳定性跟负载能力 缺点： 　　拆分规则难以抽象 　　分片事务一致性难以解决 　　数据多次扩展难度跟维护量极大 　　跨库 join 性能较差  3、MySQL 中间件各种应用   

 

mysql-proxy：Oracle，https://downloads.mysql.com/archives/proxy/ Atlas：Qihoo，https://github.com/Qihoo360/Atlas/blob/master/README_ZH.md dbproxy：美团，https://github.com/Meituan-Dianping/DBProxy Cetus：网易乐得，https://github.com/Lede-Inc/cetus Amoeba：https://sourceforge.net/projects/amoeba/ Cobar：阿里巴巴，Amoeba的升级版， https://github.com/alibaba/cobar Mycat：基于Cobar http://www.mycat.io/ (原网站) 　　　　　　http://www.mycat.org.cn/ 　　　　　　https://github.com/MyCATApache/Mycat-Server ProxySQL：https://proxysql.com/ MaxScale: 是 MariaDB 开发的一个数据库智能代理服务，允许根据数据库 SQL 语句将请求转向目标一个到多个服务器，可设定各种复杂程度的转向规则。MaxScale 设计用于透明的提供数据库 的负载均衡和高可用性，同时提供高度可伸缩和灵活的架构，支持不同的协议和路由决策。MaxScale 使用 C 语言开发，利用 Linux 下的异步 I/O 功能。使用 epoll 作为事件驱动框架。 https://mariadb.com/kb/en/maxscale/    4、Mycat 　　在整个IT系统架构中，数据库是非常重要，通常又是访问压力较大的一个服务，除了在程序开发的本身做优化，如：SQL语句优化、代码优化，数据库的处理本身优化也是非常重要的。主从、热备、分表分 库等都是系统发展迟早会遇到的技术问题问题。Mycat是一个广受好评的数据库中间件，已经在很多产品上进行使用了。 　　Mycat是一个开源的分布式数据库系统，是一个实现了MySQL协议的服务器，前端用户可以把它看作是一个数据库代理（类似于Mysql Proxy），用MySQL客户端工具和命令行访问，而其后端可以用MySQL 原生协议与多个MySQL服务器通信，也可以用JDBC协议与大多数主流数据库服务器通信，其核心功能是分表分库，即将一个大表水平分割为N个小表，存储在后端MySQL服务器里或者其他数据库里。 　　Mycat发展到目前的版本，已经不是一个单纯的MySQL代理了，它的后端可以支持MySQL、SQLServer、Oracle、DB2、PostgreSQL等主流数据库，也支持MongoDB这种新型NoSQL方式的存储，未 来还会支持更多类型的存储。而在最终用户看来，无论是那种存储方式，在MyCat里，都是一个传统的数据库表，支持标准的SQL语句进行数据的操作，这样一来，对前端业务系统来说，可以大幅降低开发 难度，提升开发速度  Mycat 可以简单概括为 　　一个彻底开源的，面向企业应用开发的大数据库集群 　　支持事务、ACID、可以替代MySQL的加强版数据库 　　一个可以视为MySQL集群的企业级数据库，用来替代昂贵的Oracle集群 　　一个融合内存缓存技术、NoSQL技术、HDFS大数据的新型SQL Server 　　结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品 　　一个新颖的数据库中间件产品 Mycat 官网：http://www.mycat.org.cn/ Mycat工作原理

 （1）mycat安装

下载安装JDK

yum -y install java
#确认安装成功
java -version
openjdk version "1.8.0_201"
OpenJDK Runtime Environment (build 1.8.0_201-b09)
OpenJDK 64-Bit Server VM (build 25.201-b09, mixed mode)

下载安装mycat

wget http://dl.mycat.org.cn/1.6.7.4/Mycat-server-1.6.7.4-release/Mycat-server-
1.6.7.4-release-20200105164103-linux.tar.gz
mkdir /apps
tar xvf Mycat-server-1.6.7.4-release-20200105164103-linux.tar.gz  -C /apps
ls /apps/mycat/
bin catlet conf lib logs version.txt

mycat安装目录结构： 　　bin mycat命令，启动、重启、停止等 　　catlet catlet为Mycat的一个扩展功能 　　conf Mycat 配置信息,重点关注 　　lib Mycat引用的jar包，Mycat是java开发的 　　logs 日志文件，包括Mycat启动的日志和运行的日志 　　version.txt mycat版本说明 logs目录: 　　wrapper.log mycat启动日志 　　mycat.log mycat详细工作日志 Mycat的配置文件都在conf目录里面，这里介绍几个常用的文件： 　　server.xml Mycat软件本身相关的配置文件，设置账号、参数等 　　schema.xml Mycat对应的物理数据库和数据库表的配置,读写分离、高可用、分布式策略定制、 节点控制 　　rule.xml Mycat分片（分库分表）规则配置文件,记录分片规则列表、使用方法等 启动和连接 

#配置环境变量
vim /etc/profile.d/mycat.sh
PATH=/apps/mycat/bin:$PATH
source /etc/profile.d/mycat.sh
#启动
mycat start
#查看日志，确定成功
cat /app/mycat/logs/wrapper.log 
...省略...
INFO   | jvm 1   | 2019/11/01 21:41:02 | MyCAT Server startup successfully. see 
logs in logs/mycat.log
#连接mycat：
mysql -uroot -p123456 -h 127.0.0.1 -P8066

（2）Mycat 主要配置文件说明 

server.xml 存放Mycat软件本身相关的配置文件，比如：连接Mycat的用户，密码，数据库名称等 server.xml文件中配置的参数解释说明：  　　user 用户配置节点 　　name 客户端登录MyCAT的用户名，也就是客户端用来连接Mycat的用户名。 　　password 客户端登录MyCAT的密码 　　schemas 数据库名，这里会和schema.xml中的配置关联，多个用逗号分开，例如:db1,db2 　　privileges 配置用户针对表的增删改查的权限 　　readOnly mycat逻辑库所具有的权限。true为只读，false为读写都有，默认为false schema.xml 是最主要的配置项，此文件关联mysql读写分离策略，读写分离、分库分表策略、分片节点都是在此文件中配置的.MyCat作为中间件，它只是一个代理，本身并不进行数据存储，需要连接后端的MySQL物 理服务器，此文件就是用来连接MySQL服务器的schema.xml文件中配置的参数解释说明： 参数 说明 　　schema 数据库设置，此数据库为逻辑数据库，name与server.xml中schema对应 　　dataNode 分片信息，也就是分库相关配置 　　dataHost 物理数据库，真正存储数据的数据库 配置说明 　　name属性唯一标识dataHost标签，供上层的标签使用。 　　maxCon属性指定每个读写实例连接池的最大连接。也就是说，标签内嵌套的writeHost、readHost标签都会使用这个属性的值来实例化出连接池的最大连接数 　　minCon属性指定每个读写实例连接池的最小连接，初始化连接池的大小    5、ProxySQL  （1）ProxySQL 介绍  ProxySQL： MySQL中间件 两个版本：官方版和percona版，percona版是基于官方版基础上修改 C++语言开发，轻量级但性能优异，支持处理千亿级数据 具有中间件所需的绝大多数功能，包括： 　　多种方式的读/写分离 　　定制基于用户、基于schema、基于语句的规则对SQL语句进行路由 　　缓存查询结果 　　后端节点监控 官方站点：https://proxysql.com/ 官方手册：https://github.com/sysown/proxysql/wiki  （2）ProxySQL 安装

cat <<EOF | tee /etc/yum.repos.d/proxysql.repo
[proxysql_repo]
name= ProxySQL YUM repository
baseurl=http://repo.proxysql.com/ProxySQL/proxysql-1.4.x/centos/\$releasever
gpgcheck=1
gpgkey=http://repo.proxysql.com/ProxySQL/repo_pub_key
EOF
#基于RPM下载安装：https://github.com/sysown/proxysql/releases
yum install proxysql

ProxySQL组成 　　服务脚本：/etc/init.d/proxysql 　　配置文件：/etc/proxysql.cnf 　　主程序：/usr/bin/proxysql 　　基于SQLITE的数据库文件：/var/lib/proxysql/ 启动ProxySQL： 

service proxysql start

启动后会监听两个默认端口 　　6032：ProxySQL的管理端口 　　6033：ProxySQL对外提供服务的端口 连接ProxySQL的管理端口 使用mysql客户端连接到ProxySQL的管理接口6032，默认管理员用户和密码都是admin： 

mysql -uadmin -padmin -P6032 -h127.0.0.1

数据库说明： 　　main 是默认的"数据库"名，表里存放后端db实例、用户验证、路由规则等信息。表名以 runtime开头的表示 　　proxysql当前运行的配置内容，不能通过dml语句修改，只能修改对应的不以 runtime_ 开头的（在内存）里的表，然后 LOAD 使其生效， SAVE 使其存到硬盘以供下次重启加载 　　disk 是持久化到硬盘的配置，sqlite数据文件 　　stats 是proxysql运行抓取的统计信息，包括到后端各命令的执行次数、流量、processlist、查询种类汇总/执行时间，等等 　　monitor 库存储 monitor 模块收集的信息，主要是对后端db的健康/延迟检查 说明： 　　在main和monitor数据库中的表， runtime开头的是运行时的配置，不能修改，只能修改非runtime表 　　修改后必须执行LOAD … TO RUNTIME才能加载到RUNTIME生效 　　执行save … to disk 才将配置持久化保存到磁盘，即保存在proxysql.db文件中 　　global_variables 有许多变量可以设置，其中就包括监听的端口、管理账号等 　　参考: https://github.com/sysown/proxysql/wiki/Global-variables    三、MySQL 高可用  1、 MySQL 高可用解决方案  MySQL官方和社区里推出了很多高可用的解决方案，大体如下，仅供参考（数据引用自Percona） 

 MMM: Multi-Master Replication Manager for MySQL，Mysql主主复制管理器是一套灵活的脚本程序，基于perl实现，用来对mysql replication进行监控和故障迁移，并能管理mysql Master-Master复制的配置(同一时间只有一个节点是可写的)

官网： http://www.mysql-mmm.org 　　　　https://code.google.com/archive/p/mysql-master-master/downloads MHA：Master High Availability，对主节点进行监控，可实现自动故障转移至其它从节点；通过提升某一从节点为新的主节点，基于主从复制实现，还需要客户端配合实现，目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，出于机器成本的考虑，淘宝进行了 改造，目前淘宝TMHA已经支持一主一从 官方网站：https://code.google.com/archive/p/mysql-master-ha/ 　　　　https://github.com/yoshinorim/mha4mysql-manager/wiki/Downloads 　　　　https://github.com/yoshinorim/mha4mysql-manager/releases 　　　　https://github.com/yoshinorim/mha4mysql-node/releases/tag/v0.58  以下技术可以达到金融级的高可用性要求 　　Galera Cluster：wsrep(MySQL extended with the Write Set Replication)　　通过wsrep协议在全局实现复制；任何一节点都可读写，不需要主从复制，实现多主读写 　　GR（Group Replication）：MySQL官方提供的组复制技术(MySQL 5.7.17引入的技术)，基于原生复制技术Paxos算法，实现了多主更新，复制组由多个server成员构成，组中的每个server可独立地执行事务，但所有读写事务只在冲突检测成功后才会提交   2、MHA Master High Availability （1）工作原理 　　　　1. MHA利用 SELECT 1 As Value 指令判断master服务器的健康性,一旦master 宕机,MHA 从宕机崩 溃的master保存二进制日志事件（binlog events） 　　　　2. 识别含有最新更新的slave 　　　　3. 应用差异的中继日志（relay log）到其他的slave 　　　　4. 应用从master保存的二进制日志事件（binlog events）到所有slave节点 　　　　5. 提升一个slave为新的master 　　　　6. 使其他的slave连接新的master进行复制 　　　　7. 故障服务器自动被剔除集群(masterha_conf_host),将配置信息去掉 　　　　8. 旧的Master的 VIP 漂移到新的master上，用户应用就可以访问新的Master 　　　　9. MHA是一次性的高可用性解决方案,Manager会自动退出 （2）选举新的Master 　　如果设定权重(candidate_master=1),按照权重强制指定新主,但是默认情况下如果一个slave落后 master 二进制日志超过100M的relay logs，即使有权重,也会失效.如果设置check_repl_delay=0,即使落后很多日志,也强制选择其为新主 　　如果从库数据之间有差异,最接近于Master的slave成为新主 　　如果所有从库数据都一致,按照配置文件顺序最前面的当新主  （3）数据恢复 　　当主服务器的SSH还能连接,从库对比主库position 或者GTID号,将二进制日志保存至各个从节点并且应用(执行save_binary_logs 实现) 　　当主服务器的SSH不能连接, 对比从库之间的relaylog的差异(执行apply_diff_relay_logs[实现])  

 3、Galera Cluster

 Galera Cluster：集成了Galera插件的MySQL集群，是一种新型的，数据不共享的，高度冗余的高可用方案，目前Galera Cluster有两个版本，分别是Percona Xtradb Cluster及MariaDB Cluster，Galera本 身是具有多主特性的，即采用multi-master的集群架构，是一个既稳健，又在数据一致性、完整性及高性能方面有出色表现的高可用解决方案 Galera Cluster特点 　　多主架构：真正的多点读写的集群，在任何时候读写数据，都是最新的 　　同步复制：改善了主从复制延迟问题，基本上达到了实时同步 　　并发复制：从节点APPLY数据时，支持并行执行，更好的性能 　　故障切换：在出现数据库故障时，因支持多点写入，切换容易 　　热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务时间就会非常少。在节点故障期间，节点本身对集群的影响非常小  　　自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不需要人工手动备份提供，Galera Cluster会自动拉取在线节点数据，最终集群会变为一致 　　对应用透明：集群的维护，对应用程序是透明的 Galera Cluster 缺点 任何更新的事务都需要全局验证通过，才会在其他节点上执行，则集群性能由集群中最差性能节点决定（一般集群节点配置都是一样的） 新节点加入或延后较大的节点重新加入需全量拷贝数据(SST，State Snapshot Transfer),作为donor( 贡献者，如： 同步数据时的提供者)的节点在同步过程中无法提供读写 只支持innodb存储引擎的表 Galera Cluster工作过程

 

Galera Cluster 包括两个组件 　　Galera replication library (galera-3) 　　WSREP：MySQL extended with the Write Set Replication WSREP复制实现： 　　PXC：Percona XtraDB Cluster，是Percona对Galera的实现 参考仓库： 　　https://mirrors.tuna.tsinghua.edu.cn/percona/release/$releasever/RPMS/$basearch  MariaDB Galera Cluster： 　　https://mirrors.tuna.tsinghua.edu.cn/mariadb/mariadb-5.5.X/yum/centos7-amd64/   PXC 原理 　　 　　

 PXC最常使用如下4个端口号：

　　3306：数据库对外服务的端口号 　　4444：请求SST的端口号 　　4567：组成员之间进行沟通的端口号 　　4568：用于传输IST的端口号  PXC中涉及到的重要概念和核心参数： （1）集群中节点的数量：整个集群中节点数量应该控制在最少3个、最多8个的范围内。最少3个节点是 为了防止出现脑裂现象，因为只有在2个节点下才会出现此现象。脑裂现象的标志就是输入任何命令， 返回的结果都是unknown command。节点在集群中，会因新节点的加入或故障、同步失效等原因发 生状态的切换。 （2）节点状态的变化阶段： 　　open：节点启动成功，尝试连接到集群时的状态 　　primary：节点已处于集群中，在新节点加入并选取donor进行数据同步时的状态 　　joiner：节点处于等待接收同步文件时的状态 　　joined：节点完成数据同步工作，尝试保持和集群进度一致时的状态 　　synced：节点正常提供服务时的状态，表示已经同步完成并和集群进度保持一致 　　donor：节点处于为新加入的节点提供全量数据时的状态 （3）节点的数据传输方式： 　　SST：State Snapshot Transfer，全量数据传输 　　IST：Incremental State Transfer，增量数据传输 　　SST数据传输有xtrabackup、mysqldump和rsync三种方式，而增量数据传输就只有一种方式 　　xtrabackup，但生产环境中一般数据量较小时，可以使用SST全量数据传输，但也只使用xtrabackup方法。 （4）GCache模块：在PXC中一个特别重要的模块，它的核心功能就是为每个节点缓存当前最新的写集。如果有新节点加入进来，就可以把新数据的增量传递给新节点，而不需要再使用SST传输方式，这 样可以让节点更快地加入集群中， 涉及如下参数： 　　gcache.size：缓存写集增量信息的大小，它的默认大小是128MB，通过wsrep_provider_options参数设置，建议调整为2GB~4GB范围，足够的空间便于缓存更多的增量信息。 　　gcache.mem_size：GCache中内存缓存的大小，适度调大可以提高整个集群的性能 　　gcache.page_size：如果内存不够用（GCache不足），就直接将写集写入磁盘文件中 （5）在各个节点上分别配置mysql及集群配置文件 /etc/my.cnf为主配置文件，当前版本中，其余的配置文件都放在/etc/percona-xtradb-cluster.conf.d目录里，包括mysqld.cnf，mysqld_safe.cnf，wsrep.cnf 三个文件 配置文件各项配置意义

 

 4、TiDB 概述   TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。 TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB和MySQL几乎完全兼容  TiDB 是一个分布式 NewSQL 数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数 据库。TiDB年可用性达到99.95% TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场 景提供一站式的解决方案。 （1）TiDB 核心特点 1. 高度兼容 MySQL 大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的MySQL 集群亦可通过 TiDB 工具进行实时迁移 2. 水平弹性扩展 通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景 3. 分布式事务 TiDB 100% 支持标准的 ACID 事务 4. 真正金融级高可用 相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可实现故障的自动恢复 (auto-failover)，无需人工介入 5. 一站式 HTAP 解决方案 TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合TiSpark，可提供一站式 HTAP解决方案，一份存储同时处理OLTP & OLAP(OLAP、OLTP的介绍和比较 )无需传统繁琐的 ETL 过程 6. 云原生 SQL 数据库 TiDB 是为云而设计的数据库，同 Kubernetes 深度耦合，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。TiDB 的设计目标是 100% 的 OLTP 场景和 80%的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。 TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力 （2）TiDB整体架构 TiDB Server

TiDB Server 负责接收SQL请求，处理SQL相关的逻辑，并通过PD找到存储计算所需数据的TiKV地址，

与TiKV交互获取数据，最终返回结果。TiDB Server 是无状态的，其本身并不存储数据，只负责计算， 可以无限水平扩展，可以通过负载均衡组件（LVS、HAProxy或F5）对外提供统一的接入地址。 PD Server Placement Driver（简称PD）是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息 （某个Key存储在那个TiKV节点）；二是对TiKV集群进行调度和负载均衡（如数据的迁移、Raft group leader的迁移等）；三是分配全局唯一且递增的事务ID PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署3个节点。PD在选举的过程中无法对外 提供服务，这个时间大约是3秒 TiKV Server TiKV Server 负责存储数据，从外部看TiKV是一个分布式的提供事务的Key-Value存储引擎。存储数据的 基本单位是Region，每个Region负责存储一个Key Range（从StartKey到EndKey的左闭右开区间）的 数据，每个TiKV节点会负责多个Region。TiKV使用Raft协议做复制，保持数据的一致性和容灾。副本以 Region为单位进行管理，不同节点上的多个Region构成一个Raft Group，互为副本。数据在多个TiKV 之间的负载均衡由PD调度，这里也就是以Region为单位进行调度    四、压力测试 1、压力测试工具  （1）常见 MySQL 压力测试工具  mysqlslap Sysbench：功能强大，官网： https://github.com/akopytov/sysbench tpcc-mysql MySQL Benchmark Suite MySQL super-smack MyBench  （2）mysqlslap mysqlslap：来自于mysql或mariadb包，测试的过程默认生成一个mysqlslap的schema,生成测试表 t1，查询和插入测试数据，mysqlslap库自动生成，如果已经存在则先删除。用--only-print来打印实际 的测试过程，整个测试完成后不会在数据库中留下痕迹 使用格式：

mysqlslap [options]

2、MySQL配置最佳实践

高并发大数据的互联网业务，架构设计思路是"解放数据库CPU，将计算转移到服务层"，并发量大的情况下，这些功能很可能将数据库拖死，业务逻辑放到服务层具备更好的扩展性，能够轻易实现"增机器 就加性能" 参考资料： 阿里巴巴Java开发手册：https://developer.aliyun.com/topic/java2020 58到家数据库30条军规解读：http://zhuanlan.51cto.com/art/201702/531364.htm 以下规范适用场景：并发量大、数据量大的互联网业务  基础规范 (1)必须使用InnoDB存储引擎 解读：支持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高 (2)使用UTF8MB4字符集 解读：万国码，无需转码，无乱码风险，节省空间，支持表情包及生僻字 (3)数据表、数据字段必须加入中文注释 解读：N年后谁知道这个r1,r2,r3字段是干嘛的 (4)禁止使用存储过程、视图、触发器、Event 解读：高并发大数据的互联网业务，架构设计思路是"解放数据库CPU，将计算转移到服务层"，并发量大的情况下，这些功能很可能将数据库拖死，业务逻辑放到服务层具备更好的扩展性，能够轻易实 现"增机器就加性能"。数据库擅长存储与索引，CPU计算还是上移吧！ (5)禁止存储大文件或者大照片 解读：为何要让数据库做它不擅长的事情?大文件和照片存储在文件系统，数据库里存URI多好。 等等。。。    

标签：log,第二十三,数据库,MySQL,Cluster,复制,master,MYSQL,节点
From： https://www.cnblogs.com/dujy/p/18017724