I have a 70GB database that I need to put on another box I'm building (Ubuntu 9.04 w/ext4, 1TB drive). I copy these files from the existing database (stopped it first of course) via USB HD. Doing a mysql dump/restore isn't really realistic as it gets exponentially slower and can take from 3-5 days to complete!
root:/var/lib/mysql# ll drwx------ 2 mysql mysql 12288 2009-05-08 06:57 agis_core -rw-rw---- 1 mysql mysql 70038585344 2009-06-17 04:09 ibdata1 -rw-rw---- 1 mysql mysql 5242880 2009-06-17 04:09 ib_logfile0 -rw-rw---- 1 mysql mysql 5242880 2009-06-17 03:22 ib_logfile1 drwxr-xr-x 2 mysql mysql 4096 2008-11-24 23:34 mysql The one main difference is that the original box is a master from a replication cluster with a single slave. The new box is a stand alone (and I want it to be that way, no replication as it's for a demonstration event). The other is that the original was on ext3 and this new one is ext4, but I fail to see that being an issue unless ext4 has some obscure bug with very large files? I also merged the /etc/mysql/my.cnf file (see way below for actual file). The only part I wasn't sure about is this, so I commented them all out on the new box, but I get the same results if I leave them in too: #server-id = 1 #log_bin = /var/log/mysql/mysql-bin.log #expire_logs_days = 10 #max_binlog_size = 100M #binlog_do_db = agis_core #innodb_flush_log_at_trx_commit = 1 #sync_binlog = 1 Whenever I try to start the mysql server, it fails and this is what syslog says: InnoDB: Log scan progressed past the checkpoint lsn 31 2660678588 090714 1:43:16 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 31 2660692731 090714 1:43:18 InnoDB: Error: page 7 log sequence number 31 2666928481 InnoDB: is in the future! Current system log sequence number 31 2660692731. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: for more information. 090714 1:43:18 InnoDB: Error: page 2 log sequence number 31 2666965968 InnoDB: is in the future! Current system log sequence number 31 2660692731. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: for more information. 090714 1:43:18 InnoDB: Error: page 4 log sequence number 31 2667028359 InnoDB: is in the future! Current system log sequence number 31 2660692731. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: for more information. 090714 1:43:18 InnoDB: Error: page 5 log sequence number 31 2667017090 InnoDB: is in the future! Current system log sequence number 31 2660692731. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: for more information. 090714 1:43:18 InnoDB: Error: page 6 log sequence number 31 2667017090 InnoDB: is in the future! Current system log sequence number 31 2660692731. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: for more information. 090714 1:43:18 InnoDB: Error: page 45 log sequence number 31 2667016488 InnoDB: is in the future! Current system log sequence number 31 2660692731. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: for more information. 090714 1:43:18 InnoDB: Error: page 1474592 log sequence number 31 2680162945 InnoDB: is in the future! Current system log sequence number 31 2660692731. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: for more information. InnoDB: Error: trying to access page number 2144600306 in space 0, InnoDB: space name ./ibdata1, InnoDB: which is outside the tablespace bounds. InnoDB: Byte offset 0, len 16384, i/o type 10. InnoDB: If you get this error at mysqld startup, please check that InnoDB: your my.cnf matches the ibdata files that you have in the InnoDB: MySQL server. 090714 1:43:18InnoDB: Assertion failure in thread 3083368144 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html InnoDB: about forcing recovery. 090714 1:43:18 - 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 against 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=0 read_buffer_size=131072 max_used_connections=0 max_connections=100 threads_connected=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 217599 Kbytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=(nil) 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=0xbf8cb3c8, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81f9a16 0x840ef93 0x83e89e1 0x83e98b7 0x83de78d 0x83d6560 0x83c8eff 0x83c9183 0x83cb18f 0x834ad2d 0x82c48f2 0x82b9d4f 0x81fab1d 0x81fce53 0xb7c9f775 0x8168381 New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/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 The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash. Both systems are UTC time so I don't get the issue with the sequence number is in the future business either. If I ever do get mysqld to start using the "innodb_force_recovery = 4" line, then as you know, I can't alter/update/insert. And it seems any attempt to do so further corrupts the database and I have to re-copy the 70GB files again. :-\ So what's the deal?? What am I missing here? I shouldn't need the /var/log/mysql/* files right? Those are only for replication I thought? Is there some command I am supposed to issue to maybe tell this database/table that it is not replicating and to be stand-alone? I've been at this for two days with no luck and out of ideas... root:/etc/mysql# cat my.cnf # # The MySQL database server configuration file. # # You can copy this to one of: # - "/etc/mysql/my.cnf" to set global options, # - "~/.my.cnf" to set user-specific options. # # One can use all long options that the program supports. # Run program with --help to get a list of available options and with # --print-defaults to see which it would actually understand and use. # # For explanations see # http://dev.mysql.com/doc/mysql/en/server-system-variables.html # This will be passed to all mysql clients # It has been reported that passwords should be enclosed with ticks/quotes # escpecially if they contain "#" chars... # Remember to edit /etc/mysql/debian.cnf when changing the socket location. [client] port = 3306 socket = /var/run/mysqld/mysqld.sock # Here is entries for some specific programs # The following values assume you have at least 32M ram # This was formally known as [safe_mysqld]. Both versions are currently parsed. [mysqld_safe] socket = /var/run/mysqld/mysqld.sock nice = 0 [mysqld] # http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html # innodb_force_recovery = 4 # # * Basic Settings # # # * IMPORTANT # If you make changes to these settings and your system uses apparmor, you may # also need to also adjust /etc/apparmor.d/usr.sbin.mysqld. # user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock port = 3306 basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language = /usr/share/mysql/english skip-external-locking # # Instead of skip-networking the default is now to listen only on # localhost which is more compatible and is not less secure. #bind-address = 127.0.0.1 # # * Fine Tuning # key_buffer = 16M # Added the 4 below parameters per Paul Danset on 2007-10-01 by BA. bulk_insert_buffer_size=128M max_heap_table_size=500M tmp_table_size=256M max_allowed_packet = 384M #max_allowed_packet=500000000 #max_allowed_packet = 16M # thread_stack = 128K thread_cache_size = 8 max_connections = 100 wait_timeout=3600 #table_cache = 64 #thread_concurrency = 10 # # * Query Cache Configuration # query_cache_limit = 1M query_cache_size = 64M #query_cache_size = 16M # # * Logging and Replication # # Both location gets rotated by the cronjob. # Be aware that this log type is a performance killer. #log = /var/log/mysql/mysql.log # # Error logging goes to syslog. This is a Debian improvement :) # # Here you can see queries with especially long duration log_slow_queries = /var/log/mysql/mysql-slow.log long_query_time = 30 #log_slow_queries = /var/log/mysql/mysql-slow.log #long_query_time = 2 #log-queries-not-using-indexes # # The following can be used as easy to replay backup logs or for replication. # note: if you are setting up a replication slave, see README.Debian about # other settings you may need to change. #server-id = 1 #log_bin = /var/log/mysql/mysql-bin.log #expire_logs_days = 10 #max_binlog_size = 100M #binlog_do_db = agis_core #binlog_do_db = include_database_name #binlog_ignore_db = include_database_name #innodb_flush_log_at_trx_commit=1 #sync_binlog=1 # # * BerkeleyDB # # Using BerkeleyDB is now discouraged as its support will cease in 5.1.12. skip-bdb # # * InnoDB # # InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/. # Read the manual for more InnoDB related options. There are many! # You might want to disable InnoDB to shrink the mysqld process by circa 100MB. #skip-innodb # # * Federated # # The FEDERATED storage engine is disabled since 5.0.67 by default in the .cnf files # shipped with MySQL distributions (my-huge.cnf, my-medium.cnf, and so forth). # skip-federated # # * Security Features # # Read the manual, too, if you want chroot! # chroot = /var/lib/mysql/ # # For generating SSL certificates I recommend the OpenSSL GUI "tinyca". # # ssl-ca=/etc/mysql/cacert.pem # ssl-cert=/etc/mysql/server-cert.pem # ssl-key=/etc/mysql/server-key.pem [mysqldump] quick quote-names max_allowed_packet = 384M #max_allowed_packet = 16M [mysql] #no-auto-rehash # faster start of mysql but no tab completition [isamchk] key_buffer = 16M # # * NDB Cluster # # See /usr/share/doc/mysql-server-*/README.Debian for more information. # # The following configuration is read by the NDB Data Nodes (ndbd processes) # not from the NDB Management Nodes (ndb_mgmd processes). # # [MYSQL_CLUSTER] # ndb-connectstring=127.0.0.1 # # * IMPORTANT: Additional settings that can override those from this file! # The files must end with '.cnf', otherwise they'll be ignored. # !includedir /etc/mysql/conf.d/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
