实验一MySQL_mysql实验.md

----------

# 实验一：利用mysqldump+二进制日志实现备份恢复数据库 #

----------

### 1、查看原始数据 ###


### 2、mysqldump执行备份 ###


### 3、模拟在备份后修改数据，模拟利用二进制日志还原的场景 ###


### 4、还原mysqldump备份的数据 ###


### 5、导出二进制日志的事件 ###


### 6、还原二进制日志事件 ###



----------

# 实验二：利用xtrabackup+二进制日志实现完全备份和恢复数据库 #

----------

### 1、安装xtrabackup软件包 ###


### 2、验证数据的存储引擎类型 ###


### 3、查看数据初始状态 ###


### 4、利用innobackupex进行完全备份 ###


### 5、进行apply-log操作 ###


### 6、查看备份出来的文件的信息 ###


### 7、模拟在完全备份后，对数进行修改，以测试通过二进制日志还原完全备份后尚未来得及备份的变化的数据 ###


### 8、模拟损坏数据库，以测试还原 ###



### 9、导出自从完全备份到数据库损坏时的二进制日志事件 ###



### 10、利用完全备份，进行恢复 ###




### 11、利用导出的二进制日志文件事件，进行及时点恢复 ###


----------

# 实验三：利用xtrabackup+二进制日志实现增量备份和恢复数据库 #

----------

> 本例中实现的是将所有的增量日志都通过apply-log的步骤同步到完全备份文件中，如果希望利用增量日志还原到固定某次增量备份的数据，则不能使用本例中方式对所有的备份都进行apply-log操作，如果希望利用增量日志还原到固定哪次增量备份的数据，则将最初的完全备份的数据、和期望还原到某个增量备份前的增量备份的数据，拷贝一份到别的地方，然后依次对拷贝出来的完全备份做apply-log，对每次增量备份做apply-log，然后用形成的apply-log后形成的完全备份的数据，进行恢复

**实验环境：将node72(10.1.32.72)上的数据库的数据还原到node73(10.1.32.73)上**

### 1、安装xtrabackup软件包 ###


### 2、验证数据的存储引擎类型 ###


### 3、查看数据初始状态 ###


### 4、先进行完全备份，对完全备份进行apply-log，查看完全备份生成的文件 ###




### 5、进行第一次增量备份，对增量备份进行apply-log，将增量日志合并到完全备份中，查看第一次增量备份生成的文件信息 ###





### 6、进行第二次增量备份，对增量备份进行apply-log，将增量日志合并到完全备份中，查看第二次增量备份生成的文件信息 ###





### 7、模拟进行二进制日志的导出 ###



### 8、拷贝完全备份的数据和二进制日志导出的事件数据到需要恢复的节点上 ###


### 9、在需要恢复的节点上安装xtrabackup软件包 ###


### 10、恢复完全备份 ###




### 11、恢复二进制日志事件 ###


----------

# 实验四：MySQL主从复制的实现 #

----------

### 1、实验环境 ###


确保各节点之间的时间同步


### 2、修改主节点的mysql服务配置文件，让其符合主从架构中主节点的要求 ###



### 3、查看主节点现有数据情况和二进制日志使用情况 ###


### 4、对主节点的数据利用xtrabackup进行完全备份 ###

> 由于两个从节点是后期加入，故采取备份主节点的数据，还原到从节点上，然后让从节点从备份时刻的二进制日志的位置开始复制的方式进行配置




### 5、在主节点上授权一个具有复制权限的用户，授权该用户只允许在从节点上登录 ###


### 6、在两个从节点上安装mariadb-server，并利用xtrabackup还原备份的数据到两个节点上 ###







### 7、修改两个从节点上的mysql服务的配置文件，让其符合主从架构中从节点的配置要求 ###



### 8、启动从节点的mysql服务，并配置其连接到主服务器进行工作的复制属性，启动复制线程 ###




### 9、验证主从复制是否成功 ###


----------

# 实验五：MySQL双主复制架构的实现 #

----------

