#MySQL主从
文章目录
##GTID主从
###GTID概念介绍
GTID 即全局事务ID（global transaction identifier）, 其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的 ID 。GTID 最初由 google 实现，官方 MySQL 在 5.6 才加入该功能。mysql 主从结构在一主一从情况下对于 GTID 来说就没有优势了，而对于 2 台主以上的结构优势异常明显，可以在数据不丢失的情况下切换新主。使用 GTID 需要注意: 在构建主从复制之前，在一台将成为主的实例上进行一些操作（如数据清理等），通过 GTID 复制，这些在主从成立之前的操作也会被复制到从服务器上，引起复制失败。也就是说通过 GTID 复制都是从最先开始的事务日志开始，即使这些操作在复制之前执行。比如在 server1 上执行一些 drop、delete 的清理操作，接着在 server2 上执行 change 的操作，会使得 server2 也进行 server1 的清理操作。
GTID 实际上是由 UUID + TID（即 transactionId）组成的。其中 UUID（即server_uuid） 产生于 auto.conf 文件（cat /data/mysql/data/auto.cnf），是一个 MySQL 实例的唯一标识。TID 代表了该实例上已经提交的事务数量，并且随着事务提交单调递增，所以 GTID 能够保证每个 MySQL 实例事务的执行（不会重复执行同一个事务，并且会补全没有执行的事务）。GTID 在一组复制中，全局唯一
如图, Server1(Maste) 崩溃，根据从上 show slave status 获得 Master_log_File/Read_Master_Log_Pos的值，Server2(Slave) 已经跟上了主，Server3(Slave) 没有跟上主。这时要是把 Server2 提升为主，Server3 变成 Server2 的从。这时在 Server3 上执行 change 的时候需要做一些计算。
这个问题在 5.6 的 GTID 出现后，就显得非常的简单。由于同一事务的 GTID 在所有节点上的值一致，那么根据 Server3 当前停止点的 GTID 就能定位到 Server2 上的 GTID 。甚至由于 MASTER_AUTO_POSITION 功能的出现，我们都不需要知道 GTID 的具体值，直接使用 CHANGE MASTER TO MASTER_HOST=‘xxx’, MASTER_AUTO_POSITION 命令就可以直接完成 failover 的工作。
Previous_gtid_log_event
Previous_gtid_log_event 在每个 binlog 头部都会有每次 binlog rotate 的时候存储在 binlog 头部 Previous-GTIDs 在 binlog 中只会存储在这台机器上执行过的所有 binlog ，不包括手动设置 gtid_purged 值。换句话说，如果你手动 set global gtid_purged=xx； 那么 xx 是不会记录在 Previous_gtid_log_event 中的。
GTID 和 Binlog 之间的关系是怎么对应的呢? 如何才能找到 GTID=? 对应的 binlog 文件呢？
假设有4个 binlog: bin.001,bin.002,bin.003,bin.004
bin.001 : Previous-GTIDs=empty; binlog_event有: 1-40
bin.002 : Previous-GTIDs=1-40; binlog_event有: 41-80
bin.003 : Previous-GTIDs=1-80; binlog_event有: 81-120
bin.004 : Previous-GTIDs=1-120; binlog_event有: 121-160
假设现在我们要找 GTID=$A，那么 MySQL 的扫描顺序为:
从最后一个 binlog 开始扫描（即: bin.004）
bin.004 的 Previous-GTIDs=1-120，如果 $A=140 > Previous-GTIDs，那么肯定在bin.004 中
bin.004 的 Previous-GTIDs=1-120，如果 $A=88 包含在 Previous-GTIDs 中，那么继续对比上一个 binlog 文件 bin.003，然后再循环前面2个步骤，直到找到为止.
gtid_mode=on (必选)
enforce-gtid-consistency=1 （必选）
log_bin=mysql-bin （可选） #高可用切换，最好开启该功能
log-slave-updates=1 （可选） #高可用切换，最好打开该功能
###GTID工作原理
从服务器连接到主服务器之后，把自己执行过的 GTID（Executed_Gtid_Set：即已经执行的事务编码）、获取到的 GTID（Retrieved_Gtid_Set：即从库已经接收到主库的事务编号）发给主服务器，主服务器把从服务器缺少的 GTID 及对应的 transactions 发过去补全即可。当主服务器挂掉的时候，找出同步最成功的那台从服务器，直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主， 先 change 到同步最成功的那台从服务器， 等把 GTID 全部补全了，就可以把它提升为主了。
GTID 是 MySQL 5.6 的新特性，可简化 MySQL 的主从切换以及 Failover 。GTID 用于在 binlog 中唯一标识一个事务。当事务提交时，MySQL Server 在写 binlog 的时候，会先写一个特殊的 Binlog Event ，类型为 GTID_Event ，指定下一个事务的 GTID ，然后再写事务的 Binlog 。主从同步时 GTID_Event 和事务的 Binlog 都会传递到从库，从库在执行的时候也是用同样的 GTID 写 binlog ，这样主从同步以后，就可通过 GTID 确定从库同步到的位置了。也就是说，无论是级联情况，还是一主多从情况，都可以通过 GTID 自动找点儿，而无需像之前那样通过 File_name 和 File_position 找点儿了。
简而言之，GTID 的工作流程为：
从服务器连接到主服务器之后，把自己执行过的 GTID（Executed_Gtid_Set：即已经执行的事务编码）、获取到的 GTID（Retrieved_Gtid_Set：即从库已经接收到主库的事务编号）发给主服务器，主服务器把从服务器缺少的 GTID 及对应的 transactions 发过去补全即可。当主服务器挂掉的时候，找出同步最成功的那台从服务器，直接把它提升为主即可。如果硬要指定某一台不是最新的从服务器提升为主， 先 change 到同步最成功的那台从服务器， 等把 GTID 全部补全了，就可以把它提升为主了。
GTID 是 MySQL 5.6 的新特性，可简化 MySQL 的主从切换以及 Failover 。GTID 用于在 binlog 中唯一标识一个事务。当事务提交时，MySQL Server 在写 binlog 的时候，会先写一个特殊的 Binlog Event ，类型为 GTID_Event ，指定下一个事务的 GTID ，然后再写事务的 Binlog 。主从同步时 GTID_Event 和事务的 Binlog 都会传递到从库，从库在执行的时候也是用同样的 GTID 写 binlog ，这样主从同步以后，就可通过 GTID 确定从库同步到的位置了。也就是说，无论是级联情况，还是一主多从情况，都可以通过 GTID 自动找点儿，而无需像之前那样通过 File_name 和 File_position 找点儿了。
简而言之，GTID 的工作流程为：
###GTID主从配置
库配置。vi /etc/my.cnf，添加以下配置，重启 mysql，关闭防火墙。
log-bin=130
server-id=10
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on
[root@130 ~]# systemctl restart mysqld
[root@130 ~]# systemctl stop firewalld
[root@130 ~]# setenforce 0
从库配置。vi /etc/my.cnf，添加以下配置，重启 mysql，关闭防火墙。
server-id=20
relay-log=myrelay
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on
read_only=on
master-info-repository=TABLE
relay-log-info-repository=TABLE
[root@131 ~]# systemctl restart mysqld
[root@131 ~]# systemctl stop firewalld
[root@131 ~]# setenforce 0
主库授权复制用户。
mysql> grant replication slave on *.* to 'abc'@'%' identified by '123456';
Query OK, 0 rows affected, 1 warning (0.02 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
mysql> show master status;
+------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------+----------+--------------+------------------+------------------------------------------+
| 128.000001 | 588 | | | 95cb821b-0cca-11ed-8584-000c295e7eb4:1-2 |
+------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec)
从库设置要同步的主库信息，并开启同步。
mysql> change master to master_host='192.168.17.131',master_port=3306,master_user='abc',master_password='123456',master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.02 sec)
mysql> start slave;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.91.128
Master_User: abc
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: 128.000001
Read_Master_Log_Pos: 588
Relay_Log_File: myrelay.000002
Relay_Log_Pos: 789
Relay_Master_Log_File: 128.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
.................................
配置完之后，通过查看 slave 的状态，可以看是否配置成功。同时可以在主库进行一些操作，提交一些事务（insert，update），之后数据就会自动同步到从库。
##http协议
状态码
##lamp简介
所谓lamp，其实就是由Linux+Apache+Mysql/MariaDB+Php/Perl/Python的一组动态网站或者服务器的开源软件，除Linux外其它各部件本身都是各自独立的程序，但是因为经常被放在一起使用，拥有了越来越高的兼容度，共同组成了一个强大的Web应用程序平台。
##web服务器工作流程
web服务器的资源分为两种，静态资源和动态资源
静态资源就是指静态内容，客户端从服务器获得的资源的表现形式与原文件相同。可以简单的理解为就是直接存储于文件系统中的资源
动态资源则通常是程序文件，需要在服务器执行之后，将执行的结果返回给客户端
如上图所示
阶段①显示的是 httpd 服务器（即 apache）和 php 服务器通过 FastCGI 协议进行通信，且 php 作为独立的服务进程运行。
阶段②显示的是 php 程序和 mysq l数据库间通过 mysql 协议进行通信。php 与 mysql 本没有什么联系，但是由 php 语言写成的程序可以与 mysql 进行数据交互。同理 perl 和 python 写的程序也可以与 mysql 数据库进行交互。
##CGI 与 FastCGI
CGI（Common Gateway Interface，通用网关接口），CGI 是外部应用程序（CGI 程序）与 web 服务器之间的接口标准，是在 CGI 程序和 web 服务器之间传递信息的过程。CGI 规范允许 web 服务器执行外部程序，并将它们的输出发送给 web 浏览器，CGI 将 web 的一组简单的静态超媒体文档变成一个完整的新的交互式媒体。
FastCGI（Fast Common Gateway Interface）是 CGI 的改良版，CGI 是通过启用一个解释器进程来处理每个请求，耗时且耗资源，而 FastCGI 则是通过 master-worker 形式来处理每个请求，即启动一个 master 主进程，然后根据配置启动几个 worker 进程，当请求进来时，master 会从 worke r进程中选择一个去处理请求，这样就避免了重复的生成和杀死进程带来的频繁 CPU 上下文切换而导致耗时。
##httpd 与 php 结合的方式
httpd 与 php 结合的方式有以下三种：
modules：php 将以 httpd 的扩展模块形式存在，需要加载动态资源时，httpd 可以直接通过 php 模块来加工资源并返回给客户端
httpd prefork：libphp5.so（多进程模型的 php）
httpd event or worker：libphp5-zts.so（线程模型的php）
CGI：httpd 需要加载动态资源时，通过 CGI 与 php 解释器联系，获得 php 执行的结果，此时 httpd 负责与 php 连接的建立和断开等
FastCGI：利用 php-fpm 机制，启动为服务进程，php 自行运行为一个服务，https 通过 socket 与 php 通信
较于 CGI 方式，FastCGI 更为常用，很少有人使用 CGI 方式来加载动态资源。
扫一扫
353
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
