Início / dba / Perguntas / 45665
Accepted
CodeMonkey
Asked: 2013-07-04 08:35:33 +0800 CST

Qual max_allowed_packet é grande o suficiente e por que preciso alterá-lo?

  • 772

Eu tenho o MySQL (5.5) na configuração master-slave e criei outro servidor slave.

Parei o slave original, despejei os dados, copiei e reimportei e funcionou bem. Eu anotei o master_log pos do slave original e usei esses comandos para configurá-lo no novo slave

CHANGE MASTER TO MASTER_HOST='<ipaddress>', 
MASTER_USER='<username>', MASTER_PASSWORD='<password>', 
MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000851', 
MASTER_LOG_POS=15824150, 
MASTER_CONNECT_RETRY=10;

Quando eu comecei o novo escravo eu consegui

Last_IO_Error: Obteve o erro fatal 1236 do mestre ao ler dados do log binário: 'entrada de evento de log excedida max_allowed_packet; Aumente max_allowed_packet no master'

No entanto, quando eu iniciei o slave original, ele pegou bem e agora está em sincronia.

Então as perguntas:

  • o valor atual é 16M, como eu sei o quão grande devo ir? (Prefiro evitar tentativa e erro com um servidor de produção).

  • por que eu preciso aumentar o valor no mestre quando o escravo original lidou bem, o problema realmente pode ser com o novo escravo?

atualizar

Aumentei o max_allowed_packet para 1073741824 como Rolando sugeriu no mestre, escravo antigo e novo escravo, e reiniciei-os ( SET GLOBAL max_allowed_packet = 1073741824;por algum motivo não pareceu demorar)

agora o último erro de IO é o mesmo de antes, mas agora vejo

Last_SQL_Error: Falha na leitura do log de retransmissão: não foi possível analisar a entrada do evento de log de retransmissão. As possíveis razões são: o log binário do mestre está corrompido (você pode verificar isso executando 'mysqlbinlog' no log binário), o log de retransmissão do escravo está corrompido (você pode verificar isso executando 'mysqlbinlog' no log de retransmissão), um problema de rede, ou um bug no código MySQL do mestre ou escravo. Se você quiser verificar o log binário do mestre ou o log de retransmissão do escravo, poderá saber seus nomes emitindo 'SHOW SLAVE STATUS' neste escravo.

Se eu fizer um mysqlbinlog no arquivo do mestre, ele passará com comandos muito felizes por muito tempo - o arquivo é 722M - se eu fizer isso para o log de retransmissão do escravo, recebo

ERRO: Erro no Log_event::read_log_event(): 'Falha na verificação de integridade', data_len: 38916267, event_type: 69

ERRO: Não foi possível ler a entrada no deslocamento 253: Erro no formato do log ou erro de leitura.

Eu verifiquei as variáveis ​​​​e as alterações funcionaram no entanto

mysql> mostra variáveis ​​LIKE '%max_allowed_packet%';

no novo escravo mostrou max_allowed_packetE slave_max_allowed_packetonde como no mestre só temmax_allowed_packet

então eu fiz uma verificação de versão no mestre:

mysql> show variables LIKE '%version%';
+-------------------------+--------------------------------------+
| Variable_name           | Value                                |
+-------------------------+--------------------------------------+
| innodb_version          | 1.1.6                                |
| protocol_version        | 10                                   |
| slave_type_conversions  |                                      |
| version                 | 5.5.11-log                           |
| version_comment         | MySQL Community Server (GPL) by Remi |
| version_compile_machine | x86_64                               |
| version_compile_os      | Linux                                |
+-------------------------+--------------------------------------+

e no novo escravo

mysql> show variables LIKE '%version%';
+-------------------------+--------------------------------------+
| Variable_name           | Value                                |
+-------------------------+--------------------------------------+
| innodb_version          | 5.5.32                               |
| protocol_version        | 10                                   |
| slave_type_conversions  |                                      |
| version                 | 5.5.32-log                           |
| version_comment         | MySQL Community Server (GPL) by Remi |
| version_compile_machine | x86_64                               |
| version_compile_os      | Linux                                |
+-------------------------+--------------------------------------+

Essas 2 versões estão muito distantes?

mysql replication