> 双主的实现方式与主/从类似，仅是两个主机即使主节点，又是对方的从节点

双主模型容易造成数据的不一致性，因此要慎用！

### 1、实验环境 ###


### 2、在两个节点上安装mariadb-server服务 ###



### 3、修改两个节点的服务器配置文件 ###



### 4、两个节点上各自启动服务，各授权一个具有复制权限的用户 ###



### 5、查看两个节点的二进制日志的状态 ###



### 6、在两个节点上定义复制时的属性，启动复制线程 ###



### 7、查看两个节点上主从的状态信息 ###



### 8、验证主从是否配置成功 ###



----------

# 实验六：半同步复制的实现 #

----------

> 默认情况下，主从复制的结构中，主从节点之间复制操作是异步的，这样就有可能造成主从节点之间数据不一致的情况发生，所谓版同步复制就是指在一主多从的场景中，我们设定主节点与其中一个或多个从节点(一般是一个)的数据复制是同步进行的，从而保证了该从节点和主节点之间的数据的一致性。故当主节点发生故障时，就可以基于其他方式将该从节点提升为主节点，提高可用性。

### 1、实验环境 ###

设定node72节点和node73节点之间的数据复制是基于同步方式进行


**确保节点间时间同步**


### 2、在两个节点上安装mariadb-server服务程序包 ###



### 3、确保两个节点上安装生成的mysql的插件目录下有semisync_master.so和semisync_slave.so共享库文件 ###



### 4、配置两个节点之间的主从关系 ###







### 5、在主节点上安装专用于主节点的半同步插件，启用主节点的半同步复制功能 ###



### 6、在从节点上安装专用于从节点的半同步插件，启用从节点的半同步复制功能 ###



### 7、验证同步复制是否配置成功 ###


----------

# 实验七：复制过滤器的实现 #

----------

> 复制过滤器的作用是让从节点仅复制主节点的指定的库，或指定数据库的指定表，而不是全部复制。

其配置方式有两种，一种是在主节点上配置，通过定义主节点只记录部分库或表产生的二进制日志时间来实现；一种是通过从节点上配置，当复制了主节点的所有的二进制日志数据后，在SQL线程执行时，只执行指定的库或表相关的二进制日志时间；一般采取在从节点上的配置来实现

### 1、实验环境说明 ###

- 主节点为node72(10.1.32.72)，从节点为node73(10.1.32.73)

- 在从节点上实现复制过滤，限制从节点，只执行testdb库和testdb1库的复制操作，其他库不予复制

### 2、确保两节点时间同步 ###


### 3、在两个节点上安装mariadb-server服务程序包 ###



### 4、配置两个节点之间的主从关系 ###






### 5、配置从节点实现复制过滤 ###





### 6、验证复制过滤器的功能是否正常 ###


----------

# 实验八：基于SSL的主从复制功能的实现 #

----------

> 在mysql服务器之间复制数据，默认情况下都是基于明文的，在有些场景中，明文传输会造成严重的数据安全隐患，因此，需要对mysql服务器之间的复制时的传输进行加密，传输加密方式可以基于SSL的会话进行

### 1、实验环境 ###


### 2、私有CA的搭建 ###


### 3、在主节点node72上生成证书签署请求、发送到私有CA服务器 ###


### 4、在从节点node73上生成证书签署请求、发送到私有CA服务器 ###


### 5、私有CA为两个节点颁发证书，将证书发送给两个节点 ###



### 6、在两个节点上分别修改证书相关文件的权限，让mysql用户拥有读取权限 ###



### 7、在两个节点上安装mariadb-server ###



### 8、配置修改主节点的配置文件，启动服务，让其满足基于SSL会话的主从复制时主节点的相关属性 ###



### 9、在从节点上测试，是否能够基于ssl会话的方式与主服务器进行连接 ###


### 10、修改从节点的服务器配置文件，让其满足主从结构中从节点的要求 ###


### 11、定义从节点从主节点复制数据时的属性，让其能够，启动复制线程 ###


