目录
1.源码编译MySQL
1、解压安装mysql:tar zxf mysql-boost-5.7.17.tar.gz
2、安装cmake,cmake相当于configure,用来编译yum install -y cmake-2.8.12.2-4.el6.x86_64.rpm
安装相关依赖的软件包 yum install -y gcc gcc-c++ ncurses-devel bison.x86_64
cmake -DCMAKE_INSTALL_PREFIX=/usr/local/mysql \ #安装目录
-DMYSQL_DATADIR=/usr/local/mysql/data \ #数据库存放目录
-DMYSQL_UNIX_ADDR=/usr/local/mysql/data/mysql.sock \ #Unix socket 文件路径
-DWITH_MYISAM_STORAGE_ENGINE=1 \ #安装 myisam 存储引擎
-DWITH_INNOBASE_STORAGE_ENGINE=1 \ #安装 innodb 存储引擎
-DDEFAULT_CHARSET=utf8 \ #使用 utf8 字符
-DDEFAULT_COLLATION=utf8_general_ci \ #校验字符
-DEXTRA_CHARSETS=all \ #安装所有扩展字符集
-DWITH_BOOST=boost/boost_1_59_0/
进入解压目录编译
make
之后make install
建议用户mysql
复制启动脚本mysql.server
到/etc/init.d/mysqld
建立目录/data/mysql/修改权限
将mysql命令
添加到环境变量 vim ~/.bash_profile
编辑/etc/my.cnf
初始化mysql,会生成一个临时密码,用于登录mysql(要记住此密码)在最后一行
启动mysql:/etc/init.d/mysqld start
执行:mysql_secure_installation
,然后会提示是否启用密码检测插件,直接回车不启用,否则会要求密码有大小写和特殊字符等要求,剩余全部选 y
再次登录数据库,可以查看数据库
可以看到mysql服务已开启
2.phpMyAdmin
通过网页图形去管理数据库
https://www.phpmyadmin.net/ ##下载地址
下载并解压包
做软链接myadmin
启动php-fpm服务并修改nginx的配置文件
在默认发布页中加入php页面
通过浏览器进入登陆界面,输入管理数据库的用户和密码
进入之后可以看到以下界面
3.mysql的主从复制
使用主从复制,让主库负责写,从库负责读,这样,即使主库出现了锁表的情景,通过读从库也可以保证业务的正常运作。架构的扩展。业务量越来越大,I/O访问频率过高,单机无法满足,此时做多库的存储,降低磁盘I/O访问的频率,提高单个机器的I/O性能。
主从复制的基础是主库记录数据库的所有变更记录到binlog( binary log,主库中保存更新事件日志的二进制文件)。binlog是数据库中保存配置中过期时间内所有修改数据库结构或内容的一个文件。如果过期时间是10d的话,那么就是最近10d的数据库修改记录。
mysql主从复制是一个异步的复制过程,主库发送更新事件到从库,从库读取更新记录,并执行更新记录,使得从库的内容与主库保持一致。
在 主库 里,只要有更新事件出现,就会被依次地写入到binlog里面,是之后从库连接到主库时,从主库拉取过来进行复制操作的数据源。
binlog输出线程 每当有从库连接到主库的时候,主库都会创建一个线程然后发送binlog内容到从库。 对于每一个即将发送给从库的sql事件,binlog输出线程会将其锁住。一旦该事件被线程读取完之后,该锁会被释放,即使在该事件完全发送到从库的时候,该锁也会被释放。在 从库 里,当复制开始的时候,从库就会创建两个线程进行处理:
从库I/O线程 当START SLAVE语句在从库开始执行之后,从库启动I/O线程,该线程连接到主库并请求主库发送binlog里面的更新记录到从库上。
从库I/O线程读取主库的binlog输出线程发送的更新并拷贝这些更新到本地文件,其中包括relay log文件。从库的SQL线程 从库启动SQL线程,这个线程读取从库I/O线程写到relay log(中继日志)的更新事件并执行。
1.配置主节点并把mysql安装到子节点
直接复制主节点的mysql到从节点server2
配置从节点的mysql
复制配置文件
配置环境变量
从节点server2初始化数据库
开启服务
开启服务之后会生成一个临时密码,使用临时密码进行数据库安全初始化
开始配置主节点(server1)数据库 vim /etc/my.cnf
mysqlbinlog查看二进制文件
在主节点上进入数据库,创建一个用户,给予复制的权力
在Master的数据库中建立一个备份帐户:每个slave使用标准的MySQL用户名和密码连接master。进行复制操作的用户会授予REPLICATION SLAVE权限
mysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'westos'; ## 创建用户,可以使用此用户远程登录数据库;
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%'; ##授权为可以复制master节点数据的slave节点
mysql> show master status; ##查看master状态
参数 | 解释 |
---|---|
REPLICATION | 表示复制的权限 |
* .* | 表示对所有库的所有表都授权 |
repl | 用户名 |
slave节点(server2 )写入server-id
在 slave(server2)上配置master信息
CHANGE MASTER TO MASTER_HOST='172.25.254.1'##在这个slave节点上面设置管理它的master节点主机信息
MASTER_USER='repl', ##用户
MASTER_PASSWORD='westos', ##密码
MASTER_LOG_FILE='mysql-bin.000001', ##基于position的主从复制的重要信息
MASTER_LOG_POS=595;
mysql> start slave; ##开启本节点的slave
mysql> show slave status\G ##查看主从复制状态
##这两个参数是Yes,表示成功 。Slave_IO_Running: Yes Slave_SQL_Running: Yes
2.测试主从同步是否生效
注意:写操作只能在master节点上做,因为master节点不会去同步slave节点的内容
在master创建新数据
mysql> create database westos; ##在server2上发现也能看到westos库
mysql> use westos
mysql> create table users (
-> username varchar(20) not null,
-> password varchar(20) not null); ##建表
mysql> desc users; ##查看表信息
mysql> insert into users values ('user1','123'); ##插入数据
mysql> select * from users; ##查看
在slave查看master的库信息
2.多个主从节点同步
复制主节点的mysql到从节点server3
复制从节点server2的配置文件到server3
建立用户和目录,修改权限
设置环境变量
在从节点server3中加入server-id
初始化数据库 ,生成密码
启动服务,安全初始化
修改从节点server2的配置文件
查看二进制文件信息
查看详细信息
在主节点中写入数据,从节点server2中可以看到
同步westos库复制到从节点server3
vim dump.sql
将刚刚导入的库导入到从节点server3新建的westos库中
可以看到从主节点同步过来的westos 数据库
在server2中创建用户并授权
对server2和server3形成一个主从关系
在从节点server3中配置主节点server2的信息
显示配置成功
在主节点server1的westos库中写入数据
同步到从节点server3;
在server2中也可以看到同步的数据
4.GTID异步复制
Global Transaction Identifier,全局事务标识
一个GTID在一个服务器上只执行一次,避免重复执行导致数据混乱或者主从不一致。
GTID用来代替传统复制方法,不再使用MASTER_LOG_FILE+MASTER_LOG_POS开启复制。而是使用MASTER_AUTO_POSTION=1的方式开始复制。
基于gtid的主从复制原理:每个mysql数据库上都有一个唯一uuid,每个事务生成一个id。gtid由上面两者组合: uuid+事务id
工作原理:
当一个事务在主库端执行并提交时,产生GTID,一同记录到binlog日志中。
binlog传输到slave,并存储到slave的relaylog后,读取这个GTID的这个值设置gtid_next变量,即告诉Slave,下一个要执行的GTID值。
sql线程从relay log中获取GTID,然后对比slave端的binlog是否有该GTID。
如果有记录,说明该GTID的事务已经执行,slave会忽略。
如果没有记录,slave就会执行该GTID事务,并记录该GTID到自身的binlog,在读取执行事务前会先检查其他session持有该GTID,确保不被重复执行。
在解析过程中会判断是否有主键,如果没有就用二级索引,如果没有就用全部扫描。
1.配置server1
配置server2
MASTER_AUTO_POSITION = 1; ##启用gtid,它是自动的
show slave status\G ##查看状态,两个线程正常运行
配置server3
在server1中写入数据
在server2上面查看状态和同步的数据
发现这两个参数 Retrieved_Gtid_Set: /Executed_Gtid_Set: 变了,从1位置开始复制的
从节点pos值相同
在server3上面查看状态和同步的数据
5.半同步复制 (io线程的优化)
主库产生binlog到主库的binlog file,传到从库中继日志,然后从库应用;也就是说传输是异步的,应用也是异步的。半同步复制指的是传输同步,应用还是异步的!
从库会在连接到主库时告诉主库,它是否配置了半同步。
如果半同步复制在主库端是开启了的,并且至少有一个半同步复制的从库节点,那么此时主库的事务线程在提交时会被阻塞并等待,结果有两种可能,要么至少一个从库节点通知它已经收到了所有这个事务的Binlog事件,要么一直等待直到超过配置的某一个时间点为止,而此时,半同步复制将自动关闭,转换为异步复制。
从库节点只有在接收到某一个事务的所有Binlog,将其写入并Flush到Relay Log文件之后,才会通知对应主库上面的等待线程。
如果在等待过程中,等待时间已经超过了配置的超时时间,没有任何一个从节点通知当前事务,那么此时主库会自动转换为异步复制,当至少一个半同步从节点赶上来时,主库便会自动转换为半同步方式的复制。
server1的主机中:
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; 安装半同步模块
SET GLOBAL rpl_semi_sync_master_enabled = 1; 开启半同步,也就是激活插件
show status like 'Rpl_semi_sync%'; 查看变量的状态
show variables like 'Rpl_semi_sync%'; 查看变量的值
mysql> show variables like '%rpl%'; 查看变量的值
+-------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled | ON |
### 是否开启半同步
| rpl_semi_sync_master_timeout | 10000 |
###切换复制的timeout
| rpl_semi_sync_master_trace_level | 32 |
###用于开启半同步复制模式时的调试级别,默认是32
| rpl_semi_sync_master_wait_for_slave_count | 1 |
###至少有N个slave接收到日志
| rpl_semi_sync_master_wait_no_slave | ON |
###是否允许master 每个事物提交后都要等待slave的receipt信号。默认为on
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
###等待的point |
+-------------------------------------------+------------+
在server2(slave节点)上
STOP SLAVE IO_THREAD; 重启IO线程使半同步生效
START SLAVE IO_THREAD;
从库重启io进程,激活插件之后必须要重启io进程,否则不会生效,如果重启不了的话就说明两端的数据不同步
在server3(slave节点)上
在三台主机的/etc/my.cnf中写入rpl_semi_sync_master_enabled =1
在server1中写入数据 ,查看同步状态没问题
server2从库同步 数据
server3从库同步 数据
server2从库的io进程关闭了,不能写入数据
查看状态待同步的事务也是1
server3正常同步数据
打开io进程server2 查看表信息,已经复制过来,只要从库的io进程恢复工作就会立即同步没有同步的数据
6.延迟复制
所谓的延迟 ,只是对 SQL_Thread 的线程的延迟。IO_Thread 主库发生的任何操作的日志都会同步到 slave,也就是说 IO_Thread 线程和主库是没有延迟的。只是 SQL_Thread 与主库有延迟。只是执行时间延迟,而不是读取 binlog 时间延迟。
先关闭SQL线程在server2中写入延迟时间30S
CHANGE MASTER TO MASTER_DELAY = N;
在server1中写入数据
30s之后在server2中同步
Seconds_Behind_Master: ##落后于master的时间
SQL_Remaining_Delay: 54 表示还有 54 秒后才可以应用 master 上执行的语句
7.并行复制
基于组的并发复制,可以支持在一个database中,并发执行relaylog中的事务。相同的二进制日志组在master上提交并行应用到slave节点上,没有跨数据库的限制,并且不需要把数据分到多个数据库
修改slave端的配置文件(server2)
slave-parallel-type=LOGICAL_CLOCK #基于组提交的并行用户
slave-parallel-workers=16 #开启16个worker:单线程变成多线程(前两个必须加入,后面为优化)
master_info_repository=TABLE #优化选项,默认以文件存储,记录master信息,用表来记录,更新速度更快
relay_log_info_repository=TABLE #日志信息,用表来记录(原来是记录在磁盘)
relay_log_recovery=ON #激活recovery:读取master二进制日志,如果损坏,直接丢弃然后重新读取
开启了16个线程
slave信息用表来记录
慢查询:server1(master)开启slow_query_log执行休眠10s
可以在日志中查询
8.(全同步复制) 组复制
组复制模型:
它支持单主模型和多主模型两种工作方式(默认是单主模型)
单主模型: 从复制组中众多个MySQL节点中自动选举一个master节点,只有master节点可以写,其他节点自动设置为read only。当master节点故障时,会自动选举一个新的master节点,选举成功后,它将设置为可写,其他slave将指向这个新的master。
多主模型: 复制组中的任何一个节点都可以写,因此没有master和slave的概念,只要突然故障的节点数量不太多,这个多主模型就能继续可用
组复制原理:
组复制由多个 server成员构成,并且组中的每个 server 成员可以独立地执行事务,但所有读写(RW)事务只有在冲突检测成功后才会提交。只读(RO)事务不需要在冲突检测,可以立即提交。
在server1上
1、关闭mysqld :/etc/init.d/my.cnf
2、删除mysql数据:rm -fr /data/mysql/*
修改配置文件 vim /etc/my.cnf
binlog_checksum=NONE :关闭binlog校验
binlog_format=ROW :组复制依赖基于行的复制格式
loose-group_replication_bootstrap_group=off :插件是否自动引导,这个选项一般都要off掉,只需要由发起组复制的节点开启,并只启动一次,如果是on,下次再启动时,会生成一个同名的组,可能会发生脑裂
开启多主模式的参数
loose-group_replication_enforce_update_everywhere_checks=ON
loose-group_replication_single_primary_mode=OFF
安全初始化,开启数据库
进入数据库修改密码
mysql> SET SQL_LOG_BIN=0; ##关闭二进制日志
mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'Westos==123'; ##创建用户
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%'; ##用户授权
mysql> FLUSH PRIVILEGES; ##刷新用户授权表
mysql> SET SQL_LOG_BIN=1; ##开启二进制日志
mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';##配置用户
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';##安装组复制插件
mysql> SET GLOBAL group_replication_bootstrap_group=ON;##在第一个节点上要先打开一次
mysql> START GROUP_REPLICATION;##开启组复制
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;##关闭组复制激活
mysql> SELECT * FROM performance_schema.replication_group_members;##查看当前组的状态,是否为online
在server2上
1、关闭mysqld :/etc/init.d/my.cnf
2、删除mysql数据:rm -fr /data/mysql/*
vim /etc/my.cnf
与server1同样操作
配置好后 在server1上 查看,
SELECT * FROM performance_schema.replication_group_members;
同样在server3上修改配置文件
关闭数据库删除/data/mysql/*
安全初始化开启数据库
配置好server2和server3后 在server1上 查看,看到3台都是online,表示正常,此时在任何一个节点写入数据,其他节点都可以看到。
在server1中写入数据
在server2中也可以看到同步信息
在server3中也可以看到同步信息
在server2中写入数据,其他的都看到
在server1中可以看到同步信息
在server3中写入数据
在server1和server2中都可以看到
在任意一个节点写数据,其他两个节点会进行组复制