我有一个python脚本,每小时将我的MySQL数据库备份到Amazon S3存储桶。我使用脚本只需调用mysqldump
以创建转储,然后使用tinys3
将其上传到S3存储桶,请注意我将lock-tables
设置为false,以便其他应用程序进行事务处理不受阻碍。
以下是供您参考的脚本:
import tinys3
import os
from django.core.wsgi import get_wsgi_application
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "my_project.settings")
application = get_wsgi_application()
from django.utils import timezone
import pytz
import datetime
import json
timezone.activate(pytz.timezone("Asia/Kolkata"))
current_datetime = timezone.localtime(
datetime.datetime.utcnow().replace(tzinfo=pytz.utc)
)
dir_struct = '/'.join(current_datetime.strftime("%Y-%m-%d-%H-%M-%S").split('-'))
endpoint = 's3-us-west-2.amazonaws.com'
params = json.load(open('buckets.json'))
S3_ACCESS_KEY=params['S3_ACCESS_KEY']
S3_SECRET_KEY = params["S3_SECRET_KEY"]
bucket = params['mysql']
db_name = params['db_name']
mysql_command = 'sudo mysqldump --defaults-file=/home/ubuntu/.my.cnf --lock-tables=false %s > /home/ubuntu/%s.sql' %(db_name, db_name)
compress_command = "zip -r /home/ubuntu/%s.sql.zip /home/ubuntu/%s.sql" %(db_name, db_name)
delete_command = "sudo rm -rf /home/ubuntu/%s.sql*" %db_name
os.system(mysql_command)
os.system(compress_command)
backup_file = open('/home/ubuntu/%s.sql.zip' %db_name, 'rb')
conn = tinys3.Connection(S3_ACCESS_KEY, S3_SECRET_KEY, tls=True,endpoint=endpoint)
print conn.upload(
(dir_struct+'%s.sql.zip' %db_name),
backup_file,
bucket,
public=False
)
print conn.get((dir_struct+'%s.sql.zip' %db_name),bucket)
os.system(delete_command)
问题是,当我每小时启动cron作业运行此脚本时,服务器会在几个小时后崩溃(比如说5到7个小时)。我还没有找到这种行为的重要原因。这里有什么问题?这个脚本中有错误或与MySQL有关吗?
答案 0 :(得分:2)
很容易想象这里发生了什么。 Mysqldump很慢。恢复更糟。
它不是一种快速或可扩展的备份解决方案 大量数据。具有大数据大小,即使备份 步骤需要一段合理的时间,恢复数据可能会很慢 因为重放SQL语句涉及用于插入的磁盘I / O, 索引创建等。
一旦你进行了备份,你就会把它压缩,然后上传到亚马逊s3。我的猜测是你的第二次备份在第一次备份完成之前就开始了,它会不断升级,直到服务器不堪重负。
即使您的服务器没有崩溃,您仍然不应该使用这种方法,因为在几个月的时间内,您将花费大量资金进行存储。
有一个更好的方法。 Mysql replication。没有cronjobs,如果桅杆下降几乎不会恢复,没有庞大的数据传输。