IT数码 购物 网址 头条 软件 日历 阅读 图书馆
TxT小说阅读器
↓语音阅读,小说下载,古典文学↓ 		图片批量下载器
↓批量下载图片,美女图库↓ 		图片自动播放器
↓图片自动播放器↓ 		一键清除垃圾
↓轻轻一点,清除系统垃圾↓
开发: C++知识库 Java知识库 JavaScript Python PHP知识库 人工智能 区块链 大数据 移动开发 嵌入式 开发工具 数据结构与算法 开发测试 游戏开发 网络协议 系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁
 
   -> 大数据 -> MySQL主从复制 -> 正文阅读

[大数据]MySQL主从复制

目录

主从复制基础

主从复制简介

MySQL数据库的主从复制方案，与使用scp/rsync等命令进行的文件级别复制类似，都是数据的远程传输，只不过MySQL的主从复制是自带的功能。MySQL的主从复制并不是数据库磁盘上的文件直接拷贝，而是将二进制日志binlog复制到要同步的服务器本地，然后由本地的线程读取日志里面的SQL语句，重新应用到MySQL数据库中。

  1. 基于二进制日志binlog进行复制
  2. 主库的修改操作会记录到二进制日志文件中
  3. 从库会请求新的二进制日志并回放，最终达到主从数据同步
  4. 主从复制核心功能：辅助备份，处理数据库物理损坏
    什么是逻辑损坏？drop、delete truncate等在数据库内部的误操作
    什么是物理损坏？操作系统层次的损坏（数据库外部的损坏）

问：主从复制可以替代数据库的备份？
答：主从复制的核心是通过二进制日志文件来实现与主库同步，如果主库发生逻辑损坏（drop、delete等误操作），从库也会同步。因此主从复制主要解决发生物理损坏的情况（物理损坏可立马启用从库对外服务，恢复备份会花费很长时间）；对逻辑损坏还是需要通过备份进行恢复。

主从复制前提

  1. 两台以上mysql实例 ：server_id、server_uuid不同
  2. 主库开启二进制日志
  3. 主库需建立专用的复制用户（replication slave）
  4. 建立主库全备（适用于主库运行很久后需要建立从库的情况），保证主从开启之前的某个时间点,从库数据和主库一致
  5. change master to：告知从库主库的IP、Port、user、passwd以及复制的起点（file，position）
  6. start slave：开启专用的复制线程（主库：binlog_dump_T 、从库：thread IO thread 、SQL thread）

主从复制搭建

主库配置（3307实例）

  1. 创建数据目录并赋予权限进行初始化
    [root@localhost data]# mkdir /data/3307/data -p 
