search

pombreda / scalr

Automatically exported from code.google.com/p/scalr
0 stars 0 forks source link

S3 upload of database snapshot does not handle errors #21

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
S3 upload of (mysqllvm64) snapshot still does not handle errors from
S3 correctly, and since files are left from previous snapshots, this
causes data corruption.

What steps will reproduce the problem?
1. Manually initiate a database bundling
(/usr/local/aws/user/bin/mysql-data-bundle.sh)
2. When S3 upload fails with Internal Error 500 (DEBUG: ERROR: S3 error:
500 (Internal Server Error): InternalError), no upload retry is made.
3. When a new database is started based on the bundle, it either has
file(s) missing or it has file(s) left over from a previous bundle. This
causes data corruptions.

What is the expected output? What do you see instead?
The expected process would be for 
1. Upload retries will be made upon failures
2. Some mechanism should exist to distinguish between files from previous
bundles to avoid data corruption (i.e do not simply rely on new files
replacing old files).

What version of the product are you using? On what operating system?

Please provide any additional information below.

ysql-snapshot.tar.amu (157286400 bytes)
DEBUG: File '/mnt/mysql-misc/snapshot/mysql-snapshot.tar.amv' stored
as s3://FARM-522-637754916194/farm-mysql/mysql-snapshot.tar.amv
(157286400 bytes)
DEBUG: ERROR: S3 error: 500 (Internal Server Error): InternalError
DEBUG: File '/mnt/mysql-misc/snapshot/mysql-snapshot.tar.amx' stored
as s3://FARM-522-637754916194/farm-mysql/mysql-snapshot.tar.amx
(157286400 bytes)
DEBUG: File '/mnt/mysql-misc/snapshot/mysql-snapshot.tar.amy' sto

Due to the 500 error, the file mysql-snapshot.tar.amw was NOT replaced
in S3.

Original issue reported on code.google.com by nivsin...@gmail.com on 20 Nov 2008 at 10:26

GoogleCodeExporter commented 9 years ago 
This error was fixed in scalr-ami-scripts-0.2-39, but the package was not 
upgraded on
your instances.
We've automatically upgraded scripts on all instances and the problem should go 
away.

Original comment by hin...@gmail.com on 21 Nov 2008 at 9:28