2016-08-11 14 views
1

MySQLデータベースをAmazon S3バケットに1時間ごとにバックアップするPythonスクリプトがあります。私はダンプを作成するためにmysqldumpを呼び出すだけでtinys3を使ってS3バケットにアップロードしますが、lock-tablesをfalseに設定して他のアプリケーションによるトランザクションに支障をきたさないよう注意してください。ここで Pythonを使用したMySQLバックアップでサーバーがクラッシュする

はあなたの参照のためのスクリプトです:

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

MySQLがクラッシュしたときにログを取得しますか? – Chris

+0

MySQLだけでなく、サーバー全体がダウンして再起動する必要があります。 MySQLエラーログにはエラーも表示されません。 –

答えて

2

ここで起こっていることを想像するのは簡単です。 Mysqldumpが遅いです。修復が悪い。

相当量のデータをバックアップするための高速またはスケーラブルなソリューションはありません。大きなデータサイズの場合、たとえバックアップ のステップが妥当な時間を要しても、SQLステートメントの再生に挿入用のディスクI/O、 インデックスの作成などが含まれているため、データの復元は非常に遅くなる可能性があります( )。

バックアップを取ったら、それを圧縮してからamazon s3にアップロードします。私の推測では、最初のバックアップが完了する前に2回目のバックアップが開始され、サーバーが圧倒されるまでエスカレートし続けます。

サーバーがクラッシュしなくても、数か月後には記憶容量が膨大になるため、この方法を使用しないでください。

はるかに良い方法があります。 Mysql replication。 cronjobsはありません、マストがダウンした場合にはほとんど回復しません。大量のデータ転送はありません。

関連する問題