[root@localhost data]# chown -R mysql.mysql /data/3307
[root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3307/data
  2. 编辑配置文件，开启二进制日志功能
    [root@localhost data]# vim /data/3307/my.cnf 
[mysqld]
basedir=/app/mysql
datadir=/data/3307/data
socket=/data/3307/mysql.sock
log_error=/data/3307/mysql.log
port=3307
server_id=7
log_bin=/data/3307/mysql-bin
  3. 启动主库数据库实例3307
    [root@localhost data]# systemctl start mysqld3307
[root@localhost data]# mysql -uroot -S /data/3307/mysql.sock
  4. 检查是否开启二进制日志文件
    [root@localhost ~]# ll /data/3307/mysql-bin*
-rw-r-----. 1 mysql mysql 154 Oct  3 12:23 /data/3307/mysql-bin.000001
-rw-r-----. 1 mysql mysql  28 Oct  3 12:23 /data/3307/mysql-bin.index
  5. 创建专用复制用户
    [root@localhost ~]# mysql -uroot -S /data/3307/mysql.sock 

mysql [(none)]>grant replication slave on *.* to slave@'192.168.1.%' identified by '123456';
  6. 建立主库全备（若主库都是刚搭建可以省略该步骤）
    [root@localhost ~]# 
[root@localhost ~]# mysqldump -uroot -S /data/3307/mysql.sock -A -R -E --triggers --master-data=2 --single-transaction > /data/3307/backup/full.sql

获取change master to 的信息
[root@localhost ~]# vim /data/3307/backup/full.sql
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=448;
  7. 查看主库状态
    mysql [(none)]>show master status ;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      448 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

从库配置（3308实例）

  1. 从库模拟恢复主库全备，保证主从开启之前的某个时间点，从库数据和主库一致

    [root@localhost ~]# mysql -uroot -S /data/3308/mysql.sock

mysql [mysql]>set sql_log_bin=0;
mysql [mysql]>source /data/3307/backup/full.sql

  2. 告知从库主库的IP、Port、专用复制用户的用户名和密码等信息（change master to）

    查看change master to帮助信息
mysql [(none)]>help change master to

CHANGE MASTER TO
  MASTER_HOST='master2.mycompany.com',    --主库地址
  MASTER_USER='replication',              --用户名
  MASTER_PASSWORD='bigs3cret',            --密码
  MASTER_PORT=3306,                       --端口
  MASTER_LOG_FILE='master2-bin.001',      --binlog
  MASTER_LOG_POS=4,                       --position
  MASTER_CONNECT_RETRY=10;                --重复连接次数

    mysql [(none)]>CHANGE MASTER TO
    ->   MASTER_HOST='192.168.1.5',
    ->   MASTER_USER='slave',
    ->   MASTER_PASSWORD='123456',
    ->   MASTER_PORT=3307,
    ->   MASTER_LOG_FILE='mysql-bin.000001',
    ->   MASTER_LOG_POS=448,
    ->   MASTER_CONNECT_RETRY=10;
Query OK, 0 rows affected, 2 warnings (0.22 sec)

  3. 开启主从专用线程

    mysql [(none)]> start slave;

  4. 检查复制状态

    mysql [(none)]>show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.5                 --主库相关信息监控
                  Master_User: slave
                  Master_Port: 3307
                Connect_Retry: 10
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 448
          
               Relay_Log_File: localhost-relay-bin.000002  --从库中继日志的应用状态
                Relay_Log_Pos: 320
        
             Slave_IO_Running: Yes                         --从库复制线程有关状态
            Slave_SQL_Running: Yes
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
               
              Replicate_Do_DB:                             --过滤复制有关
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 

        Seconds_Behind_Master: 0                          --主从延时相关状态（非人为）

                    SQL_Delay: 0                          --延时从库有关状态（人为）
          SQL_Remaining_Delay: NULL

   	       Retrieved_Gtid_Set:                            --GTID复制有关状态
    	    Executed_Gtid_Set: 
    	        Auto_Position: 0

主从复制原理

主从复制相关文件

  • 主库：
    ? ? ? ? ? ? mysql-bin.000001：二进制文件
  • 从库：
    ? ? ? ? ? ? localhost-relay-bin.000002：中继日志文件
    ? ? ? ? ? ? master.info：主库信息
    ? ? ? ? ? ? relay-log.info：中继日志信息

主从复制相关线程

  • 主库：
    ? ? ? ? ? ?Binlog_Dump_Thread：DT
  • 从库：
    ? ? ? ? ? ?Slave_IO_Thread：IT
    ? ? ? ? ? ?Slave_SQL_Thread：ST

主从复制图解原理

主从复制图解

  1. change master to命令：主库的ip port user password binlog position写入到master.info进行记录；
  2. start slave 命令：从库会启动Slave_IO_Thread和Slave_SQL_Thread；
  3. Slave_IO_Thread读取master.info信息，获取主库信息并连接主库；
  4. 主库会生成一个Binlog_Dump_Thread来响应从库；
  5. Slave_IO_Thread根据master.info记录的binlog文件名和position号，请求主库Binlog_Dump_Thread最新日志；
  6. Binlog_Dump_Thread检查主库的binlog日志，如果有新日志生成，TP(传送)给从库的Slave_IO_Thread（主库一旦有新的日志生成，会发送信号给Binlog_Dump_Thread，IO线程再请求）；
  7. Slave_IO_Thread将收到的日志存储到了TCP/IP 缓存，并立即返回ACK给主库 ，主库工作完成；
  8. Slave_IO_Thread将缓存中的数据存储到relay-log中继日志文件，并更新master.info文件binlog 文件名和postion，Slave_IO_Thread工作完成；
  9. Slave_SQL_Thread读取relay-log.info文件，获取到上次执行到的relay-log的位置，作为起点，回放relay-log；
  10. Slave_SQL_Thread回放完成之后，会更新relay-log.info文件；
  11. relay-log有自动清理的功能。

主从故障监控/分析/处理

IO线程故障

连接主库出现问题

Slave_IO_Running：Connecting
Last_IO_Errno: 0
Last_IO_Error:

  • IP

    ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.1.55' (113)

  • Port

    ERROR 2003 (HY000): Can't connect to MySQL server on '192.168.1.5' (111)

  • user，passwd

    ERROR 1045 (28000): Access denied for user 'slave'@'192.168.1.5' (using password: YES)

  • 连接数量上限

    ERROR 1040 (HY000)：Too many connections

  • 防火墙、网络不通

请求和接收二进制文件

故障：主库日志损坏或丢失

案例：执行reset master模拟主库日志丢失（会导致从库方面二进制日志位置点不对）

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'could not find next log; the first event 'mysql-bin.000001' at 154, the last event read from '/data/3307/data/mysql-bin.000002' at 154, the last byte read from '/data/3307/data/mysql-bin.000002' at 154.'

注意：在主从复制环境中，严令禁止主库中reset master； 可以选择expire 进行定期清理主库二进制日志。

处理故障过程

重新搭建主从环境

  1. 从库停止slave服务
    > stop slave;
  2. 重置从库信息
    > reset slave all;
> show slave status \G
  3. 重新搭建从库
    > change master to
> start slave;

SQL线程故障

SQL线程故障原因分析

  1. 版本差异，参数设定不同，比如：数据类型的差异，SQL_MODE影响；
  2. 要创建的数据库对象已经存在；
  3. 要删除或修改的对象不存在 ；
  4. DML语句不符合表定义及约束；

归根揭底都是由于从库发生了写入操作。

SQL县城故障模拟环境

  • 从库建立一个数据库sql_error

    mysql [(none)]>create database sql_error;
Query OK, 1 row affected (0.03 sec)

mysql [(none)]>show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sql_error          |
| sys                |
| test               |
+--------------------+
6 rows in set (0.13 sec)

  • 主库再次建立一个sql_error数据库

    mysql [(none)]>show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test               |
+--------------------+
5 rows in set (0.29 sec)

mysql [(none)]>create database sql_error;
Query OK, 1 row affected (0.02 sec)

  • 查看从库状态，出现异常

    Slave_SQL_Running: No

Last_SQL_Error: Error 'Can't create database 'sql_error'; database exists' on query. Default database: 'sql_error'. Query: 'create database sql_error'

SQL线程故障处理方式

以从库为核心的处理方案

丑话说在前头：以从库为核心处理的方案是有风险的，最安全的做法就是重新构建主从。坚定把握一个原则：一切以主库为主。

  • 方法一：sql_slave_skip_counter=1;(有风险)
    mysql [(none)]>stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql [(none)]>set global sql_slave_skip_counter=1;
# 将同步指针移到下一个，如果多次不同步，可以重复操作
Query OK, 0 rows affected (0.00 sec)

mysql [(none)]>start slave;
Query OK, 0 rows affected (0.11 sec)
  • 方法二：编辑配置文件跳过指定错误（生产环境不允许）
    vim my.cnf
slave-skip-errors = 1032,1062,1007

常见错误代码:
- 1007:对象已存在
- 1032:无法执行DML
- 1062:主键冲突,或约束冲突
一劳永逸的方案
  • 方法一：设置从库只读
    mysql [(none)]>set global read_only=1;
Query OK, 0 rows affected (0.00 sec)

mysql [(none)]>show variables like '%read_only%';
+-----------------------+-------+
| Variable_name         | Value |
+-----------------------+-------+
| innodb_read_only      | OFF   |
| read_only             | ON    |
| super_read_only       | OFF   |
| transaction_read_only | OFF   |
| tx_read_only          | OFF   |
+-----------------------+-------+
5 rows in set (0.00 sec)
  • 方法二：加入中间件实现读写分离

主从延时分析

主库做了修改操作,从库比较长时间才能追上。

外在因素

  1. 网络
  2. 主从硬件差异大
  3. 版本差异
  4. 参数因素

主库因素

原因分析：

  1. 二进制日志写入不及时
    mysql [(none)]>select @@sync_binlog;
+---------------+
| @@sync_binlog |
+---------------+
|             1 |
+---------------+
1 row in set (0.01 sec)
  2. 传统模式的主从复制中，binlog_dump线程以事件为单元串行传送二进制日志(版本5.5 5.6)
    a. 主库并发事务量大,主库可以并行,传送时是串行
    b. 主库发生大事务,由于是串行传送,会阻塞后续的事务
  3. 一主多从情况下，主库有很多DUMP线程，传输压力大（架构层面）

解决方案:

  1. MySQL 5.6 开始,开启GTID,实现了GC(group commit)机制,可以并行传输日志给从库IO
  2. MySQL 5.7 开始,不开启GTID,会自动维护匿名的GTID,也能实现GC,但建议还是开启GTID
  3. 大事务拆成多个小事务,可以有效的减少主从延时

从库因素

原因分析：

SQL线程导致的主从延时。在传统模式主从复制中，从库默认情况下只有一个SQL，只能串行回放事务SQL

  1. 主库如果并发事务量较大,从库只能串行回放
  2. 主库发生了大事务,会阻塞后续的所有的事务的运行

解决方案:

  1. MySQL 5.6 版本开启GTID之后,加入了SQL多线程的特性,但是只能针对不同库(database)下的事务进行并发回放（同一个库内依然是串行回放，防止出现逻辑问题）
  2. MySQL 5.7 版本开启GTID之后,在SQL方面,提供了逻辑时钟(logical_clock),binlog加入了seq_no（sequence number，序列号）机制,
    真正实现了基于事务级别的并发回放,这种技术称之为MTS(enhanced multi-threaded slave)
  3. 大事务拆成多个小事务,可以有效的减少主从延时

主从复制进阶

延时从库

延时从库是一种特殊从库，通过人为配置从库和主库延时N小时。

延时从库原因

主从复制的核心是通过二进制日志文件来实现与主库同步，如果主库发生逻辑损坏（drop、delete等误操作），从库也会同步。因此主从复制主要解决发生物理损坏的情况（物理损坏可立马启用从库对外服务，恢复备份会花费很长时间）。如果发生了逻辑损坏，就需要备份恢复，但如果恢复数量级很大的话，时间成本很高。

因此延时从库是为了更快的解决逻辑损坏问题的从库（备份恢复的替代方案）。

延时从库配置

SQL线程延时：数据已经写入relay-log中，但SQL线程慢点执行relay-log中的语句。
一般企业建议延时3-6小时，具体看公司运维人员对于故障的反应时间。

延时从库配置

  1. 停止slave服务

    mysql [(none)]>stop slave;
Query OK, 0 rows affected, 1 warning (0.05 sec)

  2. 修改MASTER_DELAY参数

    mysql [(none)]>CHANGE MASTER TO MASTER_DELAY=300;
Query OK, 0 rows affected (0.32 sec)

  3. 开启slave服务

    mysql [(none)]>start slave;

  4. 查看延时状态

    mysql [(none)]>show slave status \G;

                    SQL_Delay: 300   --延时时间
          SQL_Remaining_Delay: 295   --延时倒计时

  5. 查看二进制日志是否一致

    # 主库
mysql [test]>show master status ;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      943 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.34 sec)
# 从库
mysql [(none)]>show slave status \G;
          Read_Master_Log_Pos: 943

