Hi everybody,
it looks like the reason for the problem was me not handling string arguments
properly (I did not use the provided lengths, but relied on string being
null-terminated, it's in the doc, but ...). It seems this became a problem
specifically in the parallel situation, misleading me i
A variant on that...
1. pre-validate slave's consistency using pt-table-checksum
2. dump slave, wipe clean, restore
3. RE-validate slave's consistency using pt-table-checksum
> -Original Message-
> From: Stillman, Benjamin [mailto:bstill...@limitedbrands.com]
> Sent: Wednesday, November 07
In the past when I used mysqldump, I used a slave database for backups and
periodically testing restores.
My process for testing:
- Stop the slave process (so the db doesn't get updated).
- Run the backup.
- Create restore_test database.
- Restore the backup to the restore_test database.
- Use my
2012/11/7 Ananda Kumar
> you can use checksum to make sure there are not corruption in the file
That would work for the file integrity itself not for the data integrity
_in_ the file.
As Claudio suggested, probably going thru the whole recovery process from
time to time is the best way to mak
you can use checksum to make sure there are not corruption in the file
On Wed, Nov 7, 2012 at 6:39 PM, Claudio Nanni wrote:
> Gary,
>
> It is always a good practice to test the whole solution backup/restore.
> So nothing is better than testing a restore, actually it should be a
> periodic procedu
Gary,
It is always a good practice to test the whole solution backup/restore.
So nothing is better than testing a restore, actually it should be a
periodic procedure.
As for the validity of the file usually is delegated to the operating
system.
If you want to check it yourself you may create an al
