Hi All.
I use:
# rpm -qa | grep -i percona-server-server
Percona-Server-server-55-5.5.28-rel29.3.388.rhel6.x86_64
My system:
# uname -a;cat /etc/redhat-release
Linux prbc01.mg.local 2.6.32-279.19.1.el6.centos.plus.x86_64 #1 SMP
Wed Dec 19 06:20:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Red
2013/2/3 Larry Martell larry.mart...@gmail.com
We also ended up dropping the database and restoring from dumps.
However all recent dumps ended up having a similar corruption and we
were still getting the same errors. We had to go back to an October
dump before it would come up cleanly. And
for version 4.3.2
For more information, see http://www.upscene.com/go/?go=newsid=20130204
Database Workbench supports:
- Borland InterBase ( 6.x - XE )
- Firebird ( 1.x, 2.x )
- MS SQL Server/MSDE ( 7, 2000, 2005, 2008 )
- MySQL 4.x, 5.x
- Oracle Database ( 8i, 9i, 10g, 11g )
- Sybase SQL Anywhere ( 9
I definitely agree with using replication. As for delayed replication, this is
actually a built in feature of MySQL 5.6 (coming soon). 5.6 has numerous
improvements to replication. Definitely worth checking out:
http://dev.mysql.com/tech-resources/articles/whats-new-in-mysql-5.6.html
Scroll
Meta info about the tables is stored in ibdata1. Hence, it is not possible to
copy just the .ibd file to another database or machine. 5.6.x will remedy this
with some export/import commands that do not involve reading/writing the rows
individually. (Ditto for moving partitions.)
(Sorry, I
Do not try to dump or reload information_schema. It is derived meta
information, not real tables.
-Original Message-
From: Rafał Radecki [mailto:radecki.ra...@gmail.com]
Sent: Monday, February 04, 2013 12:17 AM
To: mysql@lists.mysql.com
Subject: Mysqldump routines dump, problem