延时从库应用

一主一从，从库延时5分钟，主库误删除1个库。

逻辑故障恢复思路：

  1. 5分钟之内及时侦测到误删除操作
  2. 立即停止延时从库SQL的线程
  3. 挂维护页
  4. 截取relay-log日志进行恢复
    起点 ：停止SQL线程时的relay-log位置点
    终点 ：误删除之前的position(GTID)
  5. 截取的日志恢复到从库
  6. 从库身份解除,替代主库工作

故障模拟及恢复：

  1. 模拟主库数据操作

    mysql [(none)]> create database relay charset utf8;
mysql [(none)]> use relay
mysql [relay]> create table t1 (id int);
mysql [relay]> insert into t1 values(1);
mysql [relay]> drop database relay;

  2. 发现故障，停止从库的SQL线程

    mysql [none]> stop slave sql_thread;

  3. 找到relay-log的截取起点和终点

    # 起点
mysql [(none)]>show slave status\G;
Relay_Log_File: localhost-relay-bin.000002
Relay_Log_Pos: 482              --同步前的position
Read_Master_Log_Pos: 1698       --主库传来的新position


# 终点
mysql [(none)]>show relaylog events in 'localhost-relay-bin.000002'
| localhost-relay-bin.000002 | 1046 | Xid            |         7 |        1538 | COMMIT /* xid=74 */                   |
| localhost-relay-bin.000002 | 1077 | Anonymous_Gtid |         7 |        1603 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'  |
| localhost-relay-bin.000002 | 1142 | Query          |         7 |        1698 | drop database relay                   |

