Copy 70GB ibdata, etc. and server won"t start now

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.ht ml

# 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=gcdmg-mysql-2@m.gmane.org

RE: Copy 70GB ibdata, etc. and server won"t start now

> 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.

First thing that comes to mind is a scenario that happened some time ago wh=
en we migrated data from one server to another in a similar way. Server on=
e had the innodb file set to 2gb each file (10 files total). New server wa=
s set for 1gb each. It doesn't shrink files so not much was thought about =
it at the time but our problem was the innodb table settings had to match t=
o the letter. We ended up copying the copy file from the old machine to th=
e new machine (they were running the same version so it really wasn't a pro=
blem.

I know that you stated you were running Ubuntu, which is great, but what ve=
rsion of the database did it come from and what version of the database is =
it going to? =20

Anyway, if the original server is still up, I'd just copy from one store to=
the other. It might be slow to do a 4 day export, but if you are two days=
into this the savings of USB copy has already been lost. =20

Gary

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

Re: Copy 70GB ibdata, etc. and server won"t start now

On 7/13/2009 9:19 PM, Daevid Vincent wrote:
> 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. :-\
>

I think level 4 is not the appropiate, maybe you can try level 3 or 5
which are more convenient to skip the log, then you can check if
everything works fine (aka review you tables integrity) if it is, then
restore the default value so the next restart would make the recovery if
neccesary.

Hope this helps.
Carlos




--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: Copy 70GB ibdata, etc. and server won"t start now

You should take a look at Percona's xtrabackup utility to do this. It
takes a clean snapshot of an innodb database that can be restored on a
target machine in a few minutes, though it does crash recovery at
backup time which can take a while.

Marcus

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

RE: Copy 70GB ibdata, etc. and server won"t start now

> -----Original Message-----
> From: Gary Smith [mailto:Gary@primeexalia.com]
> Sent: Monday, July 13, 2009 8:54 PM
> To: Daevid Vincent; mysql@lists.mysql.com
> Subject: RE: Copy 70GB ibdata, etc. and server won't start now
>
> > 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.
>
> First thing that comes to mind is a scenario that happened
> some time ago when we migrated data from one server to
> another in a similar way. Server one had the innodb file set
> to 2gb each file (10 files total). New server was set for
> 1gb each. It doesn't shrink files so not much was thought
> about it at the time but our problem was the innodb table
> settings had to match to the letter. We ended up copying the
> copy file from the old machine to the new machine (they were
> running the same version so it really wasn't a problem.

The logfiles are the same size so I assume that's configured right?

> I know that you stated you were running Ubuntu, which is
> great, but what version of the database did it come from and
> what version of the database is it going to?

+------+
| Old: |
+------+
mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline
5.2

drwx------ 2 mysql mysql 12288 2009-06-26 21:33 agis_core
-rw-r--r-- 1 mysql mysql 0 2008-11-24 23:34 debian-5.0.flag
-rw-rw---- 1 mysql mysql 72387395584 2009-07-14 19:18 ibdata1
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 19:18 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 18:30 ib_logfile1
drwxr-xr-x 2 mysql mysql 4096 2008-11-24 23:34 mysql


+------+
| New: |
+------+
mysql Ver 14.12 Distrib 5.0.75, for debian-linux-gnu (i486) using readline
5.2

drwx------ 2 mysql mysql 12288 2009-07-14 00:36 agis_core
-rw-r--r-- 1 mysql mysql 0 2008-11-24 23:34 debian-5.0.flag
-rw-rw---- 1 mysql mysql 70038585344 2009-06-17 04:09 ibdata1
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 01:43 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2009-06-17 03:22 ib_logfile1
drwxr-xr-x 2 mysql mysql 4096 2009-07-14 00:36 mysql


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: Copy 70GB ibdata, etc. and server won"t start now

--000e0cd2475210e47a046eb07400
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Why do the dates on the log files differ by almost a month between Old and
New?

On Tue, Jul 14, 2009 at 2:23 PM, Daevid Vincent wrote:

>
>
> > -----Original Message-----
> > From: Gary Smith [mailto:Gary@primeexalia.com]
> > Sent: Monday, July 13, 2009 8:54 PM
> > To: Daevid Vincent; mysql@lists.mysql.com
> > Subject: RE: Copy 70GB ibdata, etc. and server won't start now
> >
> > > 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.
> >
> > First thing that comes to mind is a scenario that happened
> > some time ago when we migrated data from one server to
> > another in a similar way. Server one had the innodb file set
> > to 2gb each file (10 files total). New server was set for
> > 1gb each. It doesn't shrink files so not much was thought
> > about it at the time but our problem was the innodb table
> > settings had to match to the letter. We ended up copying the
> > copy file from the old machine to the new machine (they were
> > running the same version so it really wasn't a problem.
>
> The logfiles are the same size so I assume that's configured right?
>
> > I know that you stated you were running Ubuntu, which is
> > great, but what version of the database did it come from and
> > what version of the database is it going to?
>
> +------+
> | Old: |
> +------+
> mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using
> readline
> 5.2
>
> drwx------ 2 mysql mysql 12288 2009-06-26 21:33 agis_core
> -rw-r--r-- 1 mysql mysql 0 2008-11-24 23:34 debian-5.0.flag
> -rw-rw---- 1 mysql mysql 72387395584 2009-07-14 19:18 ibdata1
> -rw-rw---- 1 mysql mysql 5242880 2009-07-14 19:18 ib_logfile0
> -rw-rw---- 1 mysql mysql 5242880 2009-07-14 18:30 ib_logfile1
> drwxr-xr-x 2 mysql mysql 4096 2008-11-24 23:34 mysql
>
>
> +------+
> | New: |
> +------+
> mysql Ver 14.12 Distrib 5.0.75, for debian-linux-gnu (i486) using readline
> 5.2
>
> drwx------ 2 mysql mysql 12288 2009-07-14 00:36 agis_core
> -rw-r--r-- 1 mysql mysql 0 2008-11-24 23:34 debian-5.0.flag
> -rw-rw---- 1 mysql mysql 70038585344 2009-06-17 04:09 ibdata1
> -rw-rw---- 1 mysql mysql 5242880 2009-07-14 01:43 ib_logfile0
> -rw-rw---- 1 mysql mysql 5242880 2009-06-17 03:22 ib_logfile1
> drwxr-xr-x 2 mysql mysql 4096 2009-07-14 00:36 mysql
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/mysql?unsub=johnny@pixelated.net
>
>


--
-----------------------------
Johnny Withers
601.209.4985
johnny@pixelated.net

--000e0cd2475210e47a046eb07400--

RE: Copy 70GB ibdata, etc. and server won"t start now

------=_NextPart_000_0053_01CA048B.1ED21490
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit




_____

From: Johnny Withers [mailto:johnny@pixelated.net]
Sent: Tuesday, July 14, 2009 1:41 PM
To: Daevid Vincent
Cc: mysql@lists.mysql.com; Gary Smith
Subject: Re: Copy 70GB ibdata, etc. and server won't start now


Why do the dates on the log files differ by almost a month between Old and
New?

Because the 70GB snapshot was copied a month ago when we swapped out some
hardware and drives and such. So the data on my "new" box will be a month
old, but that's fine. It's for a live demo and doesn't need to be current --
just have stuff to play with.

And everytime you muck with the database, it updates the stamp, so these
dates are misleading.

+------+
| Old: |
+------+
mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readline
5.2

drwx------ 2 mysql mysql 12288 2009-06-26 21:33 agis_core
-rw-r--r-- 1 mysql mysql 0 2008-11-24 23:34 debian-5.0.flag
-rw-rw---- 1 mysql mysql 72387395584 2009-07-14 19:18 ibdata1
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 19:18 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 18:30 ib_logfile1


drwxr-xr-x 2 mysql mysql 4096 2008-11-24 23:34 mysql



+------+
| New: |
+------+
mysql Ver 14.12 Distrib 5.0.75, for debian-linux-gnu (i486) using readline
5.2

drwx------ 2 mysql mysql 12288 2009-07-14 00:36 agis_core
-rw-r--r-- 1 mysql mysql 0 2008-11-24 23:34 debian-5.0.flag

-rw-rw---- 1 mysql mysql 70038585344 2009-06-17 04:09 ibdata1

-rw-rw---- 1 mysql mysql 5242880 2009-07-14 01:43 ib_logfile0

-rw-rw---- 1 mysql mysql 5242880 2009-06-17 03:22 ib_logfile1

drwxr-xr-x 2 mysql mysql 4096 2009-07-14 00:36 mysql


------=_NextPart_000_0053_01CA048B.1ED21490--

RE: Copy 70GB ibdata, etc. and server won"t start now

Daevid,=20

--The logfiles are the same size so I assume that's configured right?=20

They should be. If you copied the file over, mysql isn't going to increase=
/decrease the size of the file (because it already exists). I suspect that=
you didn't save the old my.cnf file.

The only other question I have is why is the "New" file smaller than the or=
iginal. innodb doesn't shrink files to the best of my knowledge (or at leas=
t, it hasn't for me) -- or did you mean that the top one is the new, and th=
e bottom one is the old..

So, looking a little harder at your files, I bet you tried to start myself =
against the USB device directly, on the first try, it failed, so you copied=
the data over to the local disk and you have been trying to recover it sin=
ce. I say that because the time stamp on the usb (new or old ones) but hav=
e July 14th as the dates...

I think as others have mentioned, the startup recovery flags might be your =
best bet. =20



________________________________________
From: Daevid Vincent [daevid@daevid.com]
Sent: Tuesday, July 14, 2009 12:23 PM
To: mysql@lists.mysql.com
Cc: Gary Smith
Subject: RE: Copy 70GB ibdata, etc. and server won't start now

> -----Original Message-----
> From: Gary Smith [mailto:Gary@primeexalia.com]
> Sent: Monday, July 13, 2009 8:54 PM
> To: Daevid Vincent; mysql@lists.mysql.com
> Subject: RE: Copy 70GB ibdata, etc. and server won't start now
>
> > 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.
>
> First thing that comes to mind is a scenario that happened
> some time ago when we migrated data from one server to
> another in a similar way. Server one had the innodb file set
> to 2gb each file (10 files total). New server was set for
> 1gb each. It doesn't shrink files so not much was thought
> about it at the time but our problem was the innodb table
> settings had to match to the letter. We ended up copying the
> copy file from the old machine to the new machine (they were
> running the same version so it really wasn't a problem.

The logfiles are the same size so I assume that's configured right?

> I know that you stated you were running Ubuntu, which is
> great, but what version of the database did it come from and
> what version of the database is it going to?

+------+
| Old: |
+------+
mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readlin=
e
5.2

drwx------ 2 mysql mysql 12288 2009-06-26 21:33 agis_core
-rw-r--r-- 1 mysql mysql 0 2008-11-24 23:34 debian-5.0.flag
-rw-rw---- 1 mysql mysql 72387395584 2009-07-14 19:18 ibdata1
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 19:18 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 18:30 ib_logfile1
drwxr-xr-x 2 mysql mysql 4096 2008-11-24 23:34 mysql


+------+
| New: |
+------+
mysql Ver 14.12 Distrib 5.0.75, for debian-linux-gnu (i486) using readline
5.2

drwx------ 2 mysql mysql 12288 2009-07-14 00:36 agis_core
-rw-r--r-- 1 mysql mysql 0 2008-11-24 23:34 debian-5.0.flag
-rw-rw---- 1 mysql mysql 70038585344 2009-06-17 04:09 ibdata1
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 01:43 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2009-06-17 03:22 ib_logfile1
drwxr-xr-x 2 mysql mysql 4096 2009-07-14 00:36 mysql=

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg

RE: Copy 70GB ibdata, etc. and server won"t start now

--_000_5017258D295FBE41917880488689F7B80FABD948C4VCSSBSvisio na_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Johnny,

I'm less worried about the month in between than the fact that all of the d=
ates for the files on his USB data should be roughly the same. It looks to=
me like he tried to start it against the data on the USB drive. Another q=
uestion is, was this an cold backup or hot backup? If this were a hot back=
up, I could see this problem happening. If it were a could backup, it shou=
ld work.


________________________________
From: Johnny Withers [johnny@pixelated.net]
Sent: Tuesday, July 14, 2009 1:40 PM
To: Daevid Vincent
Cc: mysql@lists.mysql.com; Gary Smith
Subject: Re: Copy 70GB ibdata, etc. and server won't start now

Why do the dates on the log files differ by almost a month between Old and =
New?

On Tue, Jul 14, 2009 at 2:23 PM, Daevid Vincent aevid@daevid.com>> wrote:


> -----Original Message-----
> From: Gary Smith [mailto:Gary@primeexalia.com >]
> Sent: Monday, July 13, 2009 8:54 PM
> To: Daevid Vincent; mysql@lists.mysql.com
> Subject: RE: Copy 70GB ibdata, etc. and server won't start now
>
> > 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 gs.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.
>
> First thing that comes to mind is a scenario that happened
> some time ago when we migrated data from one server to
> another in a similar way. Server one had the innodb file set
> to 2gb each file (10 files total). New server was set for
> 1gb each. It doesn't shrink files so not much was thought
> about it at the time but our problem was the innodb table
> settings had to match to the letter. We ended up copying the
> copy file from the old machine to the new machine (they were
> running the same version so it really wasn't a problem.

The logfiles are the same size so I assume that's configured right?

> I know that you stated you were running Ubuntu, which is
> great, but what version of the database did it come from and
> what version of the database is it going to?

+------+
| Old: |
+------+
mysql Ver 14.12 Distrib 5.0.51a, for debian-linux-gnu (i486) using readlin=
e
5.2

drwx------ 2 mysql mysql 12288 2009-06-26 21:33 agis_core
-rw-r--r-- 1 mysql mysql 0 2008-11-24 23:34 debian-5.0.flag
-rw-rw---- 1 mysql mysql 72387395584 2009-07-14 19:18 ibdata1
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 19:18 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 18:30 ib_logfile1
drwxr-xr-x 2 mysql mysql 4096 2008-11-24 23:34 mysql


+------+
| New: |
+------+
mysql Ver 14.12 Distrib 5.0.75, for debian-linux-gnu (i486) using readline
5.2

drwx------ 2 mysql mysql 12288 2009-07-14 00:36 agis_core
-rw-r--r-- 1 mysql mysql 0 2008-11-24 23:34 debian-5.0.flag
-rw-rw---- 1 mysql mysql 70038585344 2009-06-17 04:09 ibdata1
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 01:43 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2009-06-17 03:22 ib_logfile1
drwxr-xr-x 2 mysql mysql 4096 2009-07-14 00:36 mysql


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Djohnny@pixelated.ne=
t




--
-----------------------------
Johnny Withers
601.209.4985
johnny@pixelated.net

--_000_5017258D295FBE41917880488689F7B80FABD948C4VCSSBSvisio na_--

RE: Copy 70GB ibdata, etc. and server won"t start now

Not sure what you mean "start it against the USB drive". I copied from 'old'
-> USB -> 'new' /var/lib/mysql/*. At no time did I run the database pointing
at the USB drive (is that even possible? I guess a symlink or something
maybe with mods to app armor). The 'old' is growing and changing dates
because it is still live and actually in production. This 'new' box is going
to be used for a demo at a conference and is therefore a copy from about a
month ago and will not grow in size, but the dates will change as I muck
with the data on it.


________________________________

From: Gary Smith [mailto:Gary@primeexalia.com]
Sent: Tuesday, July 14, 2009 2:11 PM
To: Johnny Withers; Daevid Vincent
Cc: mysql@lists.mysql.com
Subject: RE: Copy 70GB ibdata, etc. and server won't start now


Johnny,

I'm less worried about the month in between than the fact that all
of the dates for the files on his USB data should be roughly the same. It
looks to me like he tried to start it against the data on the USB drive.
Another question is, was this an cold backup or hot backup? If this were a
hot backup, I could see this problem happening. If it were a could backup,
it should work.




--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: Copy 70GB ibdata, etc. and server won"t start now

Another thing you can do is simply erase the innodb logs. If the dbms
really was shutdown properly then the logs are useful,
they will be recreated again and you can go forward with your demo.

Carlos

On 7/14/2009 6:23 PM, Daevid Vincent wrote:
> Not sure what you mean "start it against the USB drive". I copied from 'old'
> -> USB -> 'new' /var/lib/mysql/*. At no time did I run the database pointing
> at the USB drive (is that even possible? I guess a symlink or something
> maybe with mods to app armor). The 'old' is growing and changing dates
> because it is still live and actually in production. This 'new' box is going
> to be used for a demo at a conference and is therefore a copy from about a
> month ago and will not grow in size, but the dates will change as I muck
> with the data on it.
>
>
> ________________________________
>
> From: Gary Smith [mailto:Gary@primeexalia.com]
> Sent: Tuesday, July 14, 2009 2:11 PM
> To: Johnny Withers; Daevid Vincent
> Cc: mysql@lists.mysql.com
> Subject: RE: Copy 70GB ibdata, etc. and server won't start now
>
>
> Johnny,
>
> I'm less worried about the month in between than the fact that all
> of the dates for the files on his USB data should be roughly the same. It
> looks to me like he tried to start it against the data on the USB drive.
> Another question is, was this an cold backup or hot backup? If this were a
> hot backup, I could see this problem happening. If it were a could backup,
> it should work.
>
>
>
>
>


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: Copy 70GB ibdata, etc. and server won"t start now

Uppps i mean...useless instead of useful.


On 7/14/2009 7:11 PM, Carlos Proal wrote:
>
> Another thing you can do is simply erase the innodb logs. If the dbms
> really was shutdown properly then the logs are useful,
> they will be recreated again and you can go forward with your demo.
>
> Carlos
>
> On 7/14/2009 6:23 PM, Daevid Vincent wrote:
>> Not sure what you mean "start it against the USB drive". I copied
>> from 'old'
>> -> USB -> 'new' /var/lib/mysql/*. At no time did I run the database
>> pointing
>> at the USB drive (is that even possible? I guess a symlink or something
>> maybe with mods to app armor). The 'old' is growing and changing dates
>> because it is still live and actually in production. This 'new' box
>> is going
>> to be used for a demo at a conference and is therefore a copy from
>> about a
>> month ago and will not grow in size, but the dates will change as I muck
>> with the data on it.
>>
>> ________________________________
>>
>> From: Gary Smith [mailto:Gary@primeexalia.com] Sent: Tuesday,
>> July 14, 2009 2:11 PM
>> To: Johnny Withers; Daevid Vincent
>> Cc: mysql@lists.mysql.com
>> Subject: RE: Copy 70GB ibdata, etc. and server won't start now
>>
>>
>> Johnny, I'm less worried about the month in between than
>> the fact that all
>> of the dates for the files on his USB data should be roughly the
>> same. It
>> looks to me like he tried to start it against the data on the USB drive.
>> Another question is, was this an cold backup or hot backup? If this
>> were a
>> hot backup, I could see this problem happening. If it were a could
>> backup,
>> it should work.
>>
>>
>>
>
>


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

RE: Copy 70GB ibdata, etc. and server won"t start now

> -----Original Message-----
> From: Carlos Proal [mailto:carlos.proal@gmail.com]
> Sent: Tuesday, July 14, 2009 5:13 PM
> >
> > Another thing you can do is simply erase the innodb logs.
> If the dbms
> > really was shutdown properly then the logs are useful,
> > they will be recreated again and you can go forward with your demo.

You're suggesting I can delete these two files?

-rw-rw---- 1 mysql mysql 5242880 2009-07-14 19:18 ib_logfile0
-rw-rw---- 1 mysql mysql 5242880 2009-07-14 18:30 ib_logfile1



--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: Copy 70GB ibdata, etc. and server won"t start now

Yep, you dont need to recover the database because:
1) You did a clean shutdown
2) You dont need (as i believe) an integral copy of your database,
because its for a demo, anyway the data is 1 month older, so if you miss
some records
that "probably" will be missing on the log those are not relevant for
your purpose, right ?

Carlos


On 7/14/2009 9:08 PM, Daevid Vincent wrote:
>> -----Original Message-----
>> From: Carlos Proal [mailto:carlos.proal@gmail.com]
>> Sent: Tuesday, July 14, 2009 5:13 PM
>>
>>> Another thing you can do is simply erase the innodb logs.
>>>
>> If the dbms
>>
>>> really was shutdown properly then the logs are useful,
>>> they will be recreated again and you can go forward with your demo.
>>>
>
> You're suggesting I can delete these two files?
>
> -rw-rw---- 1 mysql mysql 5242880 2009-07-14 19:18 ib_logfile0
> -rw-rw---- 1 mysql mysql 5242880 2009-07-14 18:30 ib_logfile1
>
>
>
>


--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: Copy 70GB ibdata, etc. and server won"t start now

On Tue, Jul 14, 2009 at 2:14 AM, Marcus
Bointon wrote:
> You should take a look at Percona's xtrabackup utility to do this. It takes
> a clean snapshot of an innodb database that can be restored on a target
> machine in a few minutes, though it does crash recovery at backup time which
> can take a while.

Most likely the op only tried to copy the ibdata file(s) and not the
iblog files.

A big honking waving hand over here saying YES, use xtrabackup. It
will be a pretty quick recovery process since the db was shut down
cleanly. Note that it will restore ALL tables' data, not just the
ibdata and iblog files. Just make sure that your innodb settings in
my.cnf match.


--
Regards... Todd

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=gcdmg-mysql-2@m.gmane.org

Re: Re: Copy 70GB ibdata, etc. and server won"t start now (Action

If a mailbox is protected by one of these types of services:
1) It should be smart enough to see mailing lists and use that as a
qualifying address to be allowed through.
2) It should be smart enough to not reply to bulk precedence mail
3) Or the mailbox should never be subscribed to a mailing list.

I'm firmly against these types of services, but then again I've never
seen one that met the criteria of #1 and #2. Are there any
intelligent services out there? #3 will cause people to cry about not
being fair and "I'm just trying to prevent spam." My answer is no,
not being fair is someone expecting me to do their work for them just
so they can receive emails from a public list that they joined.

Regards... Todd

On Wed, Jul 15, 2009 at 10:20 AM, wrote:
> Hello Todd Lyons,
>
> I use Boxbe to protect my email address. While I did receive your email
> about "Re: Copy 70GB ibdata, etc. and server won't start now", you are no=
t
> currently on my email Guest List. I'll be more likely to see your email a=
nd
> future messages if you are on my priority Guest List.
>
> Click here to be put directly on my Guest List
>
> Thank you,
> gurunathauti@gmail.com
>
> About this Notice
> This courtesy notice is part of a free service to make email more reliabl=
e
> and useful. Boxbe (www.boxbe.com) uses your existing social network and t=
hat
> of your friends to keep your inbox clean and make sure you receive email
> from people who matter to you.
>
> Say Goodbye to Email Overload
> www.boxbe.com
>
> Final-Recipient: rfc822; gurunathauti@gmail.com
> Diagnostic-Code: X-Boxbe-Notice; Sender not pre-approved, delivery likely
> delayed. =A0Follow instructions in above notice
> Status: 4.7.0
>
>
>
> ---------- Forwarded message ----------
> From:=A0Todd Lyons
> To:
> Date:=A0Wed, 15 Jul 2009 05:28:46 -0700
> Subject:=A0Re: Copy 70GB ibdata, etc. and server won't start now
>
>



--=20
Regards... Todd

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=3Dgcdmg-mysql-2@m.gmane.o rg