mysql database backup, are copied from the primary semi-synchronous replication and

1, and by using mysqldump backup database backup and restore binary log data (write data are backed up before, then delete library)

mysqldump -A --single-transaction -F --master-data=2 > /data/backup/mysql.sql

-A backup all databases, - single-stransaction open transaction log backup -F refresh --master-data = 2 binary log recording position

Back up the database before

In the table insert a new record, which is not in full backup

Delete library

mysql -e 'drop database hellodb'

Temporarily disable the binary log before restoring. Avoid recording the restore process

source /data/backup/mysql.sql

Restore successful

After recording a full backup No restore.

Point of view /backup/mysql.sql record binary log file

Found from the log number 06, position 245. After that there is no backup,

Export binary log using mysqlbinlog

mysqlbinlog /var/lib/mysql/centos7-bin.000006 -v > /data/backup/log.sql

The drop database hellodb log file deletion

Then import binary log generated in the database.

Restore successful

2, and restore the backup data using xtrabackup

yum install percona-xtrabackup (epel)源

mkdir / data / backups create a temporary directory to store the backup files xtrabackup

xtrabackup --backup --target-dir = / data / backups / backup command executed on the machine to be backed up. The pre-prepared files are stored in a temporary directory

Temporary generated files

(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：备份生成的日志文件

scp -r /data/backups/ 192.168.242.129:/data/ 将备份文件拷贝到目标机器

还原注意事项：

1.datadir 目录必须为空。除非指定innobackupex --force-non-empty-directorires选项指定，否则--copy-backup选项不会覆盖

2.在restore之前,必须shutdown MySQL实例，不能将一个运行中的实例restore到datadir目录中

3.由于文件属性会被保留，大部分情况下需要在启动实例之前将文件的属主改为mysql，这些文件将属于创建备份的用户

chown -R mysql:mysql /data/mysql

以上需要在用户调用innobackupex之前完成

在目标主机执行xtrabackup --prpare --target-dir=/data/backups （预准备工作)

生成了数据库文件

xtrabackup --copy-back --target-dir=/backups/ 将目录中的文件拷贝到数据库/var/lib/mysql中

修改文件属性为mysql

开始将目录中的所有的数控文件拷贝到系统的数据目录中

因为是从另一台机器拷贝过来的数据，需要修改文件属性

还原成功

3、MySQL数据备份企业实战(shell或python脚本实现)

使用xtrabackup以每周为一个备份周期做备份(数据库+二进制日志,备份至本地/data/backup)

提示: 周一某个时间点做一次完全备份,周二、三、四、五、六、日增量

备份存储目录"/data/backup/2018/52/1/备份数据" 目录解释"/data/backup/年/本年度的第几周/本周的第几天/数据" 一年52周一周7天

(Andy老师提供python备份脚本参考)

#!/bin/bash

for i in `seq 0 6`;do #循环6次

a=/data/backup/`date +%Y`/`date +%U`/ #存储目录变量

mkdir -p $a$i # #创建目录

t=`date +%w` #定义星期

if [ "$t" == "1" ];then #匹配星期周一为完全备份

xtrabackup --backup --target-dir=/data/backup &> /dev/null && echo backup ok

else

if [ "$t" == "2" ];then #匹配星期周二为增量备份

xtrabackup --backup --target-dir="$a"1 --incremental-basedir=/data/backup &> /dev/null && echo backup ok

elif [ "$t" == "3" ];then

xtrabackup --backup --target-dir="$a"2 --incremental-basedir="$a"1 &> /dev/null && echo backup ok

elif [ "$t" == "4" ];then

xtrabackup --backup --target-dir="$a"3 --incremental-basedir="$a"2 &> /dev/null && echo backup ok

elif [ "$t" == "5" ];then

xtrabackup --backup --target-dir="$a"4 --incremental-basedir="$a"3 &> /dev/null && echo backup ok

elif [ "$t" == "6" ];then

xtrabackup --backup --target-dir="$a"5 --incremental-basedir="$a"4 &> /dev/null && echo backup ok

elif [ "$t" == "0" ];then

xtrabackup --backup --target-dir="$a"6 --incremental-basedir="$a"5 &> /dev/null && echo backup ok

done

[root@centos7 ~]# crontab -l

0 2 * * * root /root/b.sh

写入计划任务。每晚执行一遍备份。周一则完全备份

4、描述MySQL复制工作原理并实现主从,主主,主从级联及半同步复制