# 截取日志
[root@localhost ~]# mysqlbinlog --start-position=482 --stop-position=1077  /data/3308/data/localhost-relay-bin.000002>/tmp/relay.sql

  4. 从库恢复relay-log

    mysql [relay]>source /tmp/relay.sql

  5. 从库身份解除，从库替代主库身份（数据量比较小的话可以考虑直接将数据导入主库）

    mysql [relay]>stop slave;
mysql [relay]>reset slave all;

半同步复制

半同步复制用来解决主从数据一致性问题。

  • MySQL 5.5 版本出现
  • MySQL 5.6 增强
  • MySQL 5.7 完善，5.7.17后出现MGR复制

半同步复制原理

  1. 主库执行新的事务commit时，更新 show master status\G ，触发一个信号给Binlog_Dump_Thread；
  2. Binlog_Dump_Thread 接收到主库的 show master status\G 信息,通知从库日志更新；
  3. 从库Slave_IO_Thread 请求新的二进制日志事件;
  4. 主库会通过 Binlog_Dump_Thread 传送新的日志事件给从库Slave_IO_Thread；
  5. 从库Slave_IO_Thread接收到binlog日志，当日志写入到磁盘上的relaylog文件时，给主库ACK_receiver线程发送确认；
  6. ACK_receiver线程触发一个事件，告诉主库commit可以成功了；
  7. 如果ACK达到了预设值的超时时间，半同步复制会切换为原始的异步复制。

