记一次innobackupex工具恢复数据库过程

innobackupex工具恢复数据库

今天正在午休的时候,同事突然给了一份dummy.tar的innobackupex备份数据,需要我恢复一下.因为是innobackupex全量备份,那么第一件事情自然就是准备虚拟机了.好在我平常就有镜像当前操作系统作为沙箱环境的习惯.接下来事情就简单了.

安装数据库

  • 操作系统环境(virtualbox):ubuntu16.0.4

首先安装mysql

sudo apt install mysql

接着安装innobackupex工具,innobackupex工具实际上是percona公司推出的一款数据库备份工具,它实际的名字其实是percona-xtrabackup,所以接下来要把这个工具下载下来

我的操作系统是ubuntu16.0.4,根据页面上对应的版本,选择对应的下载资源

wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.12/binary/debian/xenial/x86_64/Percona-XtraBackup-2.4.12-r170eb8c-xenial-x86_64-bundle.tar

解压

tar -xvf Percona-XtraBackup-2.4.12-r170eb8c-xenial-x86_64-bundle.tar

安装

sudo dpkg -i *.deb

修复依赖

sudo apt -f install

验证

which innobackupex

恢复数据

我的备份文件是dummy.tar,解压之后的格式如下,如果你的备份文件不包含下面的文件,说明你的备份文件不对

.
├── backup-my.cnf
├── ib_buffer_pool
├── ibdata1
├── mysql
├── performance_schema
├── sys
├── xtrabackup_checkpoints
├── xtrabackup_info
└── xtrabackup_logfile

我的压缩包一开始就是没有tar后缀的tar文件,结果就一直没办法备份下来,然后尝试性质的使用tar解压一下,才把目录给解压出来的

  • 恢复数据(恢复数据之前,必须要关闭数据库,并且当前用户需要有对数据库目录的权限)

使用apt安装的mysql,数据目录在/var/lib/mysql ,配置文件在/etc/mysql/my.cnf

关闭数据库

sudo service mysql stop

删除数据库原有的文件(删除之前,要确保你的数据库没有可用的数据,如果有可用的数据库,一定要先做备份,或者选择虚拟机来进行恢复工作)

sudo rm -rf /vat/lib/mysql/*

恢复数据

恢复数据有两个过程,首先是apply-log 然后才是cpoy-back

sudo innobackupex --defaults-file=/etc/mysql/my.cnf --user=root --password=123456 --use-memory=4G --apply-log /backup/mysql/data/dummy 
sudo innobackupex --defaults-file=/etc/mysql/my.cnf --user=root --password=123456 --copy-back /backup/mysql/data/dummy

恢复mysql权限(可能需要的操作如果权限不对,mysql将无法启动)

sudo own mysql:mysql -R /var/lib/mysql

重新启动数据库

sudo service mysql start

备份之后,数据库密码就不再是你原来的密码了,而是你备份的数据库的密码

记一次服务器优化

服务器环境

  • 双核心cpu 8G内存
  • 操作系统:centos6
  • web服务器: apache2.4
  • php版本: 5.6
  • mysql版本:5.5

起因

公司的网站在最近一段时间访问变的非常的缓慢,作为公司唯一略懂linux运维的人,这个任务毫无疑问的就落到了我的头上了,于是请求到了ssh权限之后,就开始了我的工作了。

问题分析

首先网站本身的访问量是不多的,猜测应该不是自然负载很高

其次服务器的代码和数据库并没有任何人动过

那么我唯一能想到的原因就是网站被ddos了,接下来验证一下猜想

解决过程

首先ssh到服务器,使用top命令查看一下当前服务器的负载情况,检测到httpd进程占用了cpu达到百分之百

这么就确定是被ddos了,接下来只要分析apache的日志,把恶意的ip封禁掉就可以了

  • 日志文件在/home/wwwlogs/access_apache.log

  • 日志格式如下

124.239.252.4 - - 2018-10-26 11:49:15 "OPTIONS * HTTP/1.0" 200 -

在awk处理的时候,以空格为分隔符,每一列分别对应$1,$2.....$9...

如果你的apache日志和我的不一样 那么通过打开http.conf修改LogFormat如下,然后重启httpd服务

LogFormat "%h %l %u %{%Y-%m-%d %H:%M:%S}t \"%r\" %>s %b" common

使用tail+awk组合命令对日志文件进行分析

tail -n 10000 /home/wwwlogs/access_apache.log  | awk '{A[$1]++;}END{for (a in A) print A[a] "  "a}' | sort -n

通过这个列举出最近10000次内访问的ip地址, 并且能够看到ip地址数量

发现ip为124.239.252.4的机器在10000次内居然有2000次的访问量,那么很容易得出这不是人类所为,接下来只要利用iptable强大的功能,把这个ip给封掉就可以了

iptables -I INPUT -s 124.239.252.4 -p tcp --dport 80 -j DROP

如果要封禁124.239.252的ip段,ip应该填写(124.239.252.0/24),24表示掩码长度

封完之后还得记得把封掉的ip记录一下,方便误杀恢复

最后再使用top命令看一下cpu负载,发现cpu占用只有20%不到,那么便大功告成了

尽管可能又漏网之鱼,但影响不大就可以了,搞定之后,就可以愉快的去做其他的事情了.