GTID主从

#GTID主从

mysql> show master status;
+-----------+----------+--------------+------------------+---------------
----------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_
Set |
+-----------+----------+--------------+------------------+---------------
----------------------------+
| on.000003 | 187 | | | 7286f791-125d11e9-9a9c-0050568843f8:1-362|
+-----------+----------+--------------+------------------+---------------
----------------------------+
1 row in set (0.00 sec)
GTID:7286f791-125d-11e9-9a9c-0050568843f8:1-362
UUID:7286f791-125d-11e9-9a9c-0050568843f8
transactionId:1-362

在整个复制架构中GTID 是不变化的,即使在多个连环主从中也不会变。
例如：ServerA —>ServerB —­>ServerC
GTID从在ServerA ,ServerB,ServerC 中都是一样的。
了解了GTID的格式，通过UUID可以知道这个事务在哪个实例上提交的。通过GTID可以极方便的进
行复制结构上的故障转移，新主设置，这就很好地解决了下面这个图所展现出来的问题。
如图, Server1(Master)崩溃，根据从上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的工
作。
GTID和Binlog的关系
GTID在binlog中的结构
GTID event 结构
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 重要参数的持久化
GTID相关参数
参数 comment
gtid_executed 执行过的所有GTID
gtid_purged 丢弃掉的GTID
gtid_mode GTID模式
gtid_next session级别的变量，下一个gtid
gtid_owned 正在运行的GTID
enforce_gtid_consistency 保证GTID安全的参数
开启GTID的必备条件
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的工作流程为：
master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
slave端的i/o 线程将变更的binlog，写入到本地的relay log中。
sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
如果有记录，说明该GTID的事务已经执行，slave会忽略。
如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。
###GTID主从配置
环境说明：
数据库角色 IP 主机名 应用与系统版本
主数据库 192.168.87.128 zzz centos8/redhat8mysql­5.7
从数据库 192.168.87.129 localhost centos8/redhat8mysql­5.7
注意在配置是首先关闭防火墙
1.主库配置：
在/etc/my.cnf添加一下配置，重启mysql

log-bin=mysql_bin
server-id=10
gtid_mode=on
enforce-gtid-consistency=true
log-slave-updates=on
[root@localhost ~]# systemctl restart mysqld 重启

2.从库配置。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@localhost ~]# systemctl restart mysqld

3.主库授权复制用户

mysql> set global validate_password_policy=0;
Query OK, 0 rows affected (0.00 sec)
mysql> set global validate_password_length=1;
Query OK, 0 rows affected (0.00 sec)
mysql> grant replication slave on *.* to 'zbc'@'%' identified by '@123';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql>

4.从库设置主从同步

mysql> change master to
-> master_host='192.168.87.128',
-> master_port=3306,
-> master_user='zbc',
-> master_password='@123',
-> master_auto_position=1;
Query OK, 0 rows affected, 2 warnings (0.01 sec)
mysql> start slave
-> ;
Query OK, 0 rows affected (0.01 sec)
mysql>
mysql> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.87.128
Master_User: zbc
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql_bin.000002
Read_Master_Log_Pos: 194
Relay_Log_File: myrelay.000005
Relay_Log_Pos: 407
Relay_Master_Log_File: mysql_bin.000002
Slave_IO_Running: Yes 必须是yes
Slave_SQL_Running: Yes 必须是yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:

如果不是如上是两个yes ，可以检查一下授权用户或者防火墙（主从的防火墙都要关）
5.检查效果：在主数据库上创建一个数据库

主数据库
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| zuoye |
+--------------------+
5 rows in set (0.01 sec)
mysql>
从数据库上
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| zuoye |
+--------------------+
5 rows in set (0.00 sec)
mysql>

###http协议
http(超文本传输协议)，它其实就是应用层的一种通信工具。当两个客户端通信的时候，那么这就需
要一个协议来进行沟通。
http协议永远都是客户端发起请求浏览器进行响应。
http的端口号 80 HTTPS的端口是443
那么在上网的时候如何请求的？
当我们客户端点击一个URL地址的时候，会给浏览器一个请求，根据请求，服务器会给一个响应，
如果不出错的话。就会把浏览器所给的信息在客户端上进行显示出来。如果错误的话就会把错误的
信息，在客户端上显示出来。
http工作：
一个http就相当于一个事物。
客户端与服务器建立链接，当我们点击一个超链接的时候，http就已经开始工作了
会给浏览器一个请求
通过请求，形成一个响应的状态
通过响应的状态来输出你所想输出的东西
在请求的时候：请求结构有三部分组成 请求行 消息报头 请求正文
同样，在响应的时候也是有三部分组成 状态行 消息报头 状态正文
上边也说了。状态
一般状态码分为5类
1×× 请求数据已经发送完成
2×× 请求的数据已经处理完毕 例如 200
3×× 重定向的一些错误 例如 302 303.。。。
4×× 在浏览器请求的时候所报的一些错误
5×× 在客户端所发送的一些错，从而导致数据出不来。
lamp架构运行的原理
###LAMP的架构：
LAMP是一个多C/S架构的平台，最初级为web客户端基于TCP/IP通过http协议发起传送，这个
请求可能是动态的，也可能是静态的。 所以web服务器通过发起请求的后缀来判断，如果是静态的
资源就由web服务器自行处理，然后将资源发给客户端。如果是动态这时web服务器会通过
CGI（Common Gateway interface）协议发起给php。 这里但是如果php是以模块形式与Web服务
器联系。那么他们是通过内部共享内存的方式。如果是php单独的放置与一台服务器，那么他们是
通过sockets套接字监听的方式通信（这又是一个C/S架构）。这时php会相应的执行一段程序，如
果在执行程序时，需要用到数据。那么php就会通过mysql协议发送给mysql服务器（也可以看作是
一个C/S架构）。由mysql服务器处理，将数据供给php程序。
LAMP流程：

1. 用户发送http请求到达httpd服务器
2. httpd解析url获取需要的资源的路径，通过内核空间读取硬盘资源，如是静态资源，则构建响应
   报文，发回给用户
3. 如果是动态资源，将资源地址发给php解析器，解析php程序文件，解析完毕将内容发回给
   httpd，httpd构建响应报文，发回给用户
4. 如果涉及到数据库操作，则利用php­mysql驱动，获取数据库数据，返回给PHP解析器