从删库到跑路(三）

最新推荐文章于 2024-10-16 08:00:00 发布
最新推荐文章于 2024-10-16 08:00:00 发布
阅读量984 收藏
点赞数 1
分类专栏： 基础作业 文章标签： linux 数据库 mysql
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/FlamencaH/article/details/108027050
版权

数据库的备份和还原原理

为什么要备份

灾难恢复：硬件故障、软件故障、自然灾害、黑客攻击、误操作测试等数据丢失场景

备份注意要点

  • 能容忍最多丢失多少数据
  • 恢复数据需要在多长时间内完成
  • 需要恢复哪些数据

还原要点

  • 做还原测试，用于测试备份的可用性
  • 还原演练

备份类型

完全备份，部分备份
  • 完全备份：整个数据集
  • 部分备份：只备份数据子集，如部分库或表
部分备份：增量备份、差异备份
  • 增量备份：仅备份最近一次完全备份或增量备份（如果存在增量）以来变化的数据，备份较快，还原复杂
  • 差异备份：仅备份最近一次完全备份以来变化的数据，备份较慢，还原简单
冷、温、热备份
  • 冷备：读写操作均不可进行
  • 温备：读操作可执行；但写操作不可执行
  • 热备：读写操作均可执行
    MyISAM：温备，不支持热备
    InnoDB：都支持
物理和逻辑备份
  • 物理备份：直接复制数据文件进行备份，与存储引擎有关，占用较多的空间，速度快
  • 逻辑备份：从数据库中“导出”数据另存而进行的备份，与存储引擎无关，占用空间少，速度慢，可能丢失精度,类似于SELECT读取数据
备份时需要考虑的因素

温备的持锁多久
备份产生的负载
备份过程的时长
恢复过程的时长

备份什么

数据
二进制日志、InnoDB的事务日志
程序代码（存储过程、函数、触发器、事件调度器）
服务器的配置文件

备份工具
  • cp, tar等复制归档工具：物理备份工具，适用所有存储引擎；只支持冷备；完全和部分备份
  • LVM的快照：先加锁，做快照后解锁，几乎热备；借助文件系统工具进行
  • mysqldump：逻辑备份工具，适用所有存储引擎，温备；支持完全或部分备份；对InnoDB存储引擎支持热备，结合binlog的增量备份
  • xtrabackup：由Percona提供支持对InnoDB做热备(物理备份)的工具，支持完全备份、增量备份
  • MariaDB Backup： 从MariaDB 10.1.26开始集成，基于Percona XtraBackup 2.3.8实现
  • mysqlbackup：热备份， MySQL Enterprise Edition组件
  • mysqlhotcopy：PERL 语言实现，几乎冷备，仅适用于MyISAM存储引擎，使用LOCK TABLES、FLUSH TABLES和cp或scp来快速备份数据库
基于LVM的备份

(1) 请求锁定所有表
mysql> FLUSH TABLES WITH READ LOCK;
(2) 记录二进制日志文件及事件位置
mysql> FLUSH LOGS;
mysql> SHOW MASTER STATUS;
mysql -e ‘SHOW MASTER STATUS’ > /PATH/TO/SOMEFILE
(3) 创建快照
lvcreate -L # -s -p r -n NAME /DEV/VG_NAME/LV_NAME
(4) 释放锁
mysql> UNLOCK TABLES;
(5) 挂载快照卷，执行数据备份
(6) 备份完成后，删除快照卷
(7) 制定好策略，通过原卷备份二进制日志

mysqldump

  • 逻辑备份工具：mysqldump, mydumper, phpMyAdmin

  • Schema和数据存储在一起、巨大的SQL语句、单个巨大的备份文件

  • mysqldump工具：客户端命令，通过mysql协议连接至mysql服务器进行备份

    mysqldump [OPTIONS] database [tables]
mysqldump [OPTIONS] –B DB1 [DB2 DB3...]
mysqldump [OPTIONS] –A [OPTIONS]

    mysqldump参考： https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html

mysqldump常见选项

-A， --all-databases 备份所有数据库，含create database
-B , --databases db_name… 指定备份的数据库，包括create database语句
-E, --events：备份相关的所有event scheduler
-R, --routines：备份所有存储过程和自定义函数
–triggers：备份表相关触发器，默认启用,用–skip-triggers，不备份触发器
–default-character-set=utf8 指定字符集
–master-data[=#]： 此选项须启用二进制日志
1：所备份的数据之前加一条记录为CHANGE MASTER TO语句，非注释，不指定#，默认为1,1是配合数据库主从复制而来的
2：记录为注释的CHANGE MASTER TO语句
此选项会自动关闭–lock-tables功能，自动打开-x | --lock-all-tables功能（除非开启–single-transaction）

-F, --flush-logs ：备份前滚动日志，锁定表完成后，执行flush logs命令,生成新的二进制日志文件，配合-A 或 -B 选项时，会导致刷新多次数据库。建议在同一时刻执行转储和日志刷新，可通过和–single-transaction或-x，–master-data 一起使用实现，此时只刷新一次日志
–compact 去掉注释，适合调试，生产不使用
-d, --no-data 只备份表结构
-t, --no-create-info 只备份数据,不备份create table
-n,–no-create-db 不备份create database，可被-A或-B覆盖
–flush-privileges 备份mysql或相关时需要使用
-f, --force 忽略SQL错误，继续执行
–hex-blob 使用十六进制符号转储二进制列，当有包括BINARY， VARBINARY，BLOB，BIT的数据类型的列时使用，避免乱码
-q, --quick 不缓存查询，直接输出，加快备份速度

MyISAM备份选项

支持温备（只能读不能写）；不支持热备，所以必须先锁定要备份的库，而后启动备份操作
锁定方法如下：
-x,–lock-all-tables：加全局读锁，锁定所有库的所有表，同时加–single-transaction或–lock-tables选项会关闭此选项功能
注意：数据量大时，可能会导致长时间无法并发访问数据库
-l,–lock-tables：对于需要备份的每个数据库，在启动备份之前分别锁定其所有表，默认为on,–skip-lock-tables选项可禁用,对备份MyISAM的多个库,可能会造成数据不一致
注：以上选项对InnoDB表一样生效，实现温备，但不推荐使用

MyISAM建议备份策略
mysqldump –uroot –A –F –E –R –x --master-data=1 --flush-privileges --triggers --default-character-set=utf8 --hex-blob >$BACKUP/fullbak_$BACKUP_TIME.sql

InnoDB备份选项

支持热备，可用温备但不建议用
--single-transaction
此选项Innodb中推荐使用，不适用MyISAM，此选项会开始备份前，先执行START TRANSACTION指令开启事务
此选项通过在单个事务中转储所有表来创建一致的快照。 仅适用于存储在支持多版本控制的存储引擎中的表（目前只有InnoDB可以）; 转储不保证与其他存储引擎保持一致。 在进行单事务转储时，要确保有效的转储文件（正确的表内容和二进制日志位置），没有其他连接应该使用以下语句：ALTER TABLE，DROP TABLE，RENAME TABLE，TRUNCATE TABLE
此选项和–lock-tables（此选项隐含提交挂起的事务）选项是相互排斥
备份大型表时，建议将–single-transaction选项和--quick结合一起使用

InnoDB建议备份策略
mysqldump –uroot –A –F –E –R --single-transaction --master-data=1 --flush-privileges --triggers --default-character-set=utf8 --hex-blob >$BACKUP/fullbak_$BACKUP_TIME.sql
事务能隔离DBL语言吗？

事务有隔离性，但是DBL语言无法隔离，会出现幻读导致数据不一致

数据库中既有MyISAM又有InnoDB时如何备份

分库备份
mysqldump -B hello --single-transaction

1.查询数据库内容

mysql -e 'show databases'|grep -Ev '^(information_schema|performance_schema|Database)$'

2.将读取的数据库循环备份

for db in `mysql -e 'show databases'|grep -Ev '^(information_schema|performance_schema|Database)$'`;mysql -B $db --single-transaction --master-data=2 > /data/$db.sql ;done

​ 方案2

mysql -e 'show databases'|grep -Ev '^(information_schema|performance_schema|Database)$'|sed -rn 's@(.*)@mysqldump -B \1 --single-transaction --master-data=2 |gzip > /data/\1\.sql.gz@p'|bash

3.将备份的数据库文件压缩

for db in `mysql -e 'show databases'|grep -Ev '^(information_schema|performance_schema|Database)$'`;mysql -B $db --single-transaction --master-data=2 |gizp > /data/$db.sql.gz ;done

xtrabackup

Percona

官网：www.percona.com
percona-server
InnoDB --> XtraDB

percona-xtrabackup-24-2.4.20-1.el7.x86_64.rpm

Xtrabackup

percona提供的mysql数据库备份工具，惟一开源的能够对innodb和xtradb数据库进行热备的工具
手册：https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html

特点

备份还原过程快速、可靠
备份过程不会打断正在执行的事务
能够基于压缩等功能节约磁盘空间和流量
自动实现备份检验
开源，免费

Xtrabackup2.2版之前包括4个可执行文件：
innobackupex: Perl 脚本
xtrabackup: C/C++ 编译的二进制
xbcrypt: 加解密
xbstream: 支持并发写的流文件格式

xtrabackup 是用来备份 InnoDB 表的，不能备份非 InnoDB 表，和 MySQL Server 没有交互

innobackupex 脚本用来备份非 InnoDB 表，同时会调用 xtrabackup 命令来备份 InnoDB 表，还会和 MySQL Server 发送命令进行交互，如加全局读锁（FTWRL）、获取位点（SHOW SLAVE STATUS）等。即innobackupex是在 xtrabackup 之上做了一层封装实现的

xtrabackup 老版本 备份过程

在这里插入图片描述

xtrabackup的新版变化

xtrabackup版本升级到2.4后，相比之前的2.1有了比较大的变化：innobackupex 功能全部集成到 xtrabackup 里面，只有一个 binary程序，另外为了兼容考虑，innobackupex作为 xtrabackup 的软链接，即xtrabackup现在支持非Innodb表备份，并且 Innobackupex 在下一版本中移除，建议通过xtrabackup替换innobackupex

xtrabackup安装

yum install percona-xtrabackup 在EPEL源中
最新版本下载安装：
https://www.percona.com/downloads/XtraBackup/LATEST/

# percona-xtrabackup-24-2.4.20-1.el7.x86_64.rpm 
# 该软件包有些依赖程序是需要EPEL源的，所以安装前需要启用epel源
# 安装
[root@localhost ~]# yum install percona-xtrabackup-24-2.4.20-1.el7.x86_64.rpm

安装的文件列表

[root@localhost ~]# rpm -ql percona-xtrabackup-24
/usr/bin/innobackupex
/usr/bin/xbcloud
/usr/bin/xbcloud_osenv
/usr/bin/xbcrypt
/usr/bin/xbstream
/usr/bin/xtrabackup
/usr/lib64/xtrabackup/plugin/keyring_file.so
/usr/lib64/xtrabackup/plugin/keyring_vault.so
/usr/share/doc/percona-xtrabackup-24-2.4.20
/usr/share/doc/percona-xtrabackup-24-2.4.20/COPYING
/usr/share/man/man1/innobackupex.1.gz
/usr/share/man/man1/xbcrypt.1.gz
/usr/share/man/man1/xbstream.1.gz
/usr/share/man/man1/xtrabackup.1.gz

查看innobackupex

[root@localhost ~]# ll /usr/bin/innobackupex 
lrwxrwxrwx 1 root root 10 Aug  5 17:44 /usr/bin/innobackupex -> xtrabackup

# 在新版本中innobackupex已经成为了软链接

xtrabackup用法

备份：innobackupex [option] BACKUP-ROOT-DIR

选项说明：https://www.percona.com/doc/percona-xtrabackup/LATEST/genindex.html

  • –user：该选项表示备份账号
  • –password：该选项表示备份的密码
  • –host：该选项表示备份数据库的地址
  • –databases：该选项接受的参数为数据库名，如果要指定多个数据库，彼此间需要以空格隔开；如：“xtra_test dba_test”，同时，在指定某数据库时，也可以只指定其中的某张表。如：“mydatabase.mytable”。该选项对innodb引擎表无效，还是会备份所有innodb表
  • –defaults-file：该选项指定从哪个文件读取MySQL配置，必须放在命令行第一个选项位置
  • –incremental：该选项表示创建一个增量备份，需要指定–incremental-basedir
  • –incremental-basedir：该选项指定为前一次全备份或增量备份的目录，与–incremental同时使用
  • –incremental-dir：该选项表示还原时增量备份的目录
  • –include=name：指定表名，格式：databasename.tablename

预处理Prepare

innobackupex --apply-log [option] BACKUP-DIR

选项说明
  • –apply-log：一般情况下,在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处理不一致状态。此选项作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态
  • –use-memory：和–apply-log选项一起使用，当prepare 备份时，做crash recovery分配的内存大小，单位字节，也可1MB,1M,1G,1GB等，推荐1G
  • –export：表示开启可导出单独的表之后再导入其他Mysql中
  • –redo-only：此选项在prepare base full backup，往其中合并增量备份时候使用，但不包括对最后一个增量备份的合并

还原

innobackupex --copy-back [选项] BACKUP-DIR
innobackupex --move-back [选项] [--defaults-group=GROUP-NAME] BACKUP-DIR

选项说明
  • –copy-back：做数据恢复时将备份数据文件拷贝到MySQL服务器的datadir
  • –move-back：这个选项与–copy-back相似，唯一的区别是它不拷贝文件，而是移动文件到目的地。这个选项移除backup文件，用时候必须小心。使用场景：没有足够的磁盘空间同事保留数据文件和Backup副本
还原注意事项
  • datadir 目录必须为空。除非指定innobackupex --force-non-empty-directorires选项指定，否则–copy-backup选项不会覆盖
  • 在restore之前,必须shutdown MySQL实例，不能将一个运行中的实例restore到datadir目录中
  • 由于文件属性会被保留，大部分情况下需要在启动实例之前将文件的属主改为mysql，这些文件将属于创建备份的用户
    chown -R mysql:mysql /data/mysql
    以上需要在用户调用innobackupex之前完成
    –force-non-empty-directories：指定该参数时候，使得innobackupex --copy-back或–move-back选项转移文件到非空目录，已存在的文件不会被覆盖。如果–copy-back和–move-back文件需要从备份目录拷贝一个在datadir已经存在的文件，会报错失败

备份生成的相关文件

使用innobackupex备份时，其会调用xtrabackup备份所有的InnoDB表，复制所有关于表结构定义的相关文件(.frm)、以及MyISAM、MERGE、CSV和ARCHIVE表的相关文件，同时还会备份触发器和数据库配置信息相关的文件。这些文件会被保存至一个以时间命名的目录中,在备份时，innobackupex还会在备份目录中创建如下文件：

  • (1)xtrabackup_info：innobackupex工具执行时的相关信息，包括版本，备份选项，备份时长，备份LSN(log sequence number日志序列号)，BINLOG的位置
  • (2)xtrabackup_checkpoints：备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN范围信息,每个InnoDB页(通常为16k大小)都会包含一个日志序列号LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的
  • (3)xtrabackup_binlog_info：MySQL服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置，可利用实现基于binlog的恢复
  • (4)backup-my.cnf：备份命令用到的配置选项信息
  • (5)xtrabackup_logfile：备份生成的日志文件

新版xtrabackup完全备份及还原

在原主机做完全备份到/backup
xtrabackup --backup --target-dir=/backup/
scp -r /backup/* 目标主机:/backup
备份时的报错及注意事项

InnoDB: Unsupported redo log format. The redo log was created with MariaDB 10.2.32. Please follow the instructions at http://dev.mysql.com/doc/refman/5.7/en/upgrading-downgrading.html

在官网中说：xtrabackup已经不支持mariadb-10.3了

在这里插入图片描述

但在Mariadb文档中有一个名为innodb_safe_truncate变量，该变量的解释为

innodb_safe_truncate
  • Description: Use a backup-safe TRUNCATE TABLE implementation and crash-safe rename operations inside InnoDB. This is not compatible with hot backup tools other than Mariabackup. Users who need to use such tools may set this to OFF.
  • Commandline: --innodb-safe-truncate={0|1}
  • Scope: Global
  • Dynamic: No
  • Data Type: boolean
  • Default Value: ON
  • Introduced: MariaDB 10.2.19
  • Removed: MariaDB 10.3.0

解决方法：

在配置文件my.cnf中添加innodb_safe_truncate=OFF，重启mariadb服务后即可备份成功

在目标主机上
  • 预准备：确保数据一致，提交完成的事务，回滚未完成的事务
xtrabackup --prepare --target-dir=/backup/

  • 复制到数据库目录

    注意：数据库目录必须为空，MySQL服务不能启动只要是还原，都会影响业务正常运行

xtrabackup --copy-back --target-dir=/backup/
  • 还原属性
chown -R mysql:mysql /var/lib/mysql
  • 启动服务
systemctl start mariadb

还原数据库时遇到错误：在配置文件my.cnf中修改datadir目录导致mariadb服务无法启动

解决方案，重装Mariadb-server后恢复

新版xtrabackup完全，增量备份及还原

备份过程

  • 完全备份：xtrabackup --backup --target-dir=/backup/base
  • 第一次修改数据
  • 第一次增量备份:xtrabackup --backup --target-dir=/backup/inc1 --incremental-basedir=/backup/base
  • 第二次修改数据
  • 第二次增量:xtrabackup --backup --target-dir=/backup/inc2 --incremental-basedir=/backup/inc1
  • scp -r /backup/* 目标主机:/backup/
  • 备份过程生成三个备份目录
    /backup/{base，inc1，inc2}

还原过程

预准备完成备份，此选项–apply-log-only 阻止回滚未完成的事务:
xtrabackup --prepare --apply-log-only --target-dir=/backup/base

合并第1次增量备份到完全备份:

xtrabackup --prepare --apply-log-only --target-dir=/backup/base --incremental-dir=/backup/inc1

合并第2次增量备份到完全备份：最后一次还原不需要加选项–apply-log-only
xtrabackup --prepare --target-dir=/backup/base --incremental-dir=/backup/inc2

复制到数据库目录，注意数据库目录必须为空，MySQL服务不能启动

xtrabackup --copy-back --target-dir=/backup/base

还原属性：chown -R mysql:mysql /var/lib/mysql

启动服务：systemctl start mariadb

xtrabackup单表导出和导入

单表备份

innobackupex --include='hellodb.students' /backups

备份表结构

mysql -e 'show create table hellodb.students' > student.sql

删除表

mysql -e 'drop table hellodb.students‘

导出

innobackupex --apply-log --export /backups/2018-02-23_15-03-23/

MySQL复制

扩展方式： Scale Up ，Scale Out

MySQL的扩展
读写分离
复制：每个节点都有相同的数据集
向外扩展
二进制日志
单向

复制的功用：

​ 数据分布

​ 负载均衡读
​ 备份
​ 高可用和故障切换
​ MySQL升级测试

一主一从

在这里插入图片描述

主从复制必须启用二进制日志

一主多从

在这里插入图片描述

主从复制原理图

在这里插入图片描述

master节点必须启用二进制日志，通过dump，发送给slave，slave有两个线程io slave ，通过

MySQL垂直分区

在这里插入图片描述

MySQL水平分片（Sharding）

在这里插入图片描述

对应shard中查询相关数据

在这里插入图片描述

MySQL复制

主从复制线程：

  • 主节点：
    dump Thread：为每个Slave的I/O Thread启动一个dump线程，用于向其发送binary log events
  • 从节点：
    I/O Thread：向Master请求二进制日志事件，并保存于中继日志中
    SQL Thread：从中继日志中读取日志事件，在本地完成重放

跟复制功能相关的文件：

  • master.info：用于保存slave连接至master时的相关信息，例如账号、密码、服务器地址等
  • relay-log.info：保存在当前slave节点上已经复制的当前二进制日志和本地replay log日志的对应关系

主从复制特点：

  • 异步复制

  • 主从数据不一致比较常见，因为主从是通过网络进行的，在写入从时会产生延时过长的情形，由于并行写入会导致“堵车”

  • 主从复制为异步复制

复制架构：

  • Master/Slave, Master/Master, 环状复制

  • 一主多从

  • 从服务器还可以再有从服务器

  • 一从多主:适用于多个不同数据库

复制需要考虑二进制日志事件记录格式

  • STATEMENT（5.0之前）
  • ROW（5.1之后，推荐）
  • MIXED

MySQL复制模型

在这里插入图片描述

主从配置过程：参看官网
https://mariadb.com/kb/en/library/setting-up-replication/
https://dev.mysql.com/doc/refman/5.5/en/replication-configuration.html

主节点配置：

(1) 启用二进制日志
[mysqld]
log_bin

(2) 为当前节点设置一个全局惟一的ID号
[mysqld]
server_id=#
log-basename=master 可选项，设置datadir中日志名称，确保不依赖主机名

(3) 创建有复制权限的用户账号
GRANT REPLICATION SLAVE ON . TO ‘repluser’@‘HOST’ IDENTIFIED BY ‘replpass’;

从节点配置：

(1) 启动中继日志
[mysqld]
server_id=# 为当前节点设置一个全局惟的ID号
read_only=ON 设置数据库只读
relay_log=relay-log relay log的文件路径，默认值hostname-relay-bin
relay_log_index=relay-log.index 默认值hostname-relay-bin.index

(2) 使用有复制权限的用户账号连接至主服务器，并启动复制线程
mysql> CHANGE MASTER TO MASTER_HOST=‘host’, MASTER_USER=‘repluser’, MASTER_PASSWORD=‘replpass’, MASTER_LOG_FILE=’ mariadb-bin.xxxxxx’, MASTER_LOG_POS=#;
mysql> START SLAVE [IO_THREAD|SQL_THREAD];

如果主节点已经运行了一段时间，且有大量数据时，如何配置并启动slave节点
  • 通过备份恢复数据至从服务器
  • 复制起始位置为备份时，二进制日志文件及其POS
如果要启用级联复制,需要在从服务器启用以下配置

[mysqld]
log_bin
log_slave_updates

MHA

MHA：Master High Availability，对主节点进行监控，可实现自动故障转移至其它从节点；通过提升某一从节点为新的主节点，基于主从复制实现，还需要客户端配合实现，目前MHA主要支持一主多从的架构，要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库，出于机器成本的考虑，淘宝进行了改造，目前淘宝TMHA已经支持一主一从
官网:https://code.google.com/archive/p/mysql-master-ha/

MHA集群架构

3191127224.png

MHA

813191149760.png

MHA工作原理

MHA工作原理
1 从宕机崩溃的master保存二进制日志事件（binlog events）
2 识别含有最新更新的slave
3 应用差异的中继日志（relay log）到其他的slave
4 应用从master保存的二进制日志事件（binlog events）
5 提升一个slave为新的master
6 使其他的slave连接新的master进行复制

MHA软件由两部分组成，Manager工具包和Node工具包

Manager工具包主要包括以下几个工具：

  • masterha_check_ssh 检查MHA的SSH配置状况
  • masterha_check_repl 检查MySQL复制状况
  • masterha_manger 启动MHA
  • masterha_check_status 检测当前MHA运行状态
  • masterha_master_monitor 检测master是否宕机
  • masterha_master_switch 故障转移（自动或手动）
  • masterha_conf_host 添加或删除配置的server信息

Node工具包：这些工具通常由MHA Manager的脚本触发，无需人为操作）主要包括以下几个工具：

  • save_binary_logs 保存和复制master的二进制日志
  • apply_diff_relay_logs 识别差异的中继日志事件并将其差异的事件应用于其他的slave
  • filter_mysqlbinlog 去除不必要的ROLLBACK事件（MHA已不再使用此工具)
  • purge_relay_logs 清除中继日志（不会阻塞SQL线程）

注意：为了尽可能的减少主库硬件损坏宕机造成的数据丢失，因此在配置MHA的同时建议配置成MySQL 5.5的半同步复制

自定义扩展：

  • secondary_check_script： 通过多条网络路由检测master的可用性
  • master_ip_ailover_script： 更新Application使用的masterip
  • shutdown_script： 强制关闭master节点
  • report_script： 发送报告
  • init_conf_load_script： 加载初始配置参数
  • master_ip_online_change_script：更新master节点ip地址

配置文件：
global配置，为各application提供默认配置
application配置：为每个主从复制集群

实现MHA

在管理节点上安装两个包：
mha4mysql-manager
mha4mysql-node

在被管理节点安装：
mha4mysql-node

在管理节点建立配置文件

vim /etc/mastermha/app1.cnf
[server default]
user=mhauser
password=magedu
manager_workdir=/data/mastermha/app1/
manager_log=/data/mastermha/app1/manager.log
remote_workdir=/data/mastermha/app1/
ssh_user=root
repl_user=repluser
repl_password=magedu
ping_interval=1
[server1]
hostname=192.168.8.17
candidate_master=1
[server2]
hostname=192.168.8.27
candidate_master=1
[server3]
hostname=192.168.8.37

实现Master

vim /etc/my.cnf
[mysqld]
log-bin
server_id=1
skip_name_resolve=1



mysql>show master logs
mysql>grant replication slave on *.* to repluser@'192.168.8.%' identified by ‘magedu';
mysql>grant all on *.* to mhauser@'192.168.8.%’identified by‘magedu';

实现slave

vim /etc/my.cnf
[mysqld]
server_id=2 #不同节点此值各不相同
log-bin
read_only
relay_log_purge=0
skip_name_resolve=1


mysql>CHANGE MASTER TO MASTER_HOST=‘MASTER_IP', MASTER_USER='repluser', MASTER_PASSWORD=‘magedu', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=245;

在所有节点实现相互之间ssh key验证

Mha验证和启动

masterha_check_ssh --conf=/etc/mastermha/app1.cnf
masterha_check_repl --conf=/etc/mastermha/app1.cnf
masterha_manager --conf=/etc/mastermha/app1.cnf

排错日志

/data/mastermha/app1/manager.log

实验：模拟数据库崩溃并用二进制日志还原

前提条件：二进制日志启用

假设每天凌晨2点自动备份

mysqldump -A -master-data=2 > /data/all.sql

在18点时数据库崩溃，之间的增删改操作被二进制日志记录下来

现在需要还原，注意事项如下：

  • 还原时设置数据库只能本机访问

  • 还原自动备份前务必关闭二进制日志的功能，因为在数据库恢复all.sql时会将记录写至二进制日志中，这不是我们想要的

    # 临时停止sql_log_bin,该变量是会话级变量，不会生成二进制日志
set sql_log_bin=off;

  • 在我们之前备份的all.sql文件中找到二进制日志位置

    -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000005', MASTER_LOG_POS=18652;

  • 将该文件成为保存为增量备份

    [root@localhost logbin]# mysqlbinlog --start-position=18652  mysql-bin.000005 > /data/inc.sql

# 如果还有其他的增量，可以以追加的形式储存
mysqlbinlog  mysql-bin.000006 >> /data/inc.sql

还原部分

MariaDB [(none)]> source /data/all.sql
MariaDB [(none)]> source /data/inc.sql

将二进制日志打开

set sql_log_bin=ON;

检查数据是否恢复成功，将防火墙打开

误删除某一张表的恢复思路

同删库恢复操作相同，重要的是在二进制日志文件中找出DROP命令，并注释掉

模拟删库的正确姿势

rm -rf /var/lib/mysql/*

删的是数据库文件下的文件，而不是整个文件夹，重启服务就会自动生成

删了文件夹，就得重新创建mysql文件夹，再更改相应权限

练习

1、编写脚本，支持让用户自主选择，使用mysqldump还是xtrabackup全量备份。

[root@localhost scripts]# vim Backup.sh 

#!/bin/bash
mkdir /data/backup
BACKDIR=/data/backup

USER=root

PASSWD=root

while true;do
echo "请选择备份工具：【1】mysqldump    【2】xtrabackup     【3】退出"
read -p "选择：" choose

case "$choose" in

1)

mysqldump  -A -F --single-transaction --master-data=1 --default-character-set=utf8mb4 > $BACKDIR/backup.sql

;;

2)
innobackupex --user=$USER --password=$PASSWD $BACKDIR

;;

3)

echo "Bye!" && exit 2
;;

*)

echo "ERROR INPUT" && exit 3
;;

esac

done

2、配置Mysql主从同步

  1. 准备两台主机192.168.33.148【从节点】,192.168.33.132【主节点】
  2. 同时安装mariadb
  3. 配置主节点：
[root@localhost yum.repos.d]# vim /etc/my.cnf

[mysqld]
server-id=132
# 配置唯一serverID
log-bin
# 启用二进制日志
  1. 在主节点上建立从节点账号
[root@localhost yum.repos.d]# systemctl start mariadb
[root@localhost yum.repos.d]# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.5.64-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> grant replication slave on *.* to repluser@'192.168.33.%' identified by 'centos';
Query OK, 0 rows affected (0.00 sec)
  1. 配置从节点
[root@localhost ~]# vim /etc/my.cnf

[mysqld]
server-id=148
read-only
# 开启只读
  1. 添加主节点信息
MariaDB [(none)]> CHANGE MASTER TO
    -> MASTER_HOST='192.168.33.132',
    -> MASTER_USER = 'repluser',
    -> MASTER_PASSWORD = 'centos',
    -> MASTER_LOG_FILE= 'mariadb-bin.000001',
    -> MASTER_LOG_POS = 245;
Query OK, 0 rows affected (0.00 sec)


# 查看从节点slave信息
MariaDB [(none)]> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 192.168.33.132
                  Master_User: repluser
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mariadb-bin.000001
          Read_Master_Log_Pos: 245
               Relay_Log_File: mariadb-relay-bin.000001
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mariadb-bin.000001
             Slave_IO_Running: No
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 245
              Relay_Log_Space: 245
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 0
1 row in set (0.00 sec)

MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)
  1. 验证
# 在主节点中建立test123数据库，查看从节点是否同步
MariaDB [(none)]> create database test123;
Query OK, 1 row affected (0.00 sec)

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

# 查看从节点
MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
| test123            |
+--------------------+
5 rows in set (0.00 sec)

# 成功

3、使用MHA实现Mysql高可用。

1.准备3个数据库服务器配置主从，1个MHA管理主机节点
  • 主节点：192.168.33.155
  • 从节点1: 192.168.33.156
  • 从节点2: 192.168.33.157
  • MHA节点：192.168.33.149
2.配置主从

主节点：

[root@localhost ~]# vim /etc/my.cnf

[mysqld]
server_id=155
log-bin
skip_name_resolve=1
# 跳过DNS解析


MariaDB [(none)]> show master logs;
+--------------------+-----------+
| Log_name           | File_size |
+--------------------+-----------+
| mariadb-bin.000001 |       245 |
+--------------------+-----------+
1 row in set (0.00 sec)


MariaDB [(none)]> grant replication slave on *.* to repluser@'192.168.33.%' identified by 'centos';
Query OK, 0 rows affected (0.00 sec)


MariaDB [(none)]> grant all on *.* to mhauser@'192.168.33.%' identified by 'centos';
Query OK, 0 rows affected (0.00 sec)

从节点：

[root@localhost ~]# vim /etc/my.cnf

[mysqld]
server_id=156
log-bin
read_only
relay_log_purge=0
skip_name_resolve=1



MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='192.168.33.155', MASTER_USER='repluser', MASTER_PASSWORD='centos', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=245;
Query OK, 0 rows affected (0.01 sec)


MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.00 sec)
3.安装mha4mysql包

在管理节点上安装两个包：
mha4mysql-manager
mha4mysql-node
在被管理节点安装：
mha4mysql-node

4.MHA管理节点

在管理节点建立配置文件

[root@localhost ~]# vim /etc/mastermha/app.cnf

[server default]
user=mhauser
password=centos
manager_workdir=/data/mastermha/app/
manager_log=/data/mastermha/app/manager.log
remote_workdir=/data/mastermha/app/
ssh_user=root
repl_user=repluser
repl_password=centos
ping_interval=1
[server1]
hostname=192.168.33.155
candidate_master=1
[server2]
hostname=192.168.33.156
candidate_master=1
[server3]
hostname=192.168.33.157

基于ssh认证,在manager主机上生成公钥，发给管理的节点

[root@localhost ~]# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:5d07Ja8rlYeLMlPoHntU5tOi2zIdb2WtCa6jkweAXzA root@localhost
The key's randomart image is:
+---[RSA 2048]----+
|                 |
|      E          |
|     . o  .      |
|    . . .o . .o  |
|     . oS ...+o+o|
|      . . . + O=*|
|         +.+ *o@o|
|        o BoO.=oo|
|        .=+B.=+o |
+----[SHA256]-----+


# 将生成的公钥先拷贝给自己
[root@localhost ~]# ssh-copy-id 192.168.33.149
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
The authenticity of host '192.168.33.149 (192.168.33.149)' can't be established.
ECDSA key fingerprint is SHA256:pJIXGoHj4VpWRUFXBduYkV5Iag1hv9jY3av6a8XmIA8.
ECDSA key fingerprint is MD5:9c:e7:70:b7:47:fd:a9:a4:ed:7f:2b:50:78:ff:37:39.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@192.168.33.149's password: 
Permission denied, please try again.
root@192.168.33.149's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '192.168.33.149'"
and check to make sure that only the key(s) you wanted were added.

# 查看生成的公钥并将公钥传给要管理的节点
scp -r .ssh 192.168.33.155:/root/
scp -r .ssh 192.168.33.156:/root/
scp -r .ssh 192.168.33.157:/root/


# 检查manager运行条件是否满足
[root@localhost mastermha]# masterha_check_ssh --conf=/etc/mastermha/app.cnf

[root@localhost mastermha]# masterha_check_repl --conf=/etc/mastermha/app.cnf


# 启用
[root@localhost mastermha]# masterha_manager --conf=/etc/mastermha/app.cnf

至此，准备条件已全部准备完毕，MHA正常运行

5.模拟主节点故障，检查从节点是否切为主节点

查看日志文件/data/mastermha/app/manager.log

Sat Aug 15 19:09:37 2020 - [info] 
192.168.33.155(192.168.33.155:3306) (current master)
 +--192.168.33.156(192.168.33.156:3306)
 +--192.168.33.157(192.168.33.157:3306)

Sat Aug 15 19:09:37 2020 - [warning] master_ip_failover_script is not defined.
Sat Aug 15 19:09:37 2020 - [warning] shutdown_script is not defined.
Sat Aug 15 19:09:37 2020 - [info] Set master ping interval 1 seconds.
Sat Aug 15 19:09:37 2020 - [warning] secondary_check_script is not defined. It is highly recommended setting it to check master reachability from two or more routes.
Sat Aug 15 19:09:37 2020 - [info] Starting ping health check on 192.168.33.155(192.168.33.155:3306)..
Sat Aug 15 19:09:37 2020 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn't respond..
Sat Aug 15 19:12:18 2020 - [warning] Got error on MySQL select ping: 2006 (MySQL server has gone away)
Sat Aug 15 19:12:18 2020 - [info] Executing SSH check script: save_binary_logs --command=test --start_pos=4 --binlog_dir=/var/lib/mysql,/var/log/mysql --output_file=/data/mastermha/app//save_binary_logs_test --manager_version=0.56 --binlog_prefix=mariadb-bin
Sat Aug 15 19:12:18 2020 - [warning] HealthCheck: SSH to 192.168.33.155 is NOT reachable.
Sat Aug 15 19:12:19 2020 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.33.155' (111))
Sat Aug 15 19:12:19 2020 - [warning] Connection failed 2 time(s)..
Sat Aug 15 19:12:20 2020 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.33.155' (111))
Sat Aug 15 19:12:20 2020 - [warning] Connection failed 3 time(s)..
Sat Aug 15 19:12:21 2020 - [warning] Got error on MySQL connect: 2003 (Can't connect to MySQL server on '192.168.33.155' (111))
Sat Aug 15 19:12:21 2020 - [warning] Connection failed 4 time(s)..
Sat Aug 15 19:12:21 2020 - [warning] Master is not reachable from health checker!
Sat Aug 15 19:12:21 2020 - [warning] Master 192.168.33.155(192.168.33.155:3306) is not reachable!
Sat Aug 15 19:12:21 2020 - [warning] SSH is NOT reachable.
Sat Aug 15 19:12:21 2020 - [info] Connecting to a master server failed. Reading configuration file /etc/masterha_default.cnf and /etc/mastermha/app.cnf again, and trying to connect to all servers to check server status..
Sat Aug 15 19:12:21 2020 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.
Sat Aug 15 19:12:21 2020 - [info] Reading application default configuration from /etc/mastermha/app.cnf..
Sat Aug 15 19:12:21 2020 - [info] Reading server configuration from /etc/mastermha/app.cnf..
Sat Aug 15 19:12:22 2020 - [info] GTID failover mode = 0
Sat Aug 15 19:12:22 2020 - [info] Dead Servers:
Sat Aug 15 19:12:22 2020 - [info]   192.168.33.155(192.168.33.155:3306)
Sat Aug 15 19:12:22 2020 - [info] Alive Servers:
Sat Aug 15 19:12:22 2020 - [info]   192.168.33.156(192.168.33.156:3306)
Sat Aug 15 19:12:22 2020 - [info]   192.168.33.157(192.168.33.157:3306)
Sat Aug 15 19:12:22 2020 - [info] Alive Slaves:
Sat Aug 15 19:12:22 2020 - [info]   192.168.33.156(192.168.33.156:3306)  Version=5.5.64-MariaDB (oldest major version between slaves) log-bin:enabled
Sat Aug 15 19:12:22 2020 - [info]     Replicating from 192.168.33.155(192.168.33.155:3306)
Sat Aug 15 19:12:22 2020 - [info]     Primary candidate for the new Master (candidate_master is set)
Sat Aug 15 19:12:22 2020 - [info]   192.168.33.157(192.168.33.157:3306)  Version=5.5.64-MariaDB (oldest major version between slaves) log-bin:enabled
Sat Aug 15 19:12:22 2020 - [info]     Replicating from 192.168.33.155(192.168.33.155:3306)
Sat Aug 15 19:12:22 2020 - [info] Checking slave configurations..
Sat Aug 15 19:12:22 2020 - [warning]  relay_log_purge=0 is not set on slave 192.168.33.156(192.168.33.156:3306).
Sat Aug 15 19:12:22 2020 - [warning]  relay_log_purge=0 is not set on slave 192.168.33.157(192.168.33.157:3306).
Sat Aug 15 19:12:22 2020 - [info] Checking replication filtering settings..
Sat Aug 15 19:12:22 2020 - [info]  Replication filtering check ok.
Sat Aug 15 19:12:22 2020 - [info] Master is down!
Sat Aug 15 19:12:22 2020 - [info] Terminating monitoring script.
Sat Aug 15 19:12:22 2020 - [info] Got exit code 20 (Master dead).
Sat Aug 15 19:12:22 2020 - [info] MHA::MasterFailover version 0.56.
Sat Aug 15 19:12:22 2020 - [info] Starting master failover.
Sat Aug 15 19:12:22 2020 - [info] 
Sat Aug 15 19:12:22 2020 - [info] * Phase 1: Configuration Check Phase..
Sat Aug 15 19:12:22 2020 - [info] 
Sat Aug 15 19:12:23 2020 - [info] GTID failover mode = 0
Sat Aug 15 19:12:23 2020 - [info] Dead Servers:
Sat Aug 15 19:12:23 2020 - [info]   192.168.33.155(192.168.33.155:3306)
Sat Aug 15 19:12:23 2020 - [info] Checking master reachability via MySQL(double check)...
Sat Aug 15 19:12:24 2020 - [info]  ok.
Sat Aug 15 19:12:24 2020 - [info] Alive Servers:
Sat Aug 15 19:12:24 2020 - [info]   192.168.33.156(192.168.33.156:3306)
Sat Aug 15 19:12:24 2020 - [info]   192.168.33.157(192.168.33.157:3306)
Sat Aug 15 19:12:24 2020 - [info] Alive Slaves:
Sat Aug 15 19:12:24 2020 - [info]   192.168.33.156(192.168.33.156:3306)  Version=5.5.64-MariaDB (oldest major version between slaves) log-bin:enabled
Sat Aug 15 19:12:24 2020 - [info]     Replicating from 192.168.33.155(192.168.33.155:3306)
Sat Aug 15 19:12:24 2020 - [info]     Primary candidate for the new Master (candidate_master is set)
Sat Aug 15 19:12:24 2020 - [info]   192.168.33.157(192.168.33.157:3306)  Version=5.5.64-MariaDB (oldest major version between slaves) log-bin:enabled
Sat Aug 15 19:12:24 2020 - [info]     Replicating from 192.168.33.155(192.168.33.155:3306)
Sat Aug 15 19:12:24 2020 - [info] Starting Non-GTID based failover.
Sat Aug 15 19:12:24 2020 - [info] 
Sat Aug 15 19:12:24 2020 - [info] ** Phase 1: Configuration Check Phase completed.
Sat Aug 15 19:12:24 2020 - [info] 
Sat Aug 15 19:12:24 2020 - [info] * Phase 2: Dead Master Shutdown Phase..
Sat Aug 15 19:12:24 2020 - [info] 
Sat Aug 15 19:12:24 2020 - [info] Forcing shutdown so that applications never connect to the current master..
Sat Aug 15 19:12:24 2020 - [warning] master_ip_failover_script is not set. Skipping invalidating dead master IP address.
Sat Aug 15 19:12:24 2020 - [warning] shutdown_script is not set. Skipping explicit shutting down of the dead master.
Sat Aug 15 19:12:25 2020 - [info] * Phase 2: Dead Master Shutdown Phase completed.
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] * Phase 3: Master Recovery Phase..
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] * Phase 3.1: Getting Latest Slaves Phase..
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] The latest binary log file/position on all slaves is mariadb-bin.000001:540
Sat Aug 15 19:12:25 2020 - [info] Latest slaves (Slaves that received relay log files to the latest):
Sat Aug 15 19:12:25 2020 - [info]   192.168.33.156(192.168.33.156:3306)  Version=5.5.64-MariaDB (oldest major version between slaves) log-bin:enabled
Sat Aug 15 19:12:25 2020 - [info]     Replicating from 192.168.33.155(192.168.33.155:3306)
Sat Aug 15 19:12:25 2020 - [info]     Primary candidate for the new Master (candidate_master is set)
Sat Aug 15 19:12:25 2020 - [info]   192.168.33.157(192.168.33.157:3306)  Version=5.5.64-MariaDB (oldest major version between slaves) log-bin:enabled
Sat Aug 15 19:12:25 2020 - [info]     Replicating from 192.168.33.155(192.168.33.155:3306)
Sat Aug 15 19:12:25 2020 - [info] The oldest binary log file/position on all slaves is mariadb-bin.000001:540
Sat Aug 15 19:12:25 2020 - [info] Oldest slaves:
Sat Aug 15 19:12:25 2020 - [info]   192.168.33.156(192.168.33.156:3306)  Version=5.5.64-MariaDB (oldest major version between slaves) log-bin:enabled
Sat Aug 15 19:12:25 2020 - [info]     Replicating from 192.168.33.155(192.168.33.155:3306)
Sat Aug 15 19:12:25 2020 - [info]     Primary candidate for the new Master (candidate_master is set)
Sat Aug 15 19:12:25 2020 - [info]   192.168.33.157(192.168.33.157:3306)  Version=5.5.64-MariaDB (oldest major version between slaves) log-bin:enabled
Sat Aug 15 19:12:25 2020 - [info]     Replicating from 192.168.33.155(192.168.33.155:3306)
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] * Phase 3.2: Saving Dead Master's Binlog Phase..
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [warning] Dead Master is not SSH reachable. Could not save it's binlogs. Transactions that were not sent to the latest slave (Read_Master_Log_Pos to the tail of the dead master's binlog) were lost.
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] * Phase 3.3: Determining New Master Phase..
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] Finding the latest slave that has all relay logs for recovering other slaves..
Sat Aug 15 19:12:25 2020 - [info] All slaves received relay logs to the same position. No need to resync each other.
Sat Aug 15 19:12:25 2020 - [info] Searching new master from slaves..
Sat Aug 15 19:12:25 2020 - [info]  Candidate masters from the configuration file:
Sat Aug 15 19:12:25 2020 - [info]   192.168.33.156(192.168.33.156:3306)  Version=5.5.64-MariaDB (oldest major version between slaves) log-bin:enabled
Sat Aug 15 19:12:25 2020 - [info]     Replicating from 192.168.33.155(192.168.33.155:3306)
Sat Aug 15 19:12:25 2020 - [info]     Primary candidate for the new Master (candidate_master is set)
Sat Aug 15 19:12:25 2020 - [info]  Non-candidate masters:
Sat Aug 15 19:12:25 2020 - [info]  Searching from candidate_master slaves which have received the latest relay log events..
Sat Aug 15 19:12:25 2020 - [info] New master is 192.168.33.156(192.168.33.156:3306)
Sat Aug 15 19:12:25 2020 - [info] Starting master failover..
Sat Aug 15 19:12:25 2020 - [info] 
From:
192.168.33.155(192.168.33.155:3306) (current master)
 +--192.168.33.156(192.168.33.156:3306)
 +--192.168.33.157(192.168.33.157:3306)

To:
192.168.33.156(192.168.33.156:3306) (new master)
 +--192.168.33.157(192.168.33.157:3306)
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] * Phase 3.3: New Master Diff Log Generation Phase..
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info]  This server has all relay logs. No need to generate diff files from the latest slave.
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] * Phase 3.4: Master Log Apply Phase..
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] *NOTICE: If any error happens from this phase, manual recovery is needed.
Sat Aug 15 19:12:25 2020 - [info] Starting recovery on 192.168.33.156(192.168.33.156:3306)..
Sat Aug 15 19:12:25 2020 - [info]  This server has all relay logs. Waiting all logs to be applied.. 
Sat Aug 15 19:12:25 2020 - [info]   done.
Sat Aug 15 19:12:25 2020 - [info]  All relay logs were successfully applied.
Sat Aug 15 19:12:25 2020 - [info] Getting new master's binlog name and position..
Sat Aug 15 19:12:25 2020 - [info]  mariadb-bin.000001:245
Sat Aug 15 19:12:25 2020 - [info]  All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST='192.168.33.156', MASTER_PORT=3306, MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=245, MASTER_USER='repluser', MASTER_PASSWORD='xxx';
Sat Aug 15 19:12:25 2020 - [warning] master_ip_failover_script is not set. Skipping taking over new master IP address.
Sat Aug 15 19:12:25 2020 - [info] Setting read_only=0 on 192.168.33.156(192.168.33.156:3306)..
Sat Aug 15 19:12:25 2020 - [info]  ok.
Sat Aug 15 19:12:25 2020 - [info] ** Finished master recovery successfully.
Sat Aug 15 19:12:25 2020 - [info] * Phase 3: Master Recovery Phase completed.
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] * Phase 4: Slaves Recovery Phase..
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] * Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..
Sat Aug 15 19:12:25 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info] -- Slave diff file generation on host 192.168.33.157(192.168.33.157:3306) started, pid: 52731. Check tmp log /data/mastermha/app//192.168.33.157_3306_20200815191222.log if it takes time..
Sat Aug 15 19:12:26 2020 - [info] 
Sat Aug 15 19:12:26 2020 - [info] Log messages from 192.168.33.157 ...
Sat Aug 15 19:12:26 2020 - [info] 
Sat Aug 15 19:12:25 2020 - [info]  This server has all relay logs. No need to generate diff files from the latest slave.
Sat Aug 15 19:12:26 2020 - [info] End of log messages from 192.168.33.157.
Sat Aug 15 19:12:26 2020 - [info] -- 192.168.33.157(192.168.33.157:3306) has the latest relay log events.
Sat Aug 15 19:12:26 2020 - [info] Generating relay diff files from the latest slave succeeded.
Sat Aug 15 19:12:26 2020 - [info] 
Sat Aug 15 19:12:26 2020 - [info] * Phase 4.2: Starting Parallel Slave Log Apply Phase..
Sat Aug 15 19:12:26 2020 - [info] 
Sat Aug 15 19:12:26 2020 - [info] -- Slave recovery on host 192.168.33.157(192.168.33.157:3306) started, pid: 52756. Check tmp log /data/mastermha/app//192.168.33.157_3306_20200815191222.log if it takes time..
Sat Aug 15 19:12:27 2020 - [info] 
Sat Aug 15 19:12:27 2020 - [info] Log messages from 192.168.33.157 ...
Sat Aug 15 19:12:27 2020 - [info] 
Sat Aug 15 19:12:26 2020 - [info] Starting recovery on 192.168.33.157(192.168.33.157:3306)..
Sat Aug 15 19:12:26 2020 - [info]  This server has all relay logs. Waiting all logs to be applied.. 
Sat Aug 15 19:12:26 2020 - [info]   done.
Sat Aug 15 19:12:26 2020 - [info]  All relay logs were successfully applied.
Sat Aug 15 19:12:26 2020 - [info]  Resetting slave 192.168.33.157(192.168.33.157:3306) and starting replication from the new master 192.168.33.156(192.168.33.156:3306)..
Sat Aug 15 19:12:26 2020 - [info]  Executed CHANGE MASTER.
Sat Aug 15 19:12:26 2020 - [info]  Slave started.
Sat Aug 15 19:12:27 2020 - [info] End of log messages from 192.168.33.157.
Sat Aug 15 19:12:27 2020 - [info] -- Slave recovery on host 192.168.33.157(192.168.33.157:3306) succeeded.
Sat Aug 15 19:12:27 2020 - [info] All new slave servers recovered successfully.
Sat Aug 15 19:12:27 2020 - [info] 
Sat Aug 15 19:12:27 2020 - [info] * Phase 5: New master cleanup phase..
Sat Aug 15 19:12:27 2020 - [info] 
Sat Aug 15 19:12:27 2020 - [info] Resetting slave info on the new master..
Sat Aug 15 19:12:27 2020 - [info]  192.168.33.156: Resetting slave info succeeded.
Sat Aug 15 19:12:27 2020 - [info] Master failover to 192.168.33.156(192.168.33.156:3306) completed successfully.
Sat Aug 15 19:12:27 2020 - [info] 

----- Failover Report -----

app: MySQL Master failover 192.168.33.155(192.168.33.155:3306) to 192.168.33.156(192.168.33.156:3306) succeeded

Master 192.168.33.155(192.168.33.155:3306) is down!

Check MHA Manager logs at localhost:/data/mastermha/app/manager.log for details.

Started automated(non-interactive) failover.
The latest slave 192.168.33.156(192.168.33.156:3306) has all relay logs for recovery.
Selected 192.168.33.156(192.168.33.156:3306) as a new master.
192.168.33.156(192.168.33.156:3306): OK: Applying all logs succeeded.
192.168.33.157(192.168.33.157:3306): This host has the latest relay log events.
Generating relay diff files from the latest slave succeeded.
192.168.33.157(192.168.33.157:3306): OK: Applying all logs succeeded. Slave started, replicating from 192.168.33.156(192.168.33.156:3306)
192.168.33.156(192.168.33.156:3306): Resetting slave info succeeded.
Master failover to 192.168.33.156(192.168.33.156:3306) completed successfully.

检查从节点192.168.33.156 read_only值

MariaDB [(none)]> show variables like 'read%';
+----------------------+--------+
| Variable_name        | Value  |
+----------------------+--------+
| read_buffer_size     | 131072 |
| read_only            | OFF    |
| read_rnd_buffer_size | 262144 |
+----------------------+--------+
3 rows in set (0.00 sec)

# read_only 已经关闭
# 该节点已经变为主节点
FlamencaH
关注
专栏目录
MySQL从删库到跑路： 入门篇
m0_50897967的博客
11-20 1243
删库第一步，先入个门。
MySQL从删库到跑路
qq_45926335的博客
03-05 479
删库！一离职程序员报复前公司
redditnote的博客
12-11 551
(给技术最前线加星标，每天看技术热点)转自：中国新闻网日前，意大利威尼达计算机数据软件公司发生了一宗数据库信息被盗和删除事件。一名该公司的离职程序员，涉嫌多次入侵公司数据...
MySQL从删库到跑路（一）
m0_73552988的博客
10-15 726
大家在学习C语言或C++时，期末作业一般都会要求写一个学生管理系统，对于C语言和C++，数据都是通过结构体将数据保存到内存中，程序运行结束后数据会消失，数据具有瞬时性，不能长久保存。有没有什么好的方法呢？
从删库到跑路
我思故我在
08-15 618
今天写写数据误删怎么办 = = 一 预防 大于 恢复 删了之后怎么恢复数据，那都是事后操作，在事情发生前，如何避免问题发生，用较少的资源合理有效避免降低风险才是王道，下面聊聊如何避免 误删数据。 1 权限 一般情况下，操作线上数据的所有入口都会有权限，一般都会给开发人员线上查询的权限，像这种的，就完全杜绝删除更改数据操作语句，做上限制，不给更改数据的权限。 如果要修复线上数据，一般都是有审批流的（其实一般审核的都不看），所以也要做限制，sql_safe_updates 参数设...
Mysql从简到杂，从删库到跑路！
m0_54790214的博客
03-02 880
mysql从简到杂，从删库到跑路！
MySQL，从删库到跑路
vincen world
09-14 3587
1、删除表中指定记录 MariaDB [vincen]> DELETE FROM 数据表名 where 指定条件; 2、同时删除表中的记录 MariaDB [vincen]> DELETE FROM 数据表名 where 字段名 BETWEEN 条件1 AND 条件2; 3、删除表中所有的记录 MariaDB [vincen]> DELETE FROM 数据表名...
Mysql从删库到跑路.pdf
09-30
Mysql从删库到跑路.pdf
深入浅析MySQL从删库到跑路_高级（一）——数据完整性
09-09
在实际操作中，应谨慎处理数据，尤其是在执行删除操作时，以避免可能导致数据丢失或破坏数据完整性的行为，比如“删库跑路”这样的极端情况。因此，数据库管理策略和备份计划是保障数据安全的重要环节。
MySQL DBA从入门到删库跑路-视频教程网盘链接提取码下载 .txt
05-26
MySQL DBA从入门到删库跑路课程基于前篇的基础课程升级而来，课程分为了数据库进阶实战课程和DBA运维实战教程部分，分别从更深入的角度进行课程学习，帮助同学们一次性吃透MySQL DBA课程。 视频大小：4.6G
Mysql从删库到跑路
dreamingcrazy的博客
08-24 2222
1、开启bin-log 打开mysql配置文件 /etc/mysql/my.cnf（这个位置不是固定的，根据你安装的mysql目录去找） 放开log_bin这一行 log_bin = /var/log/mysql/mysql-bin.log 随后重启mysql 即执行 /etc/init.d/mysql restart 进入数据库，查看log_bin开启...
mysql 从删库到跑路
chenglinquan的博客
03-22 5788
https://segmentfault.com/a/1190000013088179
Mysql从删库到跑路（1）
m0_47630931的博客
07-07 847
文章目录前言初识Mysqlmysql是啥呢什么是数据库DBMS操作数据库基本操作数据库中的数据类型操作数据表列的一些其他属性数据表的引擎基本操作总结 前言 终于放假了，前段时间一直忙着复习功课考试，也没时间更新博客，这就补上，暑假就复习巩固学过的知识吧，那就从Mysql开始吧 初识Mysql mysql是啥呢 它是一个数据库，一个用来存储关系型数据的仓库 在现实生活中，它是怎么被运用的？ 像下图这样，浏览器向服务器发送一个请求，服务器去访问数据库的内容，再给客户端以响应，这也就是我们所说的B/S模式（浏览
【从删库到跑路】一文带你明白MySQL数据库的 事务 操作
小吉妙妙屋
07-08 1063
使用样例详细讲解MySQL数据库的事务操作
从删库到跑路(二）
FlamencaH的博客
07-28 576
服务器选项配置及性能优化 mysqld选项，服务器系统变量和服务器状态变量 mysql mariadb --是服务器选项 注意：其中有些参数支持运行时修改，会立即生效；有些参数不支持，且只能通过修改配置文件，并重启服务器程序生效；有些参数作用域是全局的，且不可改变；有些可以为每个用户提供单独（会话）的设置 获取mysqld的可用选项列表 mysqld --help --verbose mysqld --print-defaults # 获取默认设置 设置服务器选项方法 在命令行中设置 ./mysq
MySQL从删库到跑路（二）
最新发布
m0_73552988的博客
10-16 701
首先介绍一下MySQL文件夹下主要目录的作用：bin放二进制文件，比如一些命令；include头文件；lib引用的一些库、一些依赖；share保存一些字符编码，比如utf-8、gbk使用MySQL的时候一般在命令行中，后面的教程会在图形界面中操作数据库，默认使用的是Windows自带的cmd，如果大家觉得不好用，推荐大家使用Hyper，用什么终端都无所谓，不影响学习使用MySQL。首先大家需要了解，SQL语言是一种大小写不敏感的语言，因此学习使用过程中大家不必过于在意书写形式。
从删库到跑路，老大爷学Java的心酸历程
程序员青戈
05-28 6994
rm -rf 背后的真香警告，今天你学废了吗？
从删库到跑路，只差一条拼接命令
xiaofan23z的专栏
03-05 744
欢迎关注作者墨天伦：潇湘秦的个人主页 - 墨天轮公众号：潇湘秦的DBA之路。
又双叒叕发删库跑路！关于删库跑路的一切都在这里
路人甲Java
02-27 1943
你以为“删库跑路”只是IT圈子里的一个玩笑话？别笑...这件事儿，它又双叒叕发生了!!!...这一次倒霉的是微盟。据官方最新消息，2月23日晚间，微盟的业务系统数据库（包括主备）遭内部人...
MySQL数据完整性：从删库到跑路的高级分析
然而，对于"删库跑路"的行为，这是对数据库管理的一种不当操作，通常是由于安全问题或数据泄露导致的极端措施，应尽量避免并采取有效的备份策略来保护数据安全。本文后续部分可能会针对这种情景提供更深入的分析和...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值