AWS RDS mysqldump pendurado

Question

Estou tentando migrar dados entre instâncias do RDS MySQL. Não consigo usar snapshots porque, com essa migração, desejo criptografar as versões de disco e de atualização subjacentes (5.1.73a a 5.5.41). Os dados estão localizados em uma única tabela; no geral, o banco de dados pesa 24,3 GB e 23,9 GB são centralizados em uma tabela (uma tabela de login do usuário).

Em um esforço para limitar o tempo de inatividade, estou fazendo backup dos dados históricos nessa tabela - ou seja, antes do tempo de inatividade, transfiro todas as leituras da tabela de login onde o id é menor que 89.000.000 e durante as linhas de inatividade é maior ou igual a 89.000.000. O comando é:

mysqldump -u${source_user} --opt --skip-add-drop-table -p${source_password} --host=${source_host} ${database} ${table_name} --where="${where_clause}" | sed 's/CREATE TABLE/CREATE TABLE IF NOT EXISTS/g' | mysql -C -u${target_user} -p${target_password} --host=${target_host} ${database}

É hacky, mas funcionou bem anteriormente. Eu corro de um terceiro servidor.

No entanto, desta vez estou com problemas. Eu corri de algumas maneiras. Quando eu o executo como um bloco, a taxa de transferência é extremamente variável e, eventualmente, todo o processo acaba interrompido sem qualquer carga de rede demonstrada no servidor de coordenação. Eu também tentei dividir as linhas por id (ie seq 0 100000 89000000 ), que começa ótimo, mas paira em partes específicas - por exemplo, o pedaço mediano de 100k-linhas leva cerca de 8 segundos, mas talvez uma em cada dez linhas leva 300 + segundos Eu nem ligaria se demorasse tanto tempo, mas isso também acontece:

mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table at row: 42158

A instância de destino mostra o uso da CPU de 100%, logs de escaninho muito ocupados, gravação de 'iops' perto de 600 e profundidades de filas, novamente spikey, perto de 20. Eu tentei definir praticamente todo o tempo limite para 1000 segundos, dobrando o tamanho do log da caixa, com muito pouco efeito. Meu colega de trabalho especula que isso é um problema com o write IOPS (é uma instância baseada em SSD sem IOPS provisionado para o registro), mas tomamos essa mesma abordagem com servidores semelhantes e não tivemos esse mesmo problema. A fonte é uma imagem recente do servidor de produção atual com uma unidade magnética.

O que estou perdendo? Obrigado.

    

Answer 1

Na minha situação, a abordagem que finalmente parece ter funcionado envolveu a desativação do uso do log bin, como mencionado aqui . Especificamente, retornei minhas configurações de grupo de parâmetros de volta ao normal, desliguei o log de bin configurando a retenção para 0, despejei o SQL em um arquivo e, em seguida, simplesmente carreguei mysql -C -u${target_user} -p${target_password} --host=${target_host} ${database} < ${filename} .

Todo o monitoramento mencionado acima é agora muito mais estável, com iops de gravação permanecendo em ~ 600 e profundidade de fila em ~ 10 (e log de bin é, naturalmente, em 0). O processo atual tem uma média de 1 MB / s, o que poderia ser mais rápido, mas ainda é cerca de três vezes mais rápido do que eu estava experimentando antes - e, claro, não estou descartando conexões agora.

    

Answer 2

Em vez de fazer um dump e recarregar, eu configuraria temporariamente a replicação entre os dois servidores MySQL, em que o master é o servidor antigo e o slave é o novo. Você pode, então, deixar que leve o tempo que for necessário para concluir e, quando terminar, poderá quebrar a replicação, desconfigurar a nova instância como um escravo de replicação e começar a usá-la no lugar do servidor original. Isso limita seu tempo de inatividade necessário a apenas alguns instantes no final do processo, quando você está quebrando a replicação e trocando qual servidor MySQL seu aplicativo usa.