文章目录
- 概述
- SQL
- 数据库的三大范式
- 主从复制
- 技术产生原因
- 主从形式
- 原理图
- 主节点 binary log dump 线程
- 从节点I/O线程作用
- 从节点SQL线程作用
- 复制过程
- 复制模式
- 异步模式（mysql async-mode）
- 半同步模式(mysql semi-sync)
- 全同步模式
- 复制机制
- binlog记录模式
- GTID复制模式
- 主从复制慢原因分析
- 读写分离
- 部署
- docker compose一键部署
概述
SQL
-
什么是SQL？
Structure Query Language(结构化查询语言)
它被美国国家标准局(ANSI)确定为关系型数据库语言的美国标准，后被国际化标准组织(ISO)采纳为关系数据库语言的国际标准。
数据库管理系统可以通过SQL管理数据库；定义和操作数据，维护数据的完整性和安全性。
-
优点
- 简单易学，具有很强的操作性
- 绝大多数重要的数据库管理系统均支持SQL
- 高度非过程化；用SQL操作数据库时大部分的工作由DBMS自动完成
-
分类
- DDL(Data Definition Language) 数据定义语言，用来操作数据库、表、列等； 常用语句：CREATE、 ALTER、DROP
- DML(Data Manipulation Language) 数据操作语言，用来操作数据库中表里的数据；常用语句：INSERT、 UPDATE、 DELETE
- DCL(Data Control Language) 数据控制语言，用来操作访问权限和安全级别； 常用语句：GRANT、DENY
- (Data Query Language) 数据查询语言，用来查询数据 常用语句：SELECT
数据库的三大范式
- 第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据线；也就是说：每列的值具有原子性，不可再分割。
- 范式(2NF)是在第一范式(1NF)的基础上建立起来得，满足第二范式(2NF)必须先满足第一范式(1NF)。如果表是单主键，那么主键以外的列必须完全依赖于主键；如果表是复合主键，那么主键以外的列必须完全依赖于主键，不能仅依赖主键的一部分。
- 范式(3NF)是在第二范式的基础上建立起来的，即满足第三范式必须要先满足第二范式。第三范式(3NF)要求：表中的非主键列必须和主键直接相关而不能间接相关；也就是说：非主键列之间不能相关依赖。
主从复制
技术产生原因
- 读写分离，主库出现了锁表的情景，可以通过读从库也可以保证业务的正常运作。
- 数据热备份
- 架构扩展，业务量大的时候，避免I/O访问频率过高，做多库的存储
主从形式
-
一主一从、一主多从
最常见的主从架构，实施起来简单并且有效，不仅可以实现HA，而且还能读写分离，进而提升集群的并发能力。
-
多主一从(5.7往后支持)
可以将多个mysql数据库备份到一台存储性能比较好的服务器上。
-
双主复制
互做主从复制，每个master既是master，又是另外一台服务器的slave。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。
-
级联复制
级联复制模式下，部分slave的数据同步不连接主节点，而是连接从节点。因为如果主节点有太多的从节点，就会损耗一部分性能用于replication，那么我们可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。
原理图
一台服务器上，利用docker compose部署一主两从，实现主从复制
复制过程实际上就是Slave 从Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作
主节点 binary log dump 线程
当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放。
从节点I/O线程作用
当从节点上执行
start slave命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。如果在SQL进程执行之前从节点服务停止，至少I/O进程已经从主节点拉取到了最新的变更并且保存在本地relay日志中，当服务再次起来之后，就可以完成数据的同步。
从节点SQL线程作用
SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。
复制过程
-
从库通过手工执行change master to 语句连接主库
需要提供了连接的用户一切条件（user 、password、port、ip、指定位置）
-
从库的IO线程和主库的dump线程建立连接
-
从库根据change master to 语句提供的file名和position号，IO线程向主库发起binlog的请求。
-
主库dump线程根据从库的请求，将本地binlog以events的方式发给从库IO线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的bin-log file 的以及bin-log position；
-
从库IO线程接收binlog events，并存放到本地relay-log中，传送过来的信息，会记录到master.info中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”；
-
从库SQL线程应用relay-log，并且把应用过的记录到relay-log.info中，默认情况下，已经应用过的relay 会自动被清理purge
复制模式
MySQL主从复制默认是异步的
异步模式（mysql async-mode）
异步模式如下图所示，这种模式下，主节点不会主动push bin log到从节点，这样有可能导致failover的情况下，也许从节点没有即时地将最新的bin log同步到本地。
半同步模式(mysql semi-sync)
这种模式下主节点只需要接收到其中一台从节点的返回信息，就会commit；否则需要等待直到超时时间然后切换成异步模式再提交；这样做的目的可以使主从数据库的数据延迟缩小，可以提高数据安全性，确保了事务提交后，binlog至少传输到了一个从节点上，不能保证从节点将此事务更新到db中。性能上会有一定的降低，响应时间会变长。如下图所示:
全同步模式
全同步模式是指主节点和从节点全部执行了commit并确认才会向客户端返回成功。
复制机制
binlog记录模式
-
基于SQL语句的复制（statement-based replication，SBR）
Statement-base Replication (SBR)就是记录sql语句在bin log中，Mysql 5.1.4 及之前的版本都是使用的这种复制格式。优点是只需要记录会修改数据的sql语句到binlog中，减少了binlog日质量，节约I/O，提高性能。缺点是在某些情况下，会导致主从节点中数据不一致（比如sleep(),now()等）。
-
基于行的复制（row-based replication，RBR)
Row-based Relication(RBR)是mysql master将SQL语句分解为基于Row更改的语句并记录在bin log中，也就是只记录哪条数据被修改了，修改成什么样。优点是不会出现某些特定情况下的存储过程、或者函数、或者trigger的调用或者触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是修改table的时候会让日志暴增,同时增加bin log同步时间。也不能通过bin log解析获取执行过的sql语句，只能看到发生的data变更。
-
混合模式复制（mixed-based replication,MBR)
Mixed-format Replication(MBR)，MySQL NDB cluster 7.3 和7.4 使用的MBR。是以上两种模式的混合，对于一般的复制使用STATEMENT模式保存到binlog，对于STATEMENT模式无法复制的操作则使用ROW模式来保存，MySQL会根据执行的SQL语句选择日志保存方式。
GTID复制模式
在MySQL 5.6里面，不用再找binlog和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行，因为复制是自动的，MySQL会通过内部机制GTID自动找点同步。
- 主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中。
- 从节点的I/O线程将变更的bin log，写入到本地的relay log中。
- SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要开启binary log）。
- 如果有记录，说明该GTID的事务已经执行，从节点会忽略。
- 如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log。
- 在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描。
主从复制慢原因分析
- 从库硬件比主库差，导致复制延迟
- 主从复制单线程，如果主库写并发太大，来不及传送到从库，就会导致延迟。单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库
- 更高版本的mysql可以支持多线程复制
- 慢SQL语句过多
- 网络延迟
- master负载：主库读写压力大，导致复制延迟，架构的前端要加buffer及缓存层
- slave负载：一般的做法是，使用多台slave来分摊读请求，再从这些slave中取一台专用的服务器，只作为备份用，不进行其他任何操作.
读写分离
只在主服务器上写，只在从服务器上读。
amoeba软件
部署
docker compose一键部署
目录：/home/mysql
-
compose文件
version: '3.8' services: mysql_master: image: mysql:8.0.33-oracle restart: always privileged: true ports: - "3306:3306" environment: - MYSQL_ROOT_PASSWORD=admin123 - MYSQL_DATABASE=db01 volumes: - ./3306_log:/var/log/mysql - ./3306_data:/var/lib/mysql - ./3306_conf/my.cnf:/etc/mysql/my.cnf networks: - mysql_network mysql_slave1: image: mysql:8.0.33-oracle restart: always privileged: true ports: - "3307:3306" environment: - MYSQL_ROOT_PASSWORD=admin123 - MYSQL_DATABASE=db01 volumes: - ./3307_log:/var/log/mysql - ./3307_data:/var/lib/mysql - ./3307_conf/my.cnf:/etc/mysql/my.cnf networks: - mysql_network mysql_slave2: image: mysql:8.0.33-oracle restart: always privileged: true ports: - "3308:3306" environment: - MYSQL_ROOT_PASSWORD=admin123 - MYSQL_DATABASE=db01 volumes: - ./3308_log:/var/log/mysql - ./3308_data:/var/lib/mysql - ./3308_conf/my.cnf:/etc/mysql/my.cnf networks: - mysql_network networks: mysql_network: -
3306 cnf文件
[mysqld] ## 设置server_id，同一局域网中需要唯一 server_id=101 ## 指定不需要同步的数据库名称 binlog-ignore-db=mysql ## 开启二进制日志功能 log-bin=mall-mysql-bin ## 允许服务器更新二进制文件 log-slave-updates=true ## 设置二进制日志使用内存大小（事务） binlog_cache_size=1M ## 设置使用的二进制日志格式（mixed,statement,row） binlog_format=mixed ## 二进制日志过期清理时间。默认值为0，表示不自动清理。 expire_logs_days=7 ## 跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。 ## 如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致 slave_skip_errors=1062 character-set-server=utf8 bind-address=0.0.0.0 -
3307
[mysqld] ## 设置server_id，同一局域网中需要唯一 server_id=102 ## 指定不需要同步的数据库名称 binlog-ignore-db=mysql ## 开启二进制日志功能，以备Slave作为其它数据库实例的Master时使用 log-bin=mall-mysql-slave1-bin ## 设置二进制日志使用内存大小（事务） binlog_cache_size=1M ## 设置使用的二进制日志格式（mixed,statement,row） binlog_format=mixed ## 二进制日志过期清理时间。默认值为0，表示不自动清理。 expire_logs_days=7 ## 跳过主从复制中遇到的所有错误或指定类型的错误，避免slave端复制中断。 ## 如：1062错误是指一些主键重复，1032错误是因为主从数据库数据不一致 slave_skip_errors=1062 ## relay_log配置中继日志 relay_log=mall-mysql-relay-bin ## log_slave_updates表示slave将复制事件写进自己的二进制日志 log_slave_updates=1 ## slave设置为只读（具有super权限的用户除外） read_only=1 -
中间操作
# 主机 CREATE USER slave@'%' IDENTIFIED WITH mysql_native_password BY '12345678'; GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%'; """ 参数说明 % 表示该用户可以从任何主机连接到MySQL服务器 *.* 表示数据库名，支持正则 REPLICATION SLAVE 允许用户作为MySQL复制的从服务器，接受来自主服务器的二进制日志并应用到本地数据库 REPLICATION CLIENT 权限允许用户连接到主服务器并检索复制相关的信息。 若想让用户拥有只读权限：GRANT SELECT ON *.* TO 'readonly'@'%'; """ flush privileges; show master status; # 从机 change master to master_host='192.168.128.2', master_user='slave', master_password='12345678', master_port=3306, master_log_file='mall-mysql-bin.000004',master_log_pos=848,master_connect_retry=10; CHANGE MASTER TO MASTER_HOST='mysql_master', MASTER_PORT=3306, MASTER_USER='slave', MASTER_PASSWORD='12345678'; START SLAVE; SHOW SLAVE STATUS\G ---- 暂且不看 CHANGE MASTER TO MASTER_HOST='${MYSQL_MASTER_HOST}', MASTER_USER='${MYSQL_MASTER_USER}', MASTER_PASSWORD='${MYSQL_MASTER_PASSWORD}', MASTER_PORT=${MYSQL_MASTER_PORT}, MASTER_LOG_FILE='${MYSQL_MASTER_LOG_FILE}', MASTER_LOG_POS=${MYSQL_MASTER_LOG_POS}, MASTER_CONNECT_RETRY=${MYSQL_MASTER_CONNECT_RETRY}; master_log_file='mall-mysql-bin.000001', # 指定从数据库要复制数据的日志文件，通过查看主数据的状态，获取File参数 master_log_pos=769, # 指定从数据库从哪个位置开始复制数据，通过查看主数据的状态，获取Position参数； master_connect_retry=30; 连接失败重试的时间间隔，单位为秒。Last_IO_Error: Error connecting to source ‘slave@192.168.112.2:3306’. This was attempt 1/86400, with a delay of 10 seconds between attempts. Message: Authentication plugin ‘caching_sha2_password’ reported error: Authentication requires secure connection.
- ALTER USER ‘slave’@‘%’ IDENTIFIED WITH mysql_native_password BY ‘12345678’;
