web-dev-qa-db-fra.com

MySQL: Innodb continue de s'écraser - comment récupérer?

# free -m
             total       used       free     shared    buffers     cached
Mem:         48289      35288      13000          0        347      30399
-/+ buffers/cache:       4541      43747
Swap:         8189         51       8137

MySQL ne peut pas commencer par des erreurs ci-dessous dans /var/log/mysqld.log: http://fpaste.org/4vmb/

Il peut être seulement démarré lorsque vous ajoutez innodb_force_recovery = 1 À my.cnf, Mais je reçois ensuite une autre erreur lors du démarrage du serveur: http://fpaste.org/6azj/

Ce serveur était le maître, mais j'ai pu promouvoir un esclave comme nouveau maître. Actuellement, j'essaie de définir ce maître en panne en tant que nouvel esclave, mais je ne peux pas l'obtenir pour commencer.

Qu'est-ce que je devrais faire maintenant?

Mise à jour du jeu 19 23:50:17 ICT 2012:

Il a été démarré avec succès avec innodb_force_recovery=2, Mais mysql s'en va lorsque vous effectuez un DROP TABLE:

mysql> drop table reportingdb.bigdata_banner_scheduler;
ERROR 2013 (HY000): Lost connection to MySQL server during query

Voici les journaux: http://fpaste.org/m82a

Mise à jour Fri Jul 20 08:02:57 ICT 2012:

J'ai essayé de reconstruire la réplication en utilisant Percona xtrabackup . À la première fois, je reçois this bug lors de la copie avec innobackupex. Merci à @dtest qui suggère d'augmenter innodb_log_file_size À 1 Go et c'est bon.

Veuillez noter que: Vous devez copier innodb_* Paramètres du maître à esclave et exécuter innobackupex --apply-log /path/to/datadir Sur l'esclave si vous ne voulez pas obtenir les erreurs ci-dessous:

120720  6:18:50  InnoDB: Error: page 3670052 log sequence number 8078993744933
InnoDB: is in the future! Current system log sequence number 8078561559052.
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.5/en/forcing-innodb-recovery.html
InnoDB: for more information.
InnoDB: Error: trying to access page number 2175909760 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.
120720  6:18:50  InnoDB: Assertion failure in thread 47633462918272 in file fil0fil.c line 4434
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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
23:18:50 UTC - mysqld got signal 6 ;
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.

Mais le jeu n'est pas fini: esclave continue de s'écraser après quelques minutes:

120720  7:58:28 [Warning] Slave SQL: Could not execute Write_rows event on table reportingdb.ox_banners; Duplicate entry '14
5928' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000999, end
_log_pos 337836040, Error_code: 1062
120720  7:58:28 [Warning] Slave SQL: Could not execute Write_rows event on table reportingdb.selfserving_img_signatures; Dup
licate entry '145928' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql
-bin.000999, end_log_pos 337843612, Error_code: 1062
120720  7:58:28 [Warning] Slave SQL: Could not execute Write_rows event on table reportingdb.selfserving_email_log; Duplicat
e entry '173213' for key 'PRIMARY', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.
000999, end_log_pos 337844062, Error_code: 1062
00:58:29 UTC - 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=1048576
read_buffer_size=1048576
max_used_connections=4
max_threads=2000
thread_count=2
connection_count=2
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 4119820 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x11cc5f20
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...
stack_bottom = 40c73a78 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x2e)[0x7af52e]
/usr/libexec/mysqld(handle_fatal_signal+0x3e2)[0x67c242]
/lib64/libpthread.so.0[0x3fed00ebe0]
/usr/libexec/mysqld(_ZN13st_select_Lex17mark_as_dependentEPS_+0x4d)[0x568a3d]
/usr/libexec/mysqld[0x68cc02]
/usr/libexec/mysqld(_ZN10Item_field15fix_outer_fieldEP3THDPP5FieldPP4Item+0x670)[0x690c90]
/usr/libexec/mysqld(_ZN10Item_field10fix_fieldsEP3THDPP4Item+0x351)[0x691361]
/usr/libexec/mysqld(_ZN9Item_func10fix_fieldsEP3THDPP4Item+0x1d3)[0x6cb433]
/usr/libexec/mysqld(_Z11setup_condsP3THDP10TABLE_LISTS2_PP4Item+0x1a5)[0x53aae5]
/usr/libexec/mysqld(_Z20mysql_prepare_updateP3THDP10TABLE_LISTPP4ItemjP8st_order+0x118)[0x5df3e8]
/usr/libexec/mysqld(_Z12mysql_updateP3THDP10TABLE_LISTR4ListI4ItemES6_PS4_jP8st_ordery15enum_duplicatesbPySB_+0x2b4)[0x5e0134]
/usr/libexec/mysqld(_Z21mysql_execute_commandP3THD+0x239b)[0x575c5b]
/usr/libexec/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x10a)[0x57994a]
/usr/libexec/mysqld(_ZN15Query_log_event14do_apply_eventEPK14Relay_log_infoPKcj+0xc57)[0x734757]
/usr/libexec/mysqld(_Z26apply_event_and_update_posP9Log_eventP3THDP14Relay_log_info+0x16e)[0x516fce]
/usr/libexec/mysqld[0x51e631]
/usr/libexec/mysqld(handle_slave_sql+0xc46)[0x51f946]
/lib64/libpthread.so.0[0x3fed00677d]
/lib64/libc.so.6(clone+0x6d)[0x3fec8d325d]

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (128380d7): UPDATE `ox_banners` A
        SET A.locationAd=@locCP 
        WHERE A.zoneId = NAME_CONST('_zoneid',2452)
