使用 python 备份 MySQL 时服务器崩溃答案

【问题标题】：Server crash on MySQL backup using python使用 python 备份 MySQL 时服务器崩溃
【发布时间】：2016-12-17 20:34:26
【问题描述】：

我有一个 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 相关？

【问题讨论】：

当 MySQL 崩溃时你会得到任何日志吗？
整个服务器宕机了，必须重新启动，而不仅仅是 MySQL。 MySQL 错误日志也不显示任何错误。

标签： python mysql amazon-s3

【解决方案1】：

很容易想象这里发生了什么。 Mysqldump 很慢。恢复更糟。

它并非旨在作为一种快速或可扩展的备份解决方案大量的数据。数据量大，即使备份步骤需要合理的时间，恢复数据可能会很慢因为重放 SQL 语句涉及插入的磁盘 I/O，索引创建等等。

备份后，您似乎会对其进行压缩，然后将其上传到 amazon s3。我的猜测是您的第二次备份在第一次备份完成之前开始，并且它会不断升级，直到服务器不堪重负。

即使您的服务器没有崩溃，您仍然不应该使用这种方法，因为几个月后您将花费大量的存储空间。

有一个更好的方法。 Mysql replication。没有 cronjobs，如果桅杆发生故障，几乎可以立即恢复，没有大量数据传输。

【讨论】：