过滤复制

需求：master 有3个库A、B、C ，现在需要将其中2个库B，C单独拆分出来，单独一个实例。

常见的做法为：单独搭建一个只有B、C库的实例，且它们只复制master的B、C库，过滤掉A库。此时就需要过滤复制。

mysql [(none)]>show slave status \G;

                  Replicate_Do_DB:                             --过滤复制相关参数
              Replicate_Ignore_DB: 
               Replicate_Do_Table: 
           Replicate_Ignore_Table: 
          Replicate_Wild_Do_Table: 
      Replicate_Wild_Ignore_Table:

过滤复制配置

  • 主库方面（不建议使用）

    Binlog_Do_DB
    Binlog_Ignore_DB

  • 从库方面

    Replicate_Do_DB
    Replicate_Ignore_DB

    配置3309数据库实例只对两个库进行同步操作

    [root@db01 ~]# vim /data/3309/my.cnf 
replicate_do_db=people
replicate_do_db=world
[root@db01 ~]# systemctl restart mysqld3309

GTID复制

GTID简介

GTID(Global Transaction ID)是对一个已提交事务的唯一编号，并且是一个全局(主从复制)唯一的编号。它的官方定义如下：

GTID = source_id ：transaction_id

什么是sever_uuid？和server-id 区别？
server_uuid是mysql的识别码，server_id是在集群里面的id号，防止server_id冲突。

  • 核心特性
    全局唯一，具备幂等性

  • 核心参数
    gtid-mode=on --启动GTID类型，否则就是普通的复制架构
    enforce-gtid-consistency=true --强制GTID的一致性
    log-slave-update=1 --设置为开启，则从库从主库复制数据时可以写入到binlog日志

GTID复制配置

需求：搭建一主两从的GTID环境

  1. 创建数据目录并授予权限

    [root@localhost ~]# mkdir -p /data/330{7,8,9}/data
[root@localhost ~]# chown -R mysql.mysql /data/330{7,8,9}

  2. 准备各实例的配置文件

    [root@localhost ~]# vim /data/3307/my.cnf