### 12、验证基于SSL的主从复制是否配置成功 ###


----------

# 实验九：MHA实现主从复制中主节点的高可用 #

----------

> MHA(Master HA)是一款开源的 MySQL 的高可用程序，它为 MySQL 主从复制架构提供 了 automating master failover 功能。MHA 在监控到 master 节点故障时，会提升其中拥有最新 数据的 slave 节点成为新的 master 节点，在此期间，MHA 会通过于其它从节点获取额外信 息来避免一致性方面的问题。MHA 还提供了 master 节点的在线切换功能，即按需切换 master/slave 节点

### 1、实验目的： ###

- 配置MHA+半同步复制功能，实现对主从结构中主节点的高可用

- 本实验配置主从复制中，基于MHA对主节点进行高可用，同时配置主从节点之间的半同步复制功能，确保有一个从节点的数据与主节点的数据一致

### 2、实验环境 ###


### 3、实验前准备工作 ###

**保证各个节点之间能基于SSH秘钥方式进行通信；且客户端不验证主机秘钥(因为MHA严重依赖于SSH)**






**保证各个节点时间同步**


**确保iptables和selinux不会成为阻碍**


**配置各个节点能基于主机名互相解析(非必须)**



### 4、在三个MySQL节点上配置mysql的主从复制集群，测试主从复制集群是否成功 ###


**node72主节点的配置：**



**node73从节点的配置：**



**node75从节点的配置：**



### 5、配置node72主节点与node73从节点之间的半同步复制功能 ###

**在node72主节点上的配置：**


**在node73从节点上的配置：**


**在node72主节点上验证半同步配置是否成功：**


### 6、在MHA的manager节点上部署MHA管理端程序 ###


### 7、在三个MySQL节点上部署MHA的node节点程序 ###




### 8、配置MHA的manager节点，启动MHA管理端程序，让其能正常工作 ###





### 9、测试将MySQL的主节点故障，验证主节点程序是否发生转移 ###





### 10、其他需要考虑的问题 ###

- **当新增从节点或原有主节点重新加入主从复制集群时的操作**

1、先部署mysql服务，然后修改配置文件，注意配置文件要与此前从节点配置时的配置文件类似

2、将当前为主节点的mysql数据进行备份，并记录当前主节点的二进制日志的位置，然后将备份文件恢复到要添加的新的从节点上，然后设定该从节点复制时的属性(CHANGE MASTER TO)，限定从该备份文件之后的二进制日志文件的位置开始复制

3、确保该从节点上mysql服务上拥有管理权限的账号和拥有复制权限的账号与其他节点一致

4、确保该节点上能够基于SSH秘钥方式与其他任意节点(包括MHA的manager节点)进行通信

5、为新的从节点安装MHA的node软件包

6、在MHA的manager的配置文件中，为该新增的节点添加配置信息

- **master_ip_failover_script脚本的说明**

前端的应用程序与mysql肯定是基于套接字进行通信，当主节点发生变动后，因为IP地址也发生了变化，因此，可能造成前端应用程序无法与MySQL服务之间建立通信，可以利用master_ip_failover_script指令，将该指令定义在manager的配置文件中的[server_default]段内，用来指明自己定义的一个脚本文件路径，该脚本文件的作用是当主节点发生转移后，在新的主节点上设定一个与之前主节点一致的VIP地址，从而实现了VIP地址的转移，具体脚本在互联网上有很多，可以自行搜索(在官方的源码包中也有提供，可对应查看，根据需要进行修改)

- **shutdown_script脚本的说明**

当主节点发生故障时，会自动将一个从节点切换为主节点，为了避免原来的主节点与现有主节点之间发生资源争用，可以用shutdown_script指令，将该指令定义在manager的配置文件中的[server_default]段内，用于指明当主节点故障后，对主节点执行的操作的一个自定义脚本的路径，该脚本的作用类似于可以将该节点关机之类的操作，内容是如shutdown -h now之类的

一键复制

编辑

Web IDE

原始数据

按行查看

历史