Linux的企业-Mysql日志，读写分离，组的复制，高可用MHA（2）-CSDN博客

接上一篇

五.Mysql数据库的日志

Mysql日志的配置

MySQL有以下几种日志：

    错误日志： -log-err
    查询日志： -log
    慢查询日志: -log-slow-queries
    更新日志: -log-update
    二进制日志： -log-bin

默认情况下，所有日志创建于mysqld数据目录中。通过刷新日志，你可以强制 mysqld来关闭和重新打开日志文件（或者在某些情况下切换到一个新的日志）。当你执行一个FLUSH LOGS语句或执行mysqladmin flush-logs或mysqladmin refresh时，出现日志刷新

1. 错误日志

用--log-error[=file_name]选项来指定mysqld保存错误日志文件的位置。如果没有给定file_name值，mysqld使用错误日志名 host_name.err并在数据目录中写入日志文件。如果你执行FLUSH LOGS，错误日志用-old重新命名后缀并且mysqld创建一个新的空日志文件。(如果未给出--log-error选项，则不会重新命名）。
如果不指定--log-error，或者(在Windows中)如果你使用--console选项，错误被写入标准错误输出stderr。通常标准输出为你的终端。
2. 通用查询日志

用--log[=file_name]或-l [file_name]选项启动它。如果没有给定file_name的值，默认名是host_name.log。
3. 慢速查询日志

用--log-slow-queries[=file_name]选项启动时，mysqld 写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件.如果没有给出file_name值，默认未主机名，后缀为 -slow.log。如果给出了文件名，但不是绝对路径名，文件则写入数据目录。
4. 更新日志

用--log-update[=file_name]选项启动,不推荐使用.

5.指定位置恢复日志

6.指定时间恢复日志

7.提取二进制日志

六.Mysql的读写分离

1.在server4上安装配置MySQL-Proxy服务端

[mysql-proxy]
user=root #运行mysql-proxy用户
admin-username=admin #主从mysql共有的用户
admin-password=westos #用户的密码
proxy-address=172.25.29.4:3306 #mysql-proxy运行ip和端口，不加端口，默认4040
proxy-read-only-backend-addresses=172.25.29.3 :3306#指定后端从slave读取数据
proxy-backend-addresses=172.25.29.2 :3306 #指定后端主master写入数据
proxy-lua-script=/usr/local/mysql-proxy/share/doc/mysql-proxy/lua/rw-splitting.lua #指定读写分离配置文件位置
admin-lua-script=/usr/local/mysql-proxy/lib/mysql-proxy/lua/admin-sql.lua #指定管理脚本
log-file=/usr/local/mysql-proxy/logs/mysql-proxy.log #日志位置
log-level=debug #定义log日志级别，由高到低分别有(error|warning|info|message|debug)
daemon=true #以守护进程方式运行
keepalive=true #mysql-proxy崩溃时，尝试重启

为方便测试将最大值设置为2，最小值为1

端口开启正常

server3上的主从复制正常

2.测试读写分离

授权ajc用户只能插入、更新

远程用admin在客户机测试，显示后端

2主写

3从读

测试：mysql远程登陆server4 mysql-proxy代理服务器

创建数据

3.用tcpdump在server4分析数据流向

数据流向server4，又从server4流向server2

多登陆几次，触发最大连接数2

再次查看eth0 3306端口情况，数据流向server3

触发最大连接次数2后，后端服务的type状态

4.用lsof工具在server4分析数据流向

lsof（list open files）是一个列出当前系统打开文件的工具。在linux环境下，任何事物都以文件的形式存在，通过文件不仅仅可以访问常规数据，还可以访问网络连接和硬件。所以如传输控制协议 (TCP) 和用户数据报协议 (UDP) 套接字等，系统在后台都为该应用程序分配了一个文件描述符，无论这个文件的本质如何，该文件描述符为应用程序与基础操作系统之间的交互提供了通用接口。因为应用程序打开文件的描述符列表提供了大量关于这个应用程序本身的信息，因此通过lsof工具能够查看这个列表对系统监测以及排错将是很有帮助的。

七.组复制

1.组复制介绍

基于组的复制（Group-based Replication）是一种被使用在容错系统中的技术。Replication-group（复制组）是由能够相互通信的多个服务器（节点）组成的。

在通信层，Group replication实现了一系列的机制：比如原子消息（atomic message delivery）和全序化消息（totalordering of messages）。

这些原子化，抽象化的机制，为实现更先进的数据库复制方案提供了强有力的支持。

MySQL Group Replication正是基于这些技术和概念，实现了一种多主全更新的复制协议。

简而言之，一个Replication-group就是一组节点，每个节点都可以独立执行事务，而读写事务则会在于group内的其他节点进行协调之后再commit。

因此，当一个事务准备提交时，会自动在group内进行原子性的广播，告知其他节点变更了什么内容/执行了什么事务。

这种原子广播的方式，使得这个事务在每一个节点上都保持着同样顺序。

这意味着每一个节点都以同样的顺序，接收到了同样的事务日志，所以每一个节点以同样的顺序重演了这些事务日志，最终整个group保持了完全一致的状态。

然而，不同的节点上执行的事务之间有可能存在资源争用。这种现象容易出现在两个不同的并发事务上。

假设在不同的节点上有两个并发事务，更新了同一行数据，那么就会发生资源争用。

面对这种情况，Group Replication判定先提交的事务为有效事务，会在整个group里面重演，后提交的事务会直接中断，或者回滚，最后丢弃掉。

因此，这也是一个无共享的复制方案，每一个节点都保存了完整的数据副本。看如下图片01.png，描述了具体的工作流程，能够简洁的和其他方案进行对比。这个复制方案，在某种程度上，和数据库状态机（DBSM）的Replication方法比较类似。

2.配置（参照www.mysql.com官方文档）

做之前使用3台虚拟机

server2、server3、server4

确保配置好主从同步

mysql版本5.7.19

(1)配置好三台主机的主从同步

server2：

server3：

server4：

主从复制配置完成，server2为主

(2)按照官方文档配置三台主机的组复制

server2设置：

server3配置：

server4配置：

3.配置完成3台主机的组复制，测试

在server2上写入数据

server3同时写入

server4同时写入

八.MHA数据库高可用

1.简介

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

该软件由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。

在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以大大降低数据丢失的风险。MHA可以与半同步复制结合起来。如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。