Vimos erros esporádicos de ActiveRecord::StatementInvalid dos servidores MySQL ao longo de 4 horas ontem. Os erros não aconteceram desde então.
Estranhamente, as instruções SQL parecem ter sido corrompidas: um caractere aleatório ou mais deslocado por 2 bytes para trás ou para frente. Por exemplo, "Unknown table 'erades'" para uma consulta em relação a uma tabela grades . Isso não se limitava a nomes de tabelas: nomes de coluna, palavras-chave SQL e valores eram todos afetados nessas consultas.
Uma amostra de mensagens de erro:
.->,: Table '[database name].id' doesn't exist: SELECT [..] FROM [..] INNER JOIN [..] ON [..] = '[table name]'.'id' ..'->b: Incorrect table name 'topic_setsb ON ': SELECT [..] FROM [..] INNER JOIN 'topic_sets' ON ...s->q: Unknown column 'aqsigned_[redacted]' in 'field list'U->W: You have an error in your SQL syntax; [..] near 'NWLL GROUP BY ...8->:: You have an error in your SQL syntax; [..] near ':887)' at line 1: SELECT [..] WHERE [..] IN (48846, 48901, 48887)
Como o MySQL provavelmente relatará apenas o primeiro erro na instrução, não posso dizer o número exato de corrupções por instrução. A consulta SQL completa incluída na mensagem parece ser uma cópia da declaração mantida em o lado do cliente e não houve corrupção nessa parte da mensagem.
Em alguns casos, não sei dizer qual caractere poderia ter sido corrompido na mensagem de erro, como "a sintaxe correta para usar próximo a '' na linha 1" e nem todas as corrupções podem ter sido sobre desvios de byte. Isso pode ser de caracteres não imprimíveis ou pode haver inserções / exclusões de caracteres.
Havia um padrão fixo um pouco na forma como as instruções eram corrompidas, mas parecia não haver uma regra clara. por exemplo. Haveria 10-20 ocorrências de alguns padrões em que a mesma declaração foi corrompida da mesma maneira, mas a posição das corrupções varia entre esses padrões.
O log de erros que posso obter do console do RDS está vazio. Não houve degradação do serviço da AWS reportada para o período de tempo.
Houve um total de 143 erros relatados em nossa ferramenta de rastreamento de exceções. Eles se originaram de 4 trabalhadores de Passageiros, 2 na mesma instância EC2 e os outros dois em outra instância EC2. Distribuição das contagens de erros entre esses trabalhadores: 1, 41, 42, 50. Isso representa cerca de 0,001% do total de solicitações atendidas durante as 4 horas que isso aconteceu.
Para cada trabalhador, os erros ocorreram em gotejamentos: cada um relatou esses erros por cerca de 5 minutos, com 1-2 erros ocorrendo a cada poucos segundos, a 2 a 3 minutos - além daquele que tinha apenas 1 erro.
Algumas consultas eram contra o banco de dados mestre e algumas eram contra o banco de dados de réplica.
Linha do tempo
instance A launch 2018-11-13 12:00 UTC
instance A process P errors 2018-11-13 13:40-13:43 UTC
instance A process Q errors 2018-11-13 14:22-14:26 UTC
instance A shutdown 2018-11-13 20:00 UTC
instance B launch 2018-11-13 15:00 UTC
instance B process R errors 2018-11-13 15:39-15:40 UTC
instance B process S errors 2018-11-13 17:39-17:43 UTC
instance B shutdown 2018-11-13 23:00 UTC
Um conhecido admitiu que viu o mesmo tipo de erro na AWS no mesmo dia e se referiu a esta palestra [1] sobre corrupção de dados em nível de rede: ele fala sobre como os switches de rede recalculam o CRC Ethernet de um pacote quando reencaminhamento e corrupção durante o processo de reencaminhamento podem resultar em um CRC "válido" e como A soma de verificação TCP também tem uma brecha. ( Notas textuais de kevinchen.co ).
[1] !! Con 2017: Corrupção no Data Center! O TCP pode falhar em manter seus dados seguros! por Evan Jones
A recomendação deles era usar o TLS para toda a comunicação, já que a camada TLS não conseguirá decifrar os bytes corrompidos.
Também encontrei esta página que descreve a limitação do CRC e da soma de verificação. Há um erro de aparência semelhante nesta pergunta de falha do servidor e porque também havia relacionado à rede.
Estou cada vez mais convencido de que os erros são causados por algo com defeito no nível da rede.
A teoria Ethernet / TCP concorda com o comportamento errôneo que descrevi? Não tenho certeza se é possível que apenas um processo por vez veja esse erro, embora eu suponha que isso possa acontecer se um switch decidir lidar com pacotes de maneira diferente com base nos pares de portas de origem e destino, já que cada conexão utilizará um porto diferente.
Eu ficaria feliz em reformular a pergunta se esta é realmente uma questão XY.
Observação: enviei uma solicitação para o fórum da AWS para confirmação / investigação de que era algo da infraestrutura da AWS. Aqui, no serverfault, estou interessado em aprender sobre a plausibilidade da hipótese e como ela pode exibir o comportamento que vi (ou não).
Tags networking