Connection ID (thread ID): 2061
Status: NOT_KILLED

slave-skip-errors = 1062 Semble ne pas fonctionner.

Je vais prendre l'instantané de Maître en utilisant mysqldump, espérons que cela peut résoudre le problème de crash.

mysqlreplicationinnodbrecovery
3
quanta

À partir d'une discussion de discussion, la première erreur est parce que le fichier ./reportingdb/bigdata_banner_scheduler.ibd est manquant. Il suffit de copier ce fichier du maître ne fonctionnera cependant. Vous devrez laisser tomber la table sur l'esclave puis jeter la table du maître.

Mais cette erreur d'affirmation est une question différente. Vous pouvez commencer en mode FICE_RECOVERY 1, mais quelque chose tue le processus mysqld, et il ne semble pas être la mémoire (mauvaise configuration).

Puisque vous essayez de configurer cela comme un esclave du maître récemment promu, je voudrais effacer les données et réinstallerais MySQL et commencer à partir d'une nouvelle copie du maître.

Si, pour une raison quelconque, vous aimeriez essayer de le faire fonctionner sans déversement de l'ensemble du maître (non recommandé), mes étapes seraient ceci:

  • Mettre skip-slave-start dans le my.cnf pour désactiver l'esclave de démarrer automatiquement
  • Sortir innodb-force-recovery de la my.cnf
  • Copiez tous les fichiers du datadir à un emplacement séparé sur votre serveur esclave
  • Réinstallez MySQL (étapes pour cela dépend de votre système d'exploitation)
  • Copiez le mysql et performance_schema Les répertoires de l'ancienne installent dans le nouvel installé datadir.
  • Démarrez le serveur MySQL pour vous assurer que le serveur commence normalement et sans problème.
  • Si c'est le cas, arrêtez le serveur et continuez ces étapes
  • Mettre innodb-force-recovery à 1 dans le my.cnf
  • Copiez tous les autres fichiers de votre sauvegarde dans le datadir
  • Démarrer le serveur. Cela devrait vous mettre dans un état où vous pouvez DROP le ./reportingdb/bigdata_banner_scheduler.ibd tableau.
  • DROP TABLE reportingdb.bigdata_banner_scheduler
  • Arrêter le serveur
  • Retirer le innodb-force-recovery de my.cnf
  • Démarrer le serveur.

À ce stade, si tout s'est bien passé, vous devriez avoir un serveur "esclave" de travail sans le reportingdb.bigdata_banner_scheduler Table et esclave doivent encore être désactivés (ne pas lire dans le binlog du Maître).

Les étapes que je ferais pour récupérer la table sur l'esclave sont les suivantes:

  • Du maître, prenez une vidage de la structure de la table et des données: mysqldump -u.. -p reportingdb bigdata_banner_scheduler > reportingBigData.sql
  • Copier le vidage à l'esclave
  • Importer le dépotoir dans l'esclave: mysql -u... -p reportingdb < reportingBigData.sql
  • Ensuite, commencez l'esclave de commencer à rattraper les événements des binlogs manquants
5
Derek Downey