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
hi all,
i use mysqldump to backup my database,
the command line is; mysqldump -p -u -h database_name database_name.sql
i find in the database_name.sql, there is a line:
Not dumping tablespaces as no INFORMATION_SCHEMA.FILES table on this server
can anyone tell me what does it mean?
thanks
0.9.5.3 für PHP 5.2.8 (but not activated in the php.ini)
Anyone have an idea to where I should start to look?
Thanks
Gary
__ Information from ESET Smart Security, version of virus
signature database 4241 (20090714) __
The message was checked by ESET Smart Security.
http
In our database we have an Organizations table and a Contacts table,
and a linking table that associates Contacts with Organizations.
Occassionally we manually add to the linking table with information
gleaned from outside data sources. This is common enough to be
annoying, since it ends up with
Matt,
If you went with option #3, you could avoid the looping by using (tCount - 1)
as the LIMIT in the delete statement instead of always using 1.
Regards,
Nathan
-Original Message-
From: Matt Neimeyer [mailto:m...@neimeyer.org]
Sent: Tuesday, July 14, 2009 8:58 AM
To:
Artie,
Please tell us your MySQL version, support your error log.Thanks.
在 2009-7-14，上午8:20， Artie Ziff 写道：
I am returning to mysql after long break, so not experienced with
details. I inherited a text file with the mysql DDL statements which
create database and tables, etc. Each 'create'
You can combine the two queries you have in option 3 (you'll need to
change field names, but you should get the idea), something like this:
DELETE table1 FROM table1, (SELECT MAX(id) AS dupid, COUNT(id) AS
dupcnt FROM table1 WHERE field1 IS NOT NULL GROUP BY link_id HAVING
dupcnt1) AS dups
I hope you mean that the SHOW WARNINGS statements follow the DDL statements.
If the DROP statements have the IF EXISTS modifier, then there should not be
any warnings shown in the output. If there are, something (less severe than
an outright error) is wrong with the CREATE statement. It might be
That's assuming that there is a unique identifier field, like an auto
increment field. Although that could be added after the fact. Also,
you need to run the query multiple times until it returns no affected
records. So if there are 4 copies of a record, it would need to be run
3 times to get rid
I am using mysql Server version: 5.1.31 MySQL Community Server (GPL) on a
MAC 10.5 host. I am having some strange date translation issues when I
insert dates into my tables.
What I do is run perl¹s Spreadsheet::ParseExcel module with Time::JulianDay
to reformat excel dates to insert properly into
-Original Message-
From: Gary Smith [mailto:g...@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
Ah... Yes. Good point. I like this because I was planning on keeping
the output somewhere for a while. (In case we need an accounting at
some point) So it will be easy enough to dump what's being deleted to
the screen while we loop over our candidates.
Thanks!
On Tue, Jul 14, 2009 at 10:16 AM,
mysql desc maintenance;
++--+--+-++---+
| Field | Type | Null | Key | Default| Extra |
++--+--+-++---+
| indate | date | YES | | NULL
Hagan,
Close but not quite what I asked for. The schema for your table is
what you get from SHOW CREATE TABLE `mytable`. It will show all the
indexes and, most imporatantly, make it trivial for someone trying to
assist you in your investigation to re-create your problem.
It is good to see the
Micheal,
Your query trouble shooting tip showed me my error - see below:
Sorry here is the SHOW CREATE TABLE:
mysql show create table `maintenance`;
+-+-
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 dae...@daevid.com wrote:
-Original Message-
From: Gary Smith [mailto:g...@primeexalia.com]
Sent: Monday, July 13, 2009 8:54 PM
To: Daevid Vincent;
Daevid,
--The logfiles are the same size so I assume that's configured right?
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
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
_
From: Johnny Withers [mailto:joh...@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
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
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
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
-Original Message-
From: Carlos Proal [mailto:carlos.pr...@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
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
Does anyone has any suggestions on how to get IO stats used by per process
(mysqld) on Linux 2.6.18-53 kernel ... I just need to see how much reads and
writes mysql is actually doing and what else is causing the IO load..
iopp
but that need 2.6.20 kernel support
On Wed, Jul 15, 2009 at 12:32 PM, dbrb2002-...@yahoo.com wrote:
Does anyone has any suggestions on how to get IO stats used by per process
(mysqld) on Linux 2.6.18-53 kernel ... I just need to see how much reads and
writes mysql is actually doing and
26 matches
Mail list logo
