Database recovery
Hi, I have recently had a system crash that required the installation of a new hard drive. I have access to the files on the old hard drive, on which is a database I need to recover. I am running MySql 3.23.37 and all the tables in the database to be recovered are MyISAM. How can I recover the old database onto a new server with only file access? The documentation suggests to me that I need to copy all the *.frm, *.MYD, and *.MYI files. If this is the case, where should I copy them to on the new server? The technical director is away and I am in charge of this recovery... I dont want to get it wrong, so *any* help is greatly appreciated. Andy Hall.
Re: Database recovery
Hi, I have recently had a system crash that required the installation of a new hard drive. I have access to the files on the old hard drive, on which is a database I need to recover. I am running MySql 3.23.37 and all the tables in the database to be recovered are MyISAM. How can I recover the old database onto a new server with only file access? The documentation suggests to me that I need to copy all the *.frm, *.MYD, and *.MYI files. If this is the case, where should I copy them to on the new server? Each table in MySQL is represented by a MYD, MYI, and frm file. These are collected in directories, each of which represents a database. So copy the files, along with the directories they were in (which represent the databases), except for the mysql database, into the MySQL data directory. For example, if you used the RPM install, this directory will be /var/lib/mysql, or wherever you extracted the binary install to if you've used the binary installation. Then restart MySQL, and it will pick up the databases. -- Alex -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Database recovery
Andy Hall [EMAIL PROTECTED] wrote on 07/04/2004 09:50:19: Hi, I have recently had a system crash that required the installation of a new hard drive. I have access to the files on the old hard drive, on which is a database I need to recover. I am running MySql 3.23.37 and all the tables in the database to be recovered are MyISAM. How can I recover the old database onto a new server with only file access? The documentation suggests to me that I need to copy all the *.frm, *.MYD, and *.MYI files. If this is the case, where should I copy them to on the new server? It would help for this sort of question if you said what OS you are using: the answer will vary with OS. Normally, you copy files from. to the mysql home directory/data/database name directory: on most Windows installations, this will be c:\mysql\data\database name. If you cannot find this, searching for files with the extension .MYI on the old disk might well find them for you. Alec -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Database recovery
Hi, I have recently had a system crash that required the installation of a new hard drive. I have access to the files on the old hard drive, on which is a database I need to recover. I am running MySql 3.23.37 and all the tables in the database to be recovered are MyISAM. How can I recover the old database onto a new server with only file access? The documentation suggests to me that I need to copy all the *.frm, *.MYD, and *.MYI files. If this is the case, where should I copy them to on the new server? Each table in MySQL is represented by a MYD, MYI, and frm file. These are collected in directories, each of which represents a database. So copy the files, along with the directories they were in (which represent the databases), except for the mysql database, into the MySQL data directory. For example, if you used the RPM install, this directory will be /var/lib/mysql, or wherever you extracted the binary install to if you've used the binary installation. Then restart MySQL, and it will pick up the databases. Hi, Thanks for the info. I now have all the frm MYD and MYI files under a new directory within MySQL. How do I restart the service manually? Would it be: /etc/rc.d/init.d/mysql restart I am using Apache web server on a Cobalt RAQ. Thanks -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Database recovery
Hi, I have recently had a system crash that required the installation of a new hard drive. I have access to the files on the old hard drive, on which is a database I need to recover. I am running MySql 3.23.37 and all the tables in the database to be recovered are MyISAM. How can I recover the old database onto a new server with only file access? The documentation suggests to me that I need to copy all the *.frm, *.MYD, and *.MYI files. If this is the case, where should I copy them to on the new server? Each table in MySQL is represented by a MYD, MYI, and frm file. These are collected in directories, each of which represents a database. So copy the files, along with the directories they were in (which represent the databases), except for the mysql database, into the MySQL data directory. For example, if you used the RPM install, this directory will be /var/lib/mysql, or wherever you extracted the binary install to if you've used the binary installation. Then restart MySQL, and it will pick up the databases. Hi, Thanks for the info. I now have all the frm MYD and MYI files under a new directory within MySQL. How do I restart the service manually? Would it be: /etc/rc.d/init.d/mysql restart I am using Apache web server on a Cobalt RAQ. Thanks No matter, its all done. Thank you very much for your help. Regards Andy Hall. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: MySQL-Max database recovery crashed - Fixed!
Hi! Heikki == Heikki Tuuri [EMAIL PROTECTED] writes: I will have to include a warning in the comments section of the MySQL documentation to NOT CONVERT MySQL SYSTEM TABLES FROM myISAM TO INNODB TYPE! I have now added a warning about this to the manual. Regards, Monty - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
MySQL-Max database recovery crashed
I converted my myISAM tables to Innodb format and everything went fine. When I restarted MySQL-Max (2.23.43) I noticed that my query log file was not being accessed anymore so I included log=/var/lib/mysql/server1.log to /etc/my.cnf. Running MySQL-Max this time though caused a continuous restarting of the server: Number of processes running now: 0 011102 10:19:54 mysqld restarted Number of processes running now: 0 011102 10:19:54 mysqld restarted Number of processes running now: 0 011102 10:19:55 mysqld restarted etc. I then started mysqld-max manually and got the following message: InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 212830477 011102 10:26:57 InnoDB: Started mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked agaist is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail key_buffer_size=268431360 record_buffer=1044480 sort_buffer=1048568 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 466539 K bytes of memoryHope that's ok, if not, decrease some variables in the equation Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xb108, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x807b90f 0x8253c7a 0x80cf21a 0x8078693 0x807853d 0x80b202b 0x807c656 0x82639fb 0x8048111 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it It seems that the InnoDB crashed and caused some sort of database corruption. On restart, it tried to recover but couldn't. How do I recover the databases? Mysqldump requires the server to be running - right? My system: Redhat7.1, kernel 2.4.2-2, mysql-max 2.23.43 (same results with 2.23.44). Thanks for any help, Stephen - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MySQL-Max database recovery crashed
Stephen, I resolved the stack dump based on the 3.23.43 symbols file. I do not understand what mysqld is trying to do here. Are you sure the stack dump is from 3.23.43? 0x807b90f init_signals__Fv + 71 0x8253c7a __tfx + 26 0x80cf21a index_prev__11ha_innobasePc + 74 0x8078693 mysql_lock_remove__FP3THDP13st_mysql_lockP8st_table + 99 0x807853d mysql_lock_tables__FP3THDPP8st_tableUi + 557 0x80b202b acl_init__Fb + 795 0x807c656 main + 2678 0x82639fb __printf_fp + 5027 0x8048111 _start + 33 3.23.44 has a new my.cnf parameter. You could try set-variable = innodb_force_recovery=2 Does it now start to run? You can then try to dump your tables. See the manual at http://www.innodb.com/ibman.html section 6.1 about forcing recovery. Regards, Heikki Innobase Oy - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MySQL-Max database recovery crashed
Stephen, I resolved now with the mysql-max-3.23.44...tar.gz distribution. I still do not understand what mysqld is trying to do here. What distribution do you use, or did you compile yourself? 0x807b90f handle_segfault__Fi + 383 0x8253c7a pthread_sighandler + 106 0x80cf21a change_active_index__11ha_innobaseUi + 230 0x8078693 lock_external__FPP8st_tableUi + 107 0x807853d mysql_lock_tables__FP3THDPP8st_tableUi + 333 0x80b202b acl_init__Fb + 411 0x807c656 main + 2454 0x82639fb __libc_start_main + 99 0x8048111 _start + 33 Setting innodb_force_recovery to 6 does not help if the crash really comes from the above sequence. Please do not try it before we understand what the stack dump means. Have you tried taking the log=... option out from your my.cnf? Does the crash happen immediately after startup? With no database activity? Regards, Heikki At 11:56 AM 11/2/01 -0800, you wrote: Stephen, I resolved the stack dump based on the 3.23.43 symbols file. I do not understand what mysqld is trying to do here. Are you sure the stack dump is from 3.23.43? 0x807b90f init_signals__Fv + 71 0x8253c7a __tfx + 26 0x80cf21a index_prev__11ha_innobasePc + 74 0x8078693 mysql_lock_remove__FP3THDP13st_mysql_lockP8st_table + 99 0x807853d mysql_lock_tables__FP3THDPP8st_tableUi + 557 0x80b202b acl_init__Fb + 795 0x807c656 main + 2678 0x82639fb __printf_fp + 5027 0x8048111 _start + 33 3.23.44 has a new my.cnf parameter. You could try set-variable = innodb_force_recovery=2 Does it now start to run? You can then try to dump your tables. See the manual at http://www.innodb.com/ibman.html section 6.1 about forcing recovery. Regards, Heikki Innobase Oy Sorry, the dump was from 2.23.44. The above force recovery statement did not help. mysqld-max produced the following: InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 212830477 011102 11:48:59 InnoDB: Started mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked agaist is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail key_buffer_size=268431360 record_buffer=1044480 sort_buffer=1048568 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 466539 K bytes of memory Hope that's ok, if not, decrease some variables in the equation Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xb138, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x807b90f 0x8253c7a 0x80cf21a 0x8078693 0x807853d 0x80b202b 0x807c656 0x82639fb 0x8048111 New value of fp=(nil) failed sanity check, terminating stack trace! Would it hurt to try set-variable = innodb_force_recovery = 6 ? Thanks, Stephen - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MySQL-Max database recovery crashed
Heikki, Removal of the log= option and even the log-bin statement did not help. I used the latest (2.23.44) RPMs from one of the mysql.com mirrors. I don't think it's a download issue because the problem originally occured with the 2.23.43 distribution. The crash occurs within seconds of starting mysqld-max so the server never really runs. I did read the Forcing recovery section of the manual and it suggests that I might have to reboot to clear some memory condition. I will give that a try. Thanks, Stephen Stephen, I resolved now with the mysql-max-3.23.44...tar.gz distribution. I still do not understand what mysqld is trying to do here. What distribution do you use, or did you compile yourself? 0x807b90f handle_segfault__Fi + 383 0x8253c7a pthread_sighandler + 106 0x80cf21a change_active_index__11ha_innobaseUi + 230 0x8078693 lock_external__FPP8st_tableUi + 107 0x807853d mysql_lock_tables__FP3THDPP8st_tableUi + 333 0x80b202b acl_init__Fb + 411 0x807c656 main + 2454 0x82639fb __libc_start_main + 99 0x8048111 _start + 33 Setting innodb_force_recovery to 6 does not help if the crash really comes from the above sequence. Please do not try it before we understand what the stack dump means. Have you tried taking the log=... option out from your my.cnf? Does the crash happen immediately after startup? With no database activity? Regards, Heikki At 11:56 AM 11/2/01 -0800, you wrote: Stephen, I resolved the stack dump based on the 3.23.43 symbols file. I do not understand what mysqld is trying to do here. Are you sure the stack dump is from 3.23.43? 0x807b90f init_signals__Fv + 71 0x8253c7a __tfx + 26 0x80cf21a index_prev__11ha_innobasePc + 74 0x8078693 mysql_lock_remove__FP3THDP13st_mysql_lockP8st_table + 99 0x807853d mysql_lock_tables__FP3THDPP8st_tableUi + 557 0x80b202b acl_init__Fb + 795 0x807c656 main + 2678 0x82639fb __printf_fp + 5027 0x8048111 _start + 33 3.23.44 has a new my.cnf parameter. You could try set-variable = innodb_force_recovery=2 Does it now start to run? You can then try to dump your tables. See the manual at http://www.innodb.com/ibman.html section 6.1 about forcing recovery. Regards, Heikki Innobase Oy Sorry, the dump was from 2.23.44. The above force recovery statement did not help. mysqld-max produced the following: InnoDB: Database was not shut down normally. InnoDB: Starting recovery from log files... InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 212830477 011102 11:48:59 InnoDB: Started mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked agaist is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail key_buffer_size=268431360 record_buffer=1044480 sort_buffer=1048568 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (record_buffer + sort_buffer)*max_connections = 466539 K bytes of memory Hope that's ok, if not, decrease some variables in the equation Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xb138, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x807b90f 0x8253c7a 0x80cf21a 0x8078693 0x807853d 0x80b202b 0x807c656 0x82639fb 0x8048111 New value of fp=(nil) failed sanity check, terminating stack trace! Would it hurt to try set-variable = innodb_force_recovery = 6 ? Thanks, Stephen -- SPL Linux Systems www.spl-linux.com - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MySQL-Max database recovery crashed
Stephen, At 01:37 PM 11/2/01 -0800, you wrote: Stephen, At 12:38 PM 11/2/01 -0800, you wrote: Heikki, Removal of the log= option and even the log-bin statement did not help. I used the latest (2.23.44) RPMs from one of the mysql.com mirrors. I don't think it's a download issue because the problem originally occured with the 2.23.43 distribution. The crash occurs within seconds of starting mysqld-max so the server never really runs. I did read the Forcing recovery section of the manual and it suggests that I might have to reboot to clear some memory condition. I will give that a try. Thanks, Stephen Stephen, I resolved now with the mysql-max-3.23.44...tar.gz distribution. I still do not understand what mysqld is trying to do here. What distribution do you use, or did you compile yourself? 0x807b90f handle_segfault__Fi + 383 0x8253c7a pthread_sighandler + 106 0x80cf21a change_active_index__11ha_innobaseUi + 230 0x8078693 lock_external__FPP8st_tableUi + 107 0x807853d mysql_lock_tables__FP3THDPP8st_tableUi + 333 0x80b202b acl_init__Fb + 411 0x807c656 main + 2454 0x82639fb __libc_start_main + 99 0x8048111 _start + 33 I looked now what MySQL does when it calls lock_external at startup: it initializes MySQL system tables like 'host' and 'user'. I assume you have not converted MySQL system tables to InnoDB format? That is not allowed. They must be MyISAM type. Maybe the MySQL system tables are corrupt? Running inside gdb could reveal if it really crashes there. Please make a copy of MySQL tables in the mysql directory so that they are preserved and we can check if they are ok. Regards, Heikki Ummm...I think I did convert the system db tables to InnoDB. Now what? How do I convert them back to MyISAM? Thanks, Stephen if you have good copies of system tables in the MyISAM format - I think they do not even need to be from the current database - then you can just copy them to the mysql directory (.frm, .MYI, .MYD files). mysqld will then use them in startup. But please make first a backup of your current mysql directory, and look if you have host.MYI and host.MYD etc. files there. An InnoDB table only has the .frm file. So we see if you had really converted system tables to InnoDB. Regards, Heikki - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MySQL-Max database recovery crashed - Fixed!
Stephen, At 01:37 PM 11/2/01 -0800, you wrote: Stephen, At 12:38 PM 11/2/01 -0800, you wrote: Heikki, Removal of the log= option and even the log-bin statement did not help. I used the latest (2.23.44) RPMs from one of the mysql.com mirrors. I don't think it's a download issue because the problem originally occured with the 2.23.43 distribution. The crash occurs within seconds of starting mysqld-max so the server never really runs. I did read the Forcing recovery section of the manual and it suggests that I might have to reboot to clear some memory condition. I will give that a try. Thanks, Stephen Stephen, I resolved now with the mysql-max-3.23.44...tar.gz distribution. I still do not understand what mysqld is trying to do here. What distribution do you use, or did you compile yourself? 0x807b90f handle_segfault__Fi + 383 0x8253c7a pthread_sighandler + 106 0x80cf21a change_active_index__11ha_innobaseUi + 230 0x8078693 lock_external__FPP8st_tableUi + 107 0x807853d mysql_lock_tables__FP3THDPP8st_tableUi + 333 0x80b202b acl_init__Fb + 411 0x807c656 main + 2454 0x82639fb __libc_start_main + 99 0x8048111 _start + 33 I looked now what MySQL does when it calls lock_external at startup: it initializes MySQL system tables like 'host' and 'user'. I assume you have not converted MySQL system tables to InnoDB format? That is not allowed. They must be MyISAM type. Maybe the MySQL system tables are corrupt? Running inside gdb could reveal if it really crashes there. Please make a copy of MySQL tables in the mysql directory so that they are preserved and we can check if they are ok. Regards, Heikki Ummm...I think I did convert the system db tables to InnoDB. Now what? How do I convert them back to MyISAM? Thanks, Stephen if you have good copies of system tables in the MyISAM format - I think they do not even need to be from the current database - then you can just copy them to the mysql directory (.frm, .MYI, .MYD files). mysqld will then use them in startup. But please make first a backup of your current mysql directory, and look if you have host.MYI and host.MYD etc. files there. An InnoDB table only has the .frm file. So we see if you had really converted system tables to InnoDB. Regards, Heikki Hi Heikki, I backed up the existing mysql system directory (containing only .frm files) and copied the mysql system databases from another operational server to the dead one. Mysqld fired-up nicely upon restarting with skip-innodb in my.cnf. After changing a few permissions, I restarted the server with innodb and my databases reappeared! I'll have a closer look but they appear untainted by my screw-up. I will have to include a warning in the comments section of the MySQL documentation to NOT CONVERT MySQL SYSTEM TABLES FROM myISAM TO INNODB TYPE! Thanks for your generous help! Regards, Stephen - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MySQL-Max database recovery crashed
On Fri, Nov 02, 2001 at 11:17:37PM +0200, Heikki Tuuri wrote: I looked now what MySQL does when it calls lock_external at startup: it initializes MySQL system tables like 'host' and 'user'. I assume you have not converted MySQL system tables to InnoDB format? That is not allowed. They must be MyISAM type. I once converted ALL the databases and tables on a machine from MyISAM to Gemini. And I seem to remember it working. Hmm. Sounds like we need a big red warning in the docs about this. Maybe even something in the code to make it impossible. Jeremy -- Jeremy D. Zawodny, [EMAIL PROTECTED] Technical Yahoo - Yahoo Finance Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936 MySQL 3.23.41-max: up 58 days, processed 1,299,168,985 queries (258/sec. avg) - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: MySQL-Max database recovery crashed
Jeremy, At 11:37 PM 11/2/01 -0800, you wrote: On Fri, Nov 02, 2001 at 11:17:37PM +0200, Heikki Tuuri wrote: I looked now what MySQL does when it calls lock_external at startup: it initializes MySQL system tables like 'host' and 'user'. I assume you have not converted MySQL system tables to InnoDB format? That is not allowed. They must be MyISAM type. I once converted ALL the databases and tables on a machine from MyISAM to Gemini. And I seem to remember it working. in theory it could work. But since it has not been tested, in practice it probably will not. I do not what kind of a 'thd' handle mysqld uses when accessing its system tables, and I think it is best to leave the freedom to MySQL AB to change the access pattern as they like. Also, the system tables are managed in a non-transactional fashion, using table level locks. I do not know what happens if the tables are transactional and are managed with row level locking. Hmm. Sounds like we need a big red warning in the docs about this. Maybe even something in the code to make it impossible. Yes, I think I will ban table names 'mysql/host', 'mysql/user', 'mysql/db' internally inside InnoDB code. Jeremy -- Jeremy D. Zawodny, [EMAIL PROTECTED] Technical Yahoo - Yahoo Finance Desk: (408) 349-7878 Fax: (408) 349-5454 Cell: (408) 685-5936 MySQL 3.23.41-max: up 58 days, processed 1,299,168,985 queries (258/sec. avg) Regards, Heikki http://www.innodb.com/ibman.html - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: database recovery (errcode 13)?
Hi, The server where the db was located got hacked and I had to reinstall the whole thing. The old HD is preserved as was and the server got a new HD. I moved the old db to the new disk and when I try to access it, I get the following error: mysql use thedb; Can't read dir of './thedb/' (Errcode: 13) Database changed mysql show tables; ERROR 12: Can't read dir of './thedb/' (Errcode: 13) mysql Error code 13 stands for permission denied. make sure the whole MySQL data directory is owned by the same user you run the mysql daemon as. i'm not completely sure about the RPM install, but it should run it as user mysql - in that case, run chown -R mysql /mysql/data/dir as root. Rgds, Tfr --== [EMAIL PROTECTED] == MySQL development team == Tallinn / Estonia ==-- - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
database recovery (errcode 13)?
Hi list, I am dealing with my first MySQL server/db, and I ran into some trouble. The server where the db was located got hacked and I had to reinstall the whole thing. The old HD is preserved as was and the server got a new HD. I moved the old db to the new disk and when I try to access it, I get the following error: mysql use thedb; Can't read dir of './thedb/' (Errcode: 13) Database changed mysql show tables; ERROR 12: Can't read dir of './thedb/' (Errcode: 13) mysql (RedHat 6.2, MySQL 2.23.37) How can I recover or fix it? Thanks in advance for any help. K. Aleksic - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: database recovery (errcode 13)?
When you say you moved the data base I'm assumeing you are meaning you reinstalled MySQL then moved the db files over to the new install? Each data base goes into its own directory. So the database files for the database named thedb would be in a subdirectory called thedb of the directory data . I am talking from a windows environment maybe its different on Linux. root=mysql sub1=data sub2=thedb---database files for thedb go here -Original Message- From: Kay Aleksic [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 09, 2001 2:10 PM To: MySQL List (E-mail) Subject: database recovery (errcode 13)? Hi list, I am dealing with my first MySQL server/db, and I ran into some trouble. The server where the db was located got hacked and I had to reinstall the whole thing. The old HD is preserved as was and the server got a new HD. I moved the old db to the new disk and when I try to access it, I get the following error: mysql use thedb; Can't read dir of './thedb/' (Errcode: 13) Database changed mysql show tables; ERROR 12: Can't read dir of './thedb/' (Errcode: 13) mysql (RedHat 6.2, MySQL 2.23.37) How can I recover or fix it? Thanks in advance for any help. K. Aleksic - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: database recovery (errcode 13)?
errno 13 is 'permission denied'. It looks like your permissions aren't set correctly. -Jeff - Original Message - From: Kay Aleksic [EMAIL PROTECTED] To: MySQL List (E-mail) [EMAIL PROTECTED] Sent: Wednesday, May 09, 2001 3:10 PM Subject: database recovery (errcode 13)? Hi list, I am dealing with my first MySQL server/db, and I ran into some trouble. The server where the db was located got hacked and I had to reinstall the whole thing. The old HD is preserved as was and the server got a new HD. I moved the old db to the new disk and when I try to access it, I get the following error: mysql use thedb; Can't read dir of './thedb/' (Errcode: 13) Database changed mysql show tables; ERROR 12: Can't read dir of './thedb/' (Errcode: 13) mysql (RedHat 6.2, MySQL 2.23.37) How can I recover or fix it? Thanks in advance for any help. K. Aleksic - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: database recovery (errcode 13)?
Kay Aleksic [EMAIL PROTECTED] wrote: I am dealing with my first MySQL server/db, and I ran into some trouble. The server where the db was located got hacked and I had to reinstall the whole thing. The old HD is preserved as was and the server got a new HD. I moved the old db to the new disk and when I try to access it, I get the following error: mysql use thedb; Can't read dir of './thedb/' (Errcode: 13) Database changed mysql show tables; ERROR 12: Can't read dir of './thedb/' (Errcode: 13) mysql I have seen this error when the database (which exists as a directory on the filesystem) or tables (files within this directory) are not owned by the same user that MySQL runs under. It's also possible you would get the same error if that user doesn't have read permissions. -- Steve Werby President, Befriend Internet Services LLC http://www.befriend.com/ - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
