A restauração de um banco de dados MySQL escravo a partir de backups brutos do mestre fornece erros de espaço de tabelas InnoDB

3

Eu tenho uma configuração de replicação mestre / escravo onde eu uso tabelas InnoDB e MyISAM em mais de 7000 bancos de dados que eu quero copiar do meu mestre para o escravo para restaurar a replicação.

Ambos os servidores estavam executando o Ubuntu 10.04.2 LTS (que usa o pacote mysql-server 5.1.41-3ubuntu12). Recentemente eu tentei atualizar o MySQL na esperança de que eu estivesse acertando algum bug que uma nova versão tinha resolvido - então meu escravo agora é o Ubuntu 10.10. No entanto, o problema parece ser o mesmo.

Eu prefiro não interromper o meu mestre, então eu tentei tirar um instantâneo LVM do meu disco inteiro para que eu possa copiar meus dados e o diretório de log via rsync para o meu escravo:
/ var / lib / mysql: Onde meus arquivos ibdata1 e ib_logfile0, bem como todos os meus arquivos .ibd e .frm, estão armazenados. Eu usei innodb_file_per_table, então há muitos arquivos .idb.
/ var / log / mysql: Onde eu mantenho todos os meus logs binários

Depois de copiado, redefino as permissões:

chown mysql.mysql /var/lib/mysql -R  
chown mysql.mysql /var/log/mysql -R

Eu removi os arquivos master.info e relay-log.info do diretório / var / lib / mysql. (Desde que meu mestre é realmente escravo para outro mestre, para certas tabelas).

Então eu tento iniciar o mysql no escravo. Logo, começo a ver os muitos e muitos erros que se parecem com os seguintes em /var/log/mysql.err:

InnoDB: Error: tablespace id is 150238 in the data dictionary  
InnoDB: but in file ./1_107789/email.ibd it is 150747!

ou:

InnoDB: Error: trying to add tablespace 148302 of name './23_4377/link.ibd'
InnoDB: to the tablespace memory cache, but tablespace
InnoDB: 148302 of name './1_68522/open.ibd' already exists in the tablespace
InnoDB: memory cache!

E então, de vez em quando:

110207 13:55:45  InnoDB: Assertion failure in thread 2979265392 in file ../../../storage/innobase/fil/fil0fil.c line 603
InnoDB: Failing assertion: 0
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.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
110207 13:55:45 - 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.

key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=1
max_threads=10000
threads_connected=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 868418 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd: 0xbc5a7138
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 = 0xb193f13c thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x2d) [0xb7638c4d]
/usr/sbin/mysqld(handle_segfault+0x494) [0xb7304854]
[0xb707f400]
/lib/tls/i686/cmov/libc.so.6(abort+0x182) [0xb6d89a82]
/usr/sbin/mysqld(+0x477790) [0xb7514790]
/usr/sbin/mysqld(+0x47795e) [0xb751495e]
/usr/sbin/mysqld(fil_space_get_size+0xdc) [0xb751966c]
/usr/sbin/mysqld(buf_read_page+0xad) [0xb75015dd]
/usr/sbin/mysqld(buf_page_get_gen+0x331) [0xb74fab21]
/usr/sbin/mysqld(btr_get_size+0x190) [0xb75b02b0]
/usr/sbin/mysqld(dict_update_statistics_low+0x50) [0xb7503e70]
/usr/sbin/mysqld(dict_table_get+0xec) [0xb750682c]
/usr/sbin/mysqld(+0x4cde5f) [0xb756ae5f]
/usr/sbin/mysqld(row_ins+0x157) [0xb756d3c7]
/usr/sbin/mysqld(row_ins_step+0x110) [0xb756d710]
/usr/sbin/mysqld(row_insert_for_mysql+0x37e) [0xb75754de]
/usr/sbin/mysqld(ha_innobase::write_row(unsigned char*)+0xf9) [0xb74e1299]
/usr/sbin/mysqld(handler::ha_write_row(unsigned char*)+0x6d) [0xb7412d3d]
/usr/sbin/mysqld(write_record(THD*, st_table*, st_copy_info*)+0x3ba) [0xb7391e2a]
/usr/sbin/mysqld(mysql_insert(THD*, TABLE_LIST*, List&, List >&, List&, List&, enum_duplicates, bool)+0x1122) [0xb73967c2]
/usr/sbin/mysqld(mysql_execute_command(THD*)+0xc85) [0xb7317c95]
/usr/sbin/mysqld(mysql_parse(THD*, char const*, unsigned int, char const**)+0x3ae) [0xb731f45e]
/usr/sbin/mysqld(Query_log_event::do_apply_event(Relay_log_info const*, char const*, unsigned int)+0x47d) [0xb73dbe9d]
/usr/sbin/mysqld(Query_log_event::do_apply_event(Relay_log_info const*)+0x26) [0xb73dca76]
/usr/sbin/mysqld(apply_event_and_update_pos(Log_event*, THD*, Relay_log_info*)+0x137) [0xb7463cc7]
/usr/sbin/mysqld(handle_slave_sql+0x1094) [0xb74662e4]
/lib/tls/i686/cmov/libpthread.so.0(+0x596e) [0xb706396e]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb6e29a4e]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0xb183bdc6 is an invalid pointer
thd->thread_id=2
thd->killed=NOT_KILLED
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.

Eu tenho trabalhado com várias opções e tentando entender por que há uma incompatibilidade de tabela. Tanto quanto eu estou preocupado, não deve haver nenhuma incompatibilidade porque eu estou copiando os arquivos de log ibdata1, innodb, assim como o .ibd. Então, por que ele não apenas se recupera e continua, para que eu possa restaurar a replicação? Eu claramente sinto falta de algo, mas não consigo encontrá-lo.

Quaisquer pistas ou sugestões apreciadas. Obrigado

    
por Edward van Kuik 07.02.2011 / 22:30

2 respostas

2

Eu acredito que você tenha um instantâneo incoistente, especialmente devido ao erro

InnoDB: Error: tablespace id is 150238 in the data dictionary  
InnoDB: but in file ./1_107789/email.ibd it is 150747!

Pode não ser culpa do LVM. Pesquisando aqui e aqui , é meu palpite que você precisa ter certeza de que o mysql escreveu tudo nos discos (sem buffers) e que as mudanças não acontecerão se as tabelas de bloqueio estiverem no lado seguro. Também pode ser devido às diferentes versões do MySQL na pequena chance de que algo tenha mudado no código innodb. Você pode descartar isso tentando o instantâneo exato em um clone / (servidor similar) do seu mestre. Por favor, veja isso também

    
por 27.05.2011 / 23:50
2

Acho que o problema estava na maneira como eu estava copiando os dados. Como meu antigo escravo já tinha alguns dos bancos de dados nele, eu estava usando o rsync para economizar tempo na cópia dos dados:

/usr/bin/rsync -rtlP --inplace --delete /snapshot/var/lib/mysql another.host.com::root/var/lib/

Mas desde que eu adicionei a opção -I assim:

/usr/bin/rsync -rtlPI --inplace --delete /snapshot/var/lib/mysql another.host.com::root/var/lib/

funcionou para mim com sucesso. O -I (--ignore-times) diz ao rsync para 'não pular arquivos que correspondam a tamanho e tempo'. Presumivelmente, pequenas alterações de sub-segundo nos arquivos (que não alteraram o tamanho do arquivo ou o registro de data e hora do arquivo) estavam causando o problema.

    
por 28.05.2011 / 11:22