[mysqld]
basedir=/app/mysql
datadir=/data/3307/data
socket=/data/3307/mysql.sock
server_id=7
port=3307
secure-file-priv=/tmp
autocommit=0
log_bin=/data/3307/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1

[mysql]
prompt=db01 [\\d]>

    [root@localhost ~]# vim /data/3308/my.cnf
[mysqld]
basedir=/app/mysql
datadir=/data/3308/data
socket=/data/3308/mysql.sock
server_id=8
port=3308
secure-file-priv=/tmp
autocommit=0
log_bin=/data/3308/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1

[mysql]
prompt=db02 [\\d]>

    [root@localhost ~]# vim /data/3309/my.cnf
[mysqld]
basedir=/app/mysql
datadir=/data/3309/data
socket=/data/3309/mysql.sock
server_id=9
port=3309
secure-file-priv=/tmp
autocommit=0
log_bin=/data/3309/binlog/mysql-bin
binlog_format=row
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1

[mysql]
prompt=db03 [\\d]>

  3. 初始化各实例数据目录

    [root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3307/data
[root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3308/data
[root@localhost data]# mysqld --initialize-insecure --user=mysql --basedir=/app/mysql --datadir=/data/3309/data

  4. 启动各数据库实例

    [root@localhost system]# systemctl start mysqld3307.service
[root@localhost system]# systemctl start mysqld3308.service
[root@localhost system]# systemctl start mysqld3309.service
[root@localhost system]# ps -ef | grep mysqld
mysql     10676      1 21 18:18 ?        00:00:06 /app/mysql/bin/mysqld --defaults-file=/data/3307/my.cnf
mysql     10687      1  9 18:19 ?        00:00:02 /app/mysql/bin/mysqld --defaults-file=/data/3308/my.cnf
mysql     10761      1 24 18:19 ?        00:00:03 /app/mysql/bin/mysqld --defaults-file=/data/3309/my.cnf
root      10795   5857 16 18:19 pts/0    00:00:00 grep --color=auto mysqld

  5. 构建主从
    数据库实例3307

    mysql [(none)]>grant replication slave on *.* to repl@'192.168.1.%' identified by '123456';
Query OK, 0 rows affected, 1 warning (0.12 sec)

    数据库实例3308/数据库实例3309

    mysql [(none)]>change master to 
    -> master_host='192.168.1.5',
    -> master_user='repl',
    -> master_password='123456' ,
    -> MASTER_AUTO_POSITION=1;
Query OK, 0 rows affected, 2 warnings (0.13 sec)

mysql [(none)]>start slave;
Query OK, 0 rows affected (0.10 sec)

  6. GTID从库误写入操作处理

    查看监控信息产生错误

    Last_SQL_Error: Error 'Can't create database 'oldboy'; database exists' on query. Default database: 'oldboy'. Query: 'create database oldboy'

Retrieved_Gtid_Set: 71bfa52e-4aae-11e9-ab8c-000c293b577e:1-3     --从主库请求的
Executed_Gtid_Set:  71bfa52e-4aae-11e9-ab8c-000c293b577e:1-2,    --实际运行的
7ca4a2b7-4aae-11e9-859d-000c298720f6:1

    由于71bfa52e-4aae-11e9-ab8c-000c293b577e:1-3操作有问题，可以采取注入空事务的方法，跳过该错误（有风险）：

    > stop slave;     --停止slave服务
> set gtid_next='99279e1e-61b7-11e9-a9fc-000c2928f5dd:3';  --手工设置操作xxxxx:N 就是slave_sql_thread报错的GTID，或者是想要跳过的GTID
> begin;commit;     --注入空事物
> set gtid_next='AUTOMATIC';    --设置回自动操作

    注入空事务的方式有风险，最好的解决方案：重新构建主从环境。

GTID复制与普通复制的区别

CHANGE MASTER TO
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=444,
MASTER_CONNECT_RETRY=10;

change master to 
master_host='10.0.0.51',
master_user='repl',
master_password='123' ,
MASTER_AUTO_POSITION=1;

start slave;

0. 在主从复制环境中，主库发生过的事务，在全局都是由唯一GTID记录的，更方便Failover;
1. gtid-mode=on 、enforce-gtid-consistency=true  、log-slave-update=1;   
2. change master to 的时候不再需要binlog 文件名和position号，直接auto即可，MASTER_AUTO_POSITION=1;
3. 在复制过程中，从库不再依赖master.info文件，而是直接读取最后一个relaylog的 GTID号，获取到上次复制的GTID号后从此号开始向后复制即可;
4. 在MHA高可用环境下，主库无法SSH时，从库进行数据恢复更加便捷;
5. mysqldump备份时，默认会将备份中包含的事务操作，以以下方式:
    SET @@GLOBAL.GTID_PURGED='8c49d7ec-7e78-11e8-9638-000c29ca725d:1';
    告诉从库，我的备份中已经有以上事务，你就不用运行了，直接从下一个GTID开始请求binlog就行。

主从复制架构演变

基础架构（无需三方软件支持）

单向主从复制架构图（只能在Master端写入数据）
在这里插入图片描述
一主多从复制架构图（只能在Master端写入数据）

在这里插入图片描述
双向主主复制架构图（两端Master均可写入数据）
在这里插入图片描述
线性级联单向双主复制架构图（只能在Master1端写入数据）
在这里插入图片描述
环状级联单向多主复制架构图（任意一点均可写入数据）
在这里插入图片描述
MySQL Group Replication（MGR）框架让MySQL具备了自动主从切换和故障恢复能力。MySQL Group Replication（MGR）是MySQL官方推出的一种基于Paxos协议的状态机复制。在MGR出现之前，用户常见的MySQL高可用方式，无论怎么变化架构，本质就是Master-Slave架构。MySQL 5.7版本开始支持无损半同步复制（lossless semi-sync replication），从而进一步提示数据复制的强一致性。
MGR

高级架构（需要三方软件支持）

  • 高可用架构
    ????单活：Keepalived + 双主 + 一从（MMM架构）、MHA
    ????多活：NDB Cluster（收费）、InnoDB Cluster、PXC（Percona XtraDB Cluster）、MGC（MariaDB Galera Cluster）

  • 高性能架构
    ????读写分离架构：Atlas（360）、Cobar、ProxySQL（Percona）、MySQL Router（Oracle）、Maxscale、Mycat
    ????分布式架构：Atlas-Sharding（360）、Mycat（开源）、TDDL（Taobao）
    ????

企业高可用标准

  • 全年无故障率（非计划内故障停机）

    99.9%                 ----> 0.001*365*24*60=525.6  min
99.99%                ----> 0.0001*365*24*60=52.56 min
99.999%               ----> 0.0001*365*24*60=5.256 min

  • 高可用架构方案

    负载均衡：有一定的高可用性（高可用最低的标准）  LVS、Nginx
主备（单活架构）：有高可用性，但是需要切换（切换的过程无法提供服务）   Keepalived、MHA
真正高可用（多活系统）：NDB Cluster、Oracle RAC、Sysbase Cluster、InnoDB Cluster（MGR）、Percona PXC、MGC
  大数据 最新文章
实现Kafka至少消费一次
亚马逊云科技：还在苦于ETL？Zero ETL的时代
初探MapReduce
【SpringBoot框架篇】32.基于注解+redis实现
Elasticsearch：如何减少 Elasticsearch 集
Go redis操作
Redis面试题
专题五 Redis高并发场景
基于GBase8s和Calcite的多数据源查询
Redis——底层数据结构原理
上一篇文章      下一篇文章      查看所有文章
加:2021-10-04 12:55:11  更:2021-10-04 12:55:50 
 
开发: C++知识库 Java知识库 JavaScript Python PHP知识库 人工智能 区块链 大数据 移动开发 嵌入式 开发工具 数据结构与算法 开发测试 游戏开发 网络协议 系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑 笔记本 显卡 显示器 固态硬盘 硬盘 耳机 手机 iphone vivo oppo 小米 华为 单反 装机 图拉丁

360图书馆 购物 三丰科技 阅读网 日历 万年历 2024年11日历 -2024/11/24 0:45:37-

图片自动播放器
↓图片自动播放器↓ 		TxT小说阅读器
↓语音阅读,小说下载,古典文学↓ 		一键清除垃圾
↓轻轻一点,清除系统垃圾↓ 		图片批量下载器
↓批量下载图片,美女图库↓
  网站联系: qq:121756557 email:121756557@qq.com  IT数码