MySQL Backup - Problem beim zurückspielen
MySQL Backup - Problem beim zurückspielen
am 31.10.2006 16:26:17 von Andreas Weller
Hallo!
Ich habe einen MySQL Server unter Win 2000 laufen. Jetzt möchte ich
gerne die Sache unter VMWare betreiben. Ich lasse MySQL unter Gentoo
Linux in der VMWare laufen - es gibt dazu eine fertige VM von
VirtualAppliances, die auch ohne Probleme in der VMWare bootet und auch
von außen ansprechbar ist.
Jetzt habe ich von der Datenbank mit Hilfe des MySQL Administrator unter
Win 2000 und der Backup Funktion gesichert. Aber das Problem ist das
zurückspielen:
Wenn ich im MySQL Administrator die IP der Linux VM eingebe kann ich
mich connecten und bekommen auch alle Daten angezeigt. Versuche ich
allerdings das Backup (etwa 120 MB) zurückzusichern bekomme ich nach
einer Weile die Fehlermeldung 1114 - table full...
Woran liegt das bzw. wie kann man das Problem beheben/umgehen?
Vielen Dank!
Gruß,
Andreas Weller
Re: MySQL Backup - Problem beim zurückspielen
am 31.10.2006 16:49:10 von Andreas Kretschmer
Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)
Re: MySQL Backup - Problem beim zurückspielen
am 31.10.2006 17:23:12 von Andreas Weller
Andreas Kretschmer schrieb:
> > Woran liegt das bzw. wie kann man das Problem beheben/umgehen?
>
> vermutlich http://bugs.mysql.com/bug.php?id=3D230
Hallo und Danke!
Laut der URL sollte der Fehler bereits behoben sein:
> [4 Apr 2003 10:57] Sinisa Milivojevic
>
> Yes, this is a known problem.
> It is already fixed in 4.0.13, which will come out this month.
Evtl. sollte ich das Backup mit anderen Optionen generieren???
Gruß,
Andreas Weller
Re: MySQL Backup - Problem beim zurückspielen
am 31.10.2006 17:31:17 von Andreas Kretschmer
Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)
Re: =?iso-8859-1?q?Re:_MySQL_Backup_-_Problem_beim_zurückspielen?
am 31.10.2006 17:42:34 von Axel Schwenke
"Andreas Weller, DF1PAW" wrote:
> Andreas Kretschmer schrieb:
>>
>> vermutlich http://bugs.mysql.com/bug.php?id=230
LOL. Andreas hat schon schlechtere Tips gegeben.
Aber keine viel schlechteren.
> Hallo und Danke!
> Laut der URL sollte der Fehler bereits behoben sein:
>> [4 Apr 2003 10:57] Sinisa Milivojevic
>>
>> Yes, this is a known problem.
>> It is already fixed in 4.0.13, which will come out this month.
Eben. Wenn in deiner VM nicht ein dreieinhalb Jahre altes MySQL
werkelt, sollte dich das nicht betreffen.
> Evtl. sollte ich das Backup mit anderen Optionen generieren???
Du solltest mal Butter bei die Fische tun.
Welche Version von MySQL ist das? Welche Version vom Administrator?
Was ist die *genaue* Fehlermeldung? Mit welchen Optionen hast du das
Backup erzeugt und mit welchen wieder zurückgespielt?
Kann es eines der Probleme sein, die hier erwähnt werden?
http://dev.mysql.com/doc/refman/5.0/en/full-table.html
Wenn das in einer VM läuft, kann ja z.B. die virtuelle Festplatte
voll sein.
XL
Re: MySQL Backup - Problem beim zurückspielen
am 31.10.2006 20:02:07 von Andreas Kretschmer
Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)
Re: MySQL Backup - Problem beim zurückspielen
am 31.10.2006 20:35:15 von Kris
Andreas Weller wrote:
> Wenn ich im MySQL Administrator die IP der Linux VM eingebe kann ich
> mich connecten und bekommen auch alle Daten angezeigt. Versuche ich
> allerdings das Backup (etwa 120 MB) zurückzusichern bekomme ich nach
> einer Weile die Fehlermeldung 1114 - table full...
> Woran liegt das bzw. wie kann man das Problem beheben/umgehen?
Die Fehlermeldung "table full" tritt unter anderem dann auf, wenn die Anzahl
der Zeilen in einer Tabelle im Format MyISAM fixed gröÃer wird als durch
den Row Pointer für diese Tabelle darstellbar. Sie tritt auch auf, wenn die
Anzahl der Bytes in einer Tabelle im Format MyISAM dynamic gröÃer wird als
durch den Row Pointer für diese Tabelle darstellbar.
In MySQL 5.0 ist der Row Pointer für MyISAM per Default 6 Byte groÃ, sodaÃ
Tabellen bis zu 256 Tera-Rows bzw 256 Terabyte enthalten können. In
früheren Versionen ist der Row Pointer 4 Byte groÃ, sodaà das Limit
entsprechend bei 4 Gigarows/byte liegt.
Durch Angaben von MAX_ROWS und AVG_ROW_SIZE als Parameter bei CREATE TABLE
oder ALTER TABLE kann MySQL gezwungen werden, einen anderen (kleineren,
gröÃeren) Row Pointer zu wählen.
In der [mysqld]-Sektion der my.cnf kann durch myisam_data_pointer_size = 6
(oder andere Werte) der Default umgestellt werden.
http://dev.mysql.com/doc/refman/5.0/en/full-table.html nennt weitere Gründe
für die Fehlermeldung.
Kris
Re: MySQL Backup - Problem beim zurückspielen?
am 31.10.2006 21:57:28 von Andreas Weller
Hallo!
Axel Schwenke schrieb:
> Du solltest mal Butter bei die Fische tun.
Gerne - ich sitze im Moment am Gerät mit dem das Backup erzeugt wurde.
Daten zur Linux VM liefere ich Morgen im Thread nach.
> Welche Version von MySQL ist das? Welche Version vom Administrator?
> Was ist die *genaue* Fehlermeldung? Mit welchen Optionen hast du das
> Backup erzeugt und mit welchen wieder zurückgespielt?
Erzeugt wurde das Backup mit MySQL 4.1.15-NT und dem SQL Administrator
10.20
Method: InnoDB Online Backup
Type: SQL File
Mit folgenden Optionen:
- Add DROP statements
- complete INSERTS
- comment
- disable keys
Es handelt sich um insgesamt 85 tables mit:
- 2217576 Rows
- 204,6 MB Data length
- 119,2 MB Index length
> Wenn das in einer VM läuft, kann ja z.B. die virtuelle Festplatte
> voll sein.
Ausgeschlossen: Die VM ist mit 2 GB angelegt und es sind grad mal 400
MB belegt.
Macht es evtl. Sinn ohne DROP statements zu sichern? Ich habe irgendwo
im Netz den Hinweis gefunden, daß es dabei zu (nicht näher genannten)
Backup-Problemen kommen kann. Wäre die Datenbank nach dem
zurücksichern ad hoc funktionsfähig?
Gruß,
Andreas Weller
Re: MySQL Backup - Problem beim zurückspielen?
am 01.11.2006 13:05:19 von Andreas Weller
Andreas Weller, DF1PAW schrieb:
> Erzeugt wurde das Backup mit MySQL 4.1.15-NT und dem SQL Administrator
> 1.0.20
> Method: InnoDB Online Backup
> Type: SQL File
> Mit folgenden Optionen:
> - Add DROP statements
> - complete INSERTS
> - comment
> - disable keys
Hallo!
Das Backup soll auf folgender VM Konfiguration zurückgespielt werden:
MySQL Version MySQL 4.1.20-log
Und als Frontend: 1.2.4 rc MySQL Administrator
Gruß,
Andreas
mysql.conf für die VM:
> # /etc/mysql/my.cnf: The global mysql configuration file.
> #
> # Customized for Virtual Appliances
>
> # The following options will be passed to all MySQL clients
> [client]
> #password = your_password
> port = 3306
> socket = /var/run/mysqld/mysqld.sock
>
> [mysql]
> character-sets-dir=/usr/share/mysql/charsets
> default-character-set=utf8
>
> [mysqladmin]
> character-sets-dir=/usr/share/mysql/charsets
> default-character-set=utf8
>
> [mysqlcheck]
> character-sets-dir=/usr/share/mysql/charsets
> default-character-set=utf8
>
> [mysqldump]
> character-sets-dir=/usr/share/mysql/charsets
> default-character-set=utf8
>
> [mysqlimport]
> character-sets-dir=/usr/share/mysql/charsets
> default-character-set=utf8
>
> [mysqlshow]
> character-sets-dir=/usr/share/mysql/charsets
> default-character-set=utf8
>
> [myisamchk]
> character-sets-dir=/usr/share/mysql/charsets
>
> [myisampack]
> character-sets-dir=/usr/share/mysql/charsets
>
> # use [safe_mysqld] with mysql-3
> [mysqld_safe]
> err-log = /var/log/mysql/mysql.err
>
> # add a section [mysqld-4.1] or [mysqld-5.0] for specific configurations
> [mysqld]
> character-set-server = utf8
> default-character-set = utf8
> user = mysql
> port = 3306
> socket = /var/run/mysqld/mysqld.sock
> pid-file = /var/run/mysqld/mysqld.pid
> log-error = /var/log/mysql/mysqld.err
> basedir = /usr
> datadir = /var/lib/mysql
> skip-locking
> key_buffer = 16M
> max_allowed_packet = 1M
> table_cache = 64
> sort_buffer_size = 512K
> net_buffer_length = 8K
> read_buffer_size = 256K
> read_rnd_buffer_size = 512K
> myisam_sort_buffer_size = 8M
> language = /usr/share/mysql/english
>
> # security:
> # using "localhost" in connects uses sockets by default
> # skip-networking
> # bind-address = 127.0.0.1
>
> log-bin
> server-id = 1
>
> # point the following paths to different dedicated disks
> tmpdir = /tmp/
> #log-update = /path-to-dedicated-directory/hostname
>
> # you need the debug USE flag enabled to use the following directives,
> # if needed, uncomment them, start the server and issue
> # #tail -f /tmp/mysqld.sql /tmp/mysqld.trace
> # this will show you *exactly* what's happening in your server ;)
>
> #log = /tmp/mysqld.sql
> #gdb
> #debug = d:t:i:o,/tmp/mysqld.trace
> #one-thread
>
> # uncomment the following directives if you are using BDB tables
> #bdb_cache_size = 4M
> #bdb_max_lock = 10000
>
> # the following is the InnoDB configuration
> # if you wish to disable innodb instead
> # uncomment just the next line
> #skip-innodb
> #
> # the rest of the innodb config follows:
> # don't eat too much memory, we're trying to be safe on 64Mb boxes
> # you might want to bump this up a bit on boxes with more RAM
> innodb_buffer_pool_size = 16M
> # this is the default, increase it if you have lots of tables
> innodb_additional_mem_pool_size = 2M
> #
> # i'd like to use /var/lib/mysql/innodb, but that is seen as a database :-(
> # and upstream wants things to be under /var/lib/mysql/, so that's the route
> # we have to take for the moment
> #innodb_data_home_dir = /var/lib/mysql/
> #innodb_log_arch_dir = /var/lib/mysql/
> #innodb_log_group_home_dir = /var/lib/mysql/
> # you may wish to change this size to be more suitable for your system
> # the max is there to avoid run-away growth on your machine
> innodb_data_file_path = ibdata1:10M:autoextend:max:128M
> # we keep this at around 25% of of innodb_buffer_pool_size
> # sensible values range from 1MB to (1/innodb_log_files_in_group*innodb_buffer_pool_size)
> innodb_log_file_size = 5M
> # this is the default, increase it if you have very large transactions going on
> innodb_log_buffer_size = 8M
> # this is the default and won't hurt you
> # you shouldn't need to tweak it
> set-variable = innodb_log_files_in_group=2
> # see the innodb config docs, the other options are not always safe
> innodb_flush_log_at_trx_commit = 1
> innodb_lock_wait_timeout = 50
>
> [mysqldump]
> quick
> max_allowed_packet = 16M
>
> [mysql]
> # uncomment the next directive if you are not familiar with SQL
> #safe-updates
>
> [isamchk]
> key_buffer = 20M
> sort_buffer_size = 20M
> read_buffer = 2M
> write_buffer = 2M
>
> [myisamchk]
> key_buffer = 20M
> sort_buffer_size = 20M
> read_buffer = 2M
> write_buffer = 2M
>
> [mysqlhotcopy]
> interactive-timeout
Re: MySQL Backup - Problem beim zurückspielen?
am 01.11.2006 13:42:02 von Axel Schwenke
Andreas Weller wrote:
[snip]
Der wahrscheinlichste Grund für einen "table full" Fehler beim Restore
eines Backups ist eine volle Platte bzw. ein voller InnoDB-Tablespace.
Und tatsächlich steht in deiner my.cnf:
>> innodb_data_file_path = ibdata1:10M:autoextend:max:128M
Schau also mal nach, ob /var/lib/mysql/ibdata1 schon die maximal
erlaubten 128MB groß ist. Wenn ja, kannst du das Limit hochsetzen
(my.cnf editieren) und nach einem Restart des MySQL-Servers sollte
das neue Limit gelten.
Falls es das nicht ist, müssen wir tiefer graben.
XL
Re: MySQL Backup - Problem beim zurückspielen?
am 03.11.2006 09:41:37 von Andreas Weller
Axel Schwenke schrieb:
>>> innodb_data_file_path = ibdata1:10M:autoextend:max:128M
>
> Schau also mal nach, ob /var/lib/mysql/ibdata1 schon die maximal
> erlaubten 128MB groß ist. Wenn ja, kannst du das Limit hochsetzen
> (my.cnf editieren) und nach einem Restart des MySQL-Servers sollte
> das neue Limit gelten.
Danke!
Genau das war's. Jetzt kann man das Backup zurückspielen.
Gruß,
Andreas