一台mysql数据库的并发连接数是有限的，当访问量大的时候，可能一台服务器压力太大。如果数据库压力过大宕机了。则会有数据丢失的风险和用户体验过差，所以，我们可以利用mysql的复制。一台主机，多台备用机，当一台主数据库写入数据，则将二进制日志复制到其他从服务器上，实现同步过程，如果主服务器宕机，则自动从多台从服务器挑选一台充当主服务器，避免宕机时间过长

复制原理

当主服务器收到数据更新请求，会写入二进制日志中。在本机中，有一个专门的dump的主服务器线程将二进制日志出来往从服务器线程发。然后发给从服务器。从服务器有一个io thread线程然后写到relay log （类似二进制日志）日志中。在交给sql thread 在从服务器中更改数据

主从

在主服务器配置文件

log-bin=/data/logbin/mysql-bin #启用二进制日志

server-id=1 #指定服务器编号

在从服务器配置

server-id=2 #区别于主服务器编号

read_only=on #为了安全从服务器设置为只读，防止修改

在主服务器创建并授权复制账号

grant replication slave on *.* to test@'192.168.64.%' identified by 'centos';

主服务器数据库

从服务器数据库

在从服务器执行主服务器修改master 信息

CHANGE MASTER TO

MASTER_HOST='192.168.64.128',#主服务ip

MASTER_USER='test',#用那个账号复制

MASTER_PASSWORD='centos',#账户口令

MASTER_PORT=3306,#端口

MASTER_LOG_FILE='mysql-bin.000003',#从那个二进制日志开始复制

MASTER_LOG_POS=245;#从二进制日志的开始内容复制

查看从节点信息

start slave;从服务器执行复制之后就不需要在执行

复制成功

级联复制：主复制复制给从服务器。在从从服务器复制给其他从服务器

主服务器配置文件不变

创建并授权复制账号

grant replication slave on *.* to test@'192.168.64.%' identified by 'centos';

在中间节点上修改配置文件

加入log_slave_updates将主节点二进制日志记录到自己的日志中

并开启二进制日志，需要将日志复制给下一个节点

修改master to 信息

CHANGE MASTER TO

MASTER_HOST='192.168.64.128',

MASTER_USER='test',

MASTER_PASSWORD='centos',

MASTER_PORT=3306,

MASTER_LOG_FILE='mysql-bin.000001',

MASTER_LOG_POS=245;

start slave；开启复制

主服务器导入表

中间节点开始导入数据

在最后一个节点修改配置文件，关闭二进制日志，从中间节点复制过来二进制日志

启动数据库，修改master信息为中间节点

CHANGE MASTER TO

MASTER_HOST='192.168.64.130',

MASTER_USER='test',

MASTER_PASSWORD='centos',

MASTER_PORT=3306,

MASTER_LOG_FILE='mysql-bin.000001',

MASTER_LOG_POS=245;

同步成功

主主复制：互为主从

容易产生的问题：数据不一致；因此慎用

考虑要点：自动增长id

配置一个节点使用奇数id

auto_increment_offset=1 开始点

auto_increment_increment=2 增长幅度

另一个节点使用偶数id

auto_increment_offset=2

auto_increment_increment=2

修改主配置文件

修改另一台主配置文件

创建账号

grant replication slave on *.* to test@'192.168.64.%' identified by 'centos';

在第二台主机修改master 信息

CHANGE MASTER TO

MASTER_HOST='192.168.64.128',

MASTER_USER='test',

MASTER_PASSWORD='centos',

MASTER_PORT=3306,

MASTER_LOG_FILE='mysql-bin.000001',

MASTER_LOG_POS=245;

在第一台主机配置

CHANGE MASTER TO

MASTER_HOST='192.168.64.130',

MASTER_USER='test',

MASTER_PASSWORD='centos',

MASTER_PORT=3306,

MASTER_LOG_FILE='mysql-bin.000001',

MASTER_LOG_POS=245;

启动复制 start slave;

半同步复制

默认情况下，MySQL的复制功能是异步的，异步复制可以提供最佳的性能，主

库把binlog日志发送给从库即结束，并不验证从库是否接收完毕。这意味着当

主服务器或从服务器端发生故障时，有可能从服务器没有接收到主服务器发送

过来的binlog日志，这就会造成主服务器和从服务器的数据不一致，甚至在恢

复时造成数据的丢失

在主服务器安装一个半同步插件模块semisync_master.so';

先实现标准的主从复制

在主服务器安装插件/usr/lib64/mysql/plugin/semisync_master.so

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

在配置文件加入配置

在从节点安装插件semisync_slave.so

INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

并写入配置文件

查看插件状态是否启动

SHOW GLOBAL VARIABLES LIKE '%semi%';

SHOW GLOBAL STATUS LIKE '%semi%';

