>
> If time is pressing, and he's not sure how to get mysqldump to
> function properly, I'd suggest shutting down the mysql server, taking
> a tarball backup of /var/lib/mysql (or wherever the database files
> are), compressing that (xz is nice for these purposes), and then
> getting the mysqldump backup.
I'm a bit confused here. If I get a tarball and compress that, then is that
for download and moving to the other server? Is this just in case the
mysqldump does not work at all.
>
> As for getting the mysql dump itself, if he's not sure what privileges
> are set up, I'd probably skip resetting permissions and instead taking
> the dump from a daemon running under --skip-grant-tables.
So, I start mysql-server with the option --skip-grant-tables and then try to
do the mysqldump?
>
> It all depends on how much time he has before the system becomes
> unavailable to him.
>
>
In my previous email, I point out that the error now is different. It is
error 28 from the storage engine. So, I have to google that and see what
that means.
Thanks,
Bruce
>Definitely another option.
>The only thing I would say is if getting the dump under --skip-grant-tables
you need to make absolutely >sure external access to the database is blocked
as the daemon will presumably be running a lot longer in
->-skip-grant-tables to complete a dump than it would be just to reset a
password.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
