记一次调整异地备份方案，减轻文件传输消耗的案例

• 问题发现

  运维反映说，流量留出峰值呈规律性，监控图如下：

• 原异地容灾方案 

结合原上地机房做的异地容灾方案，将数据备份至阿里服务器上一份，总共13库，总数据量26G左右，备份方式采用是mysqldump备份方式，备份时间是凌晨的2点

• 流量留出峰值原因

mysqldump方式完全是将上地26G的数据通过IP/TCP方式传输到了阿里机房，速度的快慢当然取决于上地机房的出口带宽了，从上面的监控图中可以很清楚的明白这一点

• 调整方案

看着最近7日的规律性”驼峰”，再结合原来的异地容灾方案，遂决定调整异地备份方案，减轻文件传输消耗。而原上地数据库每日都会做本地备份，并且进行压缩存储，压缩后的数据总数据量总共才为6G左右，通过FTP或expect免交互式方式传输到阿里服务器上，将会减少20G的带宽消耗，而且是每天

• 免交互式脚本文件

cat remote.exp
#!/usr/bin/expect
set timeout 3
set dbname [lindex $argv 0]    #绑定命令行第一个变量
set password "userpwd"    #设置用来传输文件的用户密码       
spawn scp $dbname username@serverip:/server_path    #将本地压缩后的文件传输到阿里服务器
expect "username@'s password:"
send "$password\n"
expect off

cat remote_backup.sh
#!/bin/bash
time=`date "+%F"`
dataBases="dbname list"

cd /shell_path
for db in $dataBases
do
  dbname="${db}-${time}.sql.gz"
  expect remote.exp /local_backfile_path/$dbname
done

• 添加上地服务器上的计划任务

0 2 * * * sh /shell_path/remote_backup.sh

OK，已经拿其中的小库测试过了，没有问题，但是。。。第二天检查时发现：

• 上地服务器本地备份文件

du -sh {dbname1,dbname2,xxx}-2018-11-28.sql.gz
2.5G	dbname1-2018-11-28.sql.gz
265M dbname2-2018-11-28.sql.gz
xxx

• 阿里服务器上（异地容灾）的备份文件

du -sh {dbname1,dbname2,xxx}-2018-11-28.sql.gz

12M  dbname1-2018-11-28.sql.gz

9.9M dbname2-2018-11-28.sql.gz

xxx

什么情况？？！！文件大小不一样？？？

第一直觉是怀疑文件传输的不完整，只传输了部分数据，所以打算在自己的测试环境将其中的一个小库导进入看看缺失了些什么，结果如下：

gunzip dbname-2018-11-28.sql.gz 
gzip: dbname-2018-11-28.sql.gz: unexpected end of file

显而易见，文件不只是不完整，而是损坏了，也就是说脚本执行的可能有问题（因为之前测脚本的时候用的是小库测的，而对于大库看其大小只是传输了一部分，导致了损坏！）

故，拿大库测试如下：

sh remote_backup.sh 
spawn scp dbname-2018-11-28.sql.gz username@serverip:/server_path
12% 6160KB   3.4MB/s   00:12 ETA

可以看到，文件传输了12%即被终止，这也正是阿里上备份文件损坏的原因所在！也就是说脚本确实是存在问题的，

百度了下，expect用法，将文件传输脚本，调整如下：

• 调整后的脚本文件

cat remote.exp
#!/usr/bin/expect
set timeout 3
set dbname [lindex $argv 0]    
set password "userpwd"         
spawn scp $dbname username@serverip:/server_path    
expect "username@'s password:"
send "$password\n"
#设置文件的传输时间
set timeout 10800
send "exit\n"
expect off

再次执行：

sh remote_backup.sh 
spawn scp dbname-2018-11-28.sql.gz username@serverip:/server_path 
100%   563MB 814.5KB/s

这次OK了，看来是需要设置传输时间，踩了一个坑（对expect还不是很熟练啊，哈哈）

现在的监控图：

PS：前几天也是一直在找问题，所以异地的备份流量几乎为0，真正看到调整后效果的是从12-02，可以清晰的看到流量峰值已经被消掉了一个，持续时间大大降低了！