重新启动线程 stop slave； start slave；实现半同步复制

5、描述MySQL Proxy原理并实现读写分离

MySQL Proxy处于客户端应用程序和MySQL服务器之间，通过截断、改变并转发客户端和后端数据库之间的通信来实现其功能，这和WinGate 之类的网络代理服务器的基本思想是一样的。代理服务器是和TCP/IP协议打交道，而要理解MySQL Proxy的工作机制，同样要清楚MySQL客户端和服务器之间的通信协议，MySQL Protocol 包括认证和查询两个基本过程：

认证过程包括：

客户端向服务器发起连接请求

服务器向客户端发送握手信息

客户端向服务器发送认证请求

服务器向客户端发送认证结果

如果认证通过，则进入查询过程：

客户端向服务器发起查询请求

服务器向客户端返回查询结果

当然，这只是一个粗略的描述，每个过程中发送的包都是有固定格式的，想详细了解MySQL Protocol的同学，可以去这里看看。MySQL Proxy要做的，就是介入协议的各个过程。首先MySQL Proxy以服务器的身份接受客户端请求，根据配置对这些请求进行分析处理，然后以客户端的身份转发给相应的后端数据库服务器，再接受服务器的信息，返回给客户端。所以MySQL Proxy需要同时实现客户端和服务器的协议。由于要对客户端发送过来的SQL语句进行分析，还需要包含一个SQL解析器。可以说MySQL Proxy相当于一个轻量级的MySQL了，实际上，MySQL Proxy的admin server是可以接受SQL来查询状态信息的

在调度器安装proxysql 调度器

配置一下yum源

cat <<EOF | tee /etc/yum.repos.d/proxysql.repo

[proxysql_repo]

name= ProxySQL YUM repository

baseurl=http://repo.proxysql.com/ProxySQL/proxysql-1.4.x/centos/\$releasever

gpgcheck=1

gpgkey=http://repo.proxysql.com/ProxySQL/repo_pub_key

EOF

yum install proxysql 安装调度器

调度器配置为数据库方式，所以要启动数据库

启动服务

准备：实现读写分离前，先实现主从复制

注意：slave节点需要设置read_only=1

启动ProxySQL：service proxysql start

启动后会监听两个默认端口

6032：ProxySQL的管理端口

6033：ProxySQL对外提供服务的端口

使用mysql客户端连接到ProxySQL的管理接口6032，默认管理员用户和密码都

是admin：

mysql -uadmin -padmin -P6032 -h127.0.0.1

在数据库中插入数据库服务器的地址和编号，这里编号统一为10，后面会自己识别主从服务器

根据数据库的配置文件read-only这项来区分

MySQL > load mysql servers to runtim

MySQL > save mysql servers to disk;

加载配置并存盘

在主数据库创建账号让proxysql 监控并自动调整读组和写组

grant replication client on *.* to monitor@'192.168.64.%' identified by 'centos';

在proxysql调度器加入监控账号和密码。并且加载生效

将都组和写组写入表中。test为描述可有可无

insert into mysql_replication_hostgroups values(10,20,"test");

分组成功，如果不成功，可手写如记录改变编号

创建测试账号在主服务器

grant all on *.* to sqluser@'192.168.64.%' identified by 'centos';

在proxysql服务器加入到mysq_user中

在ProxySQL配置，将用户sqluser添加到mysql_users表中， default_hostgroup默认

组设置为写组10，当读写分离的路由规则不符合时，会访问默认组的数据库

insert into mysql_users(username,password,default_hostgroup)values('sqluser','centos',10);

保存并生效

load mysql users to runtim；

save mysql users to disk;

在proxysql调度器上用sqluser账户连接，利用6033端口。

默认sqluser在10这个主机组。也就是mysql的主数据库默认所有操作都在主数据库上操作。

配置路由规则。实现读写分离

与规则有关的表：mysql_query_rules和mysql_query_rules_fast_routing，

插入路由规则：将select语句分离到20的读组，select语句中有一个特殊语句

SELECT...FOR UPDATE它会申请写锁，应路由到10的写组

insert into mysql_query_rules

(rule_id,active,match_digest,destination_hostgroup,apply)VALUES

(1,1,'^SELECT.*FOR UPDATE$',10,1),(2,1,'^SELECT',20,1);

##除了读操作发往从节点，其他操作都发往主节点

到此，读写分离配置完成

验证。读为从服务器

mysql -usqluser -pcentos -P6033 -h127.0.0.1 -e 'select @@server_id'

利用事物查看，为主服务器

6、使用MHA及galera实现MySQL的高可用性

MHA工作原理