3 respostas

  1. Não há problema em maximizar o max_allowed_packetpara 1G. Sempre que um pacote MySQL é construído, ele não saltará para 1G desde o início. Por quê?

    Primeiro você precisa saber o que é um pacote MySQL. Página 99 do Livro

    Entendendo o MySQL Internals

    explica isso nos parágrafos 1-3 da seguinte forma:

    O código de comunicação de rede do MySQL foi escrito sob a suposição de que as consultas são sempre razoavelmente curtas e, portanto, podem ser enviadas e processadas pelo servidor em um bloco, que é chamado de pacote na terminologia do MySQL. O servidor aloca a memória para um buffer temporário para armazenar o pacote e solicita o suficiente para acomodá-lo inteiramente. Essa arquitetura requer uma precaução para evitar que o servidor fique sem memória --- um limite no tamanho do pacote, o que essa opção faz.

    O código de interesse em relação a esta opção encontra-se em sql/net_serv.cc . Dê uma olhada em my_net_read() , então siga a chamada para my_real_read() e preste atenção especial em net_realloc() .

    Essa variável também limita o comprimento de um resultado de muitas funções de string. Consulte sql/field.cc e sql/intem_strfunc.cc para obter detalhes.

    Compare isso com a documentação do MySQL em max_allowed_packet:

    O tamanho máximo de um pacote ou qualquer string gerada/intermediária, ou qualquer parâmetro enviado pela função da API C mysql_stmt_send_long_data(). O padrão é 4 MB a partir do MySQL 5.6.6, 1 MB antes disso.

    O buffer de mensagem de pacote é inicializado em bytes net_buffer_length, mas pode crescer até bytes max_allowed_packet quando necessário. Esse valor por padrão é pequeno, para capturar pacotes grandes (possivelmente incorretos).

    Você deve aumentar esse valor se estiver usando colunas BLOB grandes ou strings longas. Deve ser tão grande quanto o maior BLOB que você deseja usar. O limite de protocolo para max_allowed_packet é 1 GB. O valor deve ser um múltiplo de 1024; os não-múltiplos são arredondados para o múltiplo mais próximo.

    Ao alterar o tamanho do buffer da mensagem alterando o valor da variável max_allowed_packet, você também deve alterar o tamanho do buffer no lado do cliente se o programa cliente permitir. No lado do cliente, max_allowed_packet tem um padrão de 1 GB. Alguns programas como mysql e mysqldump permitem que você altere o valor do lado do cliente configurando max_allowed_packet na linha de comando ou em um arquivo de opções.

    Dada esta informação, você deve estar feliz que o MySQL irá expandir e contratar o Pacote MySQL conforme necessário. Portanto, vá em frente e

    Mestre e Escravo devem corresponder em termos de quem eles transmitem dados, especialmente dados BLOB.

    ATUALIZAÇÃO 2013-07-04 07:03 EDT

    De suas mensagens sobre o log de retransmissão, parece que você tem o seguinte

    • um log de retransmissão corrompido
    • um bom registro mestre

    SUGESTÃO

    SHOW SLAVE STATUS\G
STOP SLAVE;
CHANGE MASTER TO
MASTER_LOG_FILE='(Relay_Master_Log_File from SHOW SLAVE STATUS\G)',
MASTER_LOG_POS=(Exec_Master_Log_Pos from SHOW SLAVE STATUS\G);
START SLAVE;

    A execução CHANGE MASTER TOlimpa todos os logs de retransmissão e inicia com um novo. Você estará replicando a partir do Último Evento BinLog Master (BinLog,Position) executado no Slave.

    De uma chance !!!

    • 24
  2. Best Answer

    Embaraçosamente, o problema era nomes de arquivos incorretos para logs, causando resultados estranhos, reimportados com os nomes de arquivos corretos e tudo estava bem .

    • 13

  3. Se você vir o log binário no mestre, as posições do log binário estão erradas. Às vezes o erro não é o que parece ser. Não altere o valor máximo do pacote. Precisamos fazer um pequeno trabalho por aqui. Então, minha sugestão, você pode precisar redefinir as coordenadas de replicação do escravo. Use mysqlbinlog no mestre para identificar onde as transações começam e procure as transações adjacentes. Reinicialize conforme explicado abaixo.

    STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000851', MASTER_LOG_POS=15824150, MASTER_HOST='master-server', MASTER_USER='master-user', MASTER_PASSWORD='master-password';

    Você pode encontrar mais detalhes sobre exatamente o que fazer neste artigo de solução de problemas do mysql . Espero que isso ajude.

    • 1

relate perguntas