1 从宕机崩溃的master保存二进制日志事件（binlog events）

2 识别含有最新更新的slave

3 应用差异的中继日志（relay log）到其他的slave

4 应用从master保存的二进制日志事件（binlog events）

5 提升一个slave为新的master

6 使其他的slave连接新的master进行复制

mha实验前

skip-name-resolv建议在所有主从节点加上这项，跳过名字解析，避免mha实验出现解析问题

MHA软件由两部分组成，Manager（管理节点）工具包和Node（被管理节点）工具包

https://code.google.com/archive/p/mysql-master-ha/ 可在官网下载

搭建步骤：

在主数据库节点创建一个管理账号

grant all on *.* to mhauser@'192.168.64.%’identified by‘centos';

在从节点数据库中加入

vim /etc/my.cnf

[mysqld]

server_id=2 #不同节点此值各不相同

log-bin #启用二进制，实现高可用

read_only #因为上面建立的账号可自动关闭这个选项，也可以不加入配置文件

relay_log_purge=0 #中继日志，如果主服务宕机数据没拷贝过去从的话需要启用中继

skip_name_resolve=1 #跳过名字解析

然后在所有机器实现sshkey验证，如果主节点出现问题，可用ssh协议将主服务器的配置文件拷出来

生成密钥

ssh-copy-id 192.168.64.133 到自己的机器上，在将生成的文件拷贝到其他机器上实现key验证

在管理节点上安装两个包：

mha4mysql-manager

mha4mysql-node

在被管理节点安装：

mha4mysql-node

在管理节点建立配置文件写入被管理节点的信息

vim /etc/mastermha/app1.cnf

[server default]

user=mhauser #主节点授权的账号

password=centos #密码

manager_workdir=/data/mastermha/app1/ #管理目录

manager_log=/data/mastermha/app1/manager.log#日志

remote_workdir=/data/mastermha/app1/ #在远程节点创建的目录

ssh_user=root #利用ssh账号远处管理节点

repl_user=repluser

repl_password=centos

ping_interval=1

[server1] #需要监控的节点信息

hostname=192.168.64.130

candidate_master=1 #表示这两台服务器有能力当主节点

[server2]

hostname=192.168.64.131

candidate_master=1

[server3]

hostname=192.168.64.132

Mha验证和启动

masterha_check_ssh --conf=/etc/mastermha/app1.cnf #测试ssh协议是否联通

调用我们上面写的配置文件

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

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

配置完成

galera cluster实现高可用性

Galera Cluster：集成了Galera插件的MySQL集群，是一种新型的，数据

不共享的，高度冗余的高可用方案，目前Galera Cluster有两个版本，分

别是Percona Xtradb Cluster及MariaDB Cluster，Galera本身是具有多

主特性的，即采用multi-master的集群架构，是一个既稳健，又在数据一

致性、完整性及高性能方面有出色表现的高可用解决方案

Galera Cluster特点

多主架构：真正的多点读写的集群，在任何时候读写数据，都是最新的

同步复制：集群不同节点之间数据同步，没有延迟，在数据库挂掉之后，数据

不会丢失

并发复制：从节点APPLY数据时，支持并行执行，更好的性能

故障切换：在出现数据库故障时，因支持多点写入，切换容易

热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务

时间就会非常少。在节点故障期间，节点本身对集群的影响非常小

自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不需要

人工手动备份提供，Galera Cluster会自动拉取在线节点数据，最终集群会变为

一致

对应用透明：集群的维护，对应用程序是透明的

gelare需要安装专门的数据库且不能装mariadb数据库

配置yum源，下载MariaDB-Galera-server

vim /etc/yum.repos.d/base.repo

[base]

baseurl=https://mirrors.tuna.tsinghua.edu.cn/mariadb/mariadb-5.5.64/yum/centos7-amd64/

gpgcheck=0

复制到其他主机上。最少三台

修改配置文件

vim /etc/my.cnf.d/server.cnf

[galera]

wsrep_provider = /usr/lib64/galera/libgalera_smm.so #提供的库文件路劲

wsrep_cluster_address="gcomm://192.168.64.128,192.168.64.130.,192.168.64.131"#集群服务器的节点分别是谁

binlog_format=row #二进制日志为行显示

default_storage_engine=InnoDB #默认存储引擎

innodb_autoinc_lock_mode=2 #加锁的模式

bind-address=0.0.0.0

首次启动时，需要初始化集群，在其中一个节点上执行命令

/etc/init.d/mysql start --wsrep-new-cluster

而后正常启动其它节点

service mysql start

配置完成。

mysql database backup, are copied from the primary semi-synchronous replication and

Guess you like