Mysql
 sql >> Base de Dados >  >> RDS >> Mysql

Backup MySQL Amazon RDS


O RDS não permite nem ao usuário master o SUPER privilégio, e isso é necessário para executar FLUSH TABLES WITH READ LOCK . (Esta é uma limitação infeliz do RDS).

A instrução com falha está sendo gerada pelo --master-data opção, que é, obviamente, necessária se você quiser aprender as coordenadas precisas do log binário onde o backup começa. FLUSH TABLES WITH READ LOCK adquire um bloqueio de leitura global em todas as tabelas, o que permite ao mysqldump START TRANSACTION WITH CONSISTENT SNAPSHOT (como faz com --single-transaction ) e então SHOW MASTER STATUS para obter as coordenadas do log binário, após o que libera o bloqueio de leitura global porque possui uma transação que manterá os dados visíveis em um estado consistente com essa posição do log.

O RDS quebra esse mecanismo negando o SUPER privilégio e não fornecendo nenhuma solução óbvia.

Existem algumas opções hacky disponíveis para contornar isso corretamente, nenhuma das quais pode ser particularmente atraente:

  • faça o backup durante um período de baixo tráfego. Se as coordenadas do log binário não mudaram entre o momento em que você inicia o backup e após o backup começar a gravar os dados no arquivo de saída ou no servidor de destino (assumindo que você usou --single-transaction ), isso funcionará porque você sabe que as coordenadas não foram alteradas enquanto o processo estava em execução.

  • observe a posição do log binário no mestre antes de iniciar o backup e use essas coordenadas com CHANGE MASTER TO . Se o binlog_format do seu mestre está definido como ROW então isso deve funcionar, embora você provavelmente tenha que pular alguns erros iniciais, mas não deve ter nenhum erro posteriormente. Isso funciona porque a replicação baseada em linha é muito determinística e será interrompida se tentar inserir algo que já está lá ou excluir algo que já foi. Uma vez passados ​​os erros, você estará nas coordenadas verdadeiras do log binário onde o instantâneo consistente realmente começou.

  • como no item anterior, mas após restaurar o backup tente determinar a posição correta usando mysqlbinlog --base64-output=decode-rows --verbose para ler o binlog do master nas coordenadas que você obteve, verificando seu novo slave para ver quais dos eventos já devem ter sido executados antes que o snapshot realmente tenha começado, e usando as coordenadas determinadas desta forma para CHANGE MASTER TO .

  • use um processo externo para obter um bloqueio de leitura em todas as tabelas do servidor, o que interromperá todas as gravações; observe que a posição do log binário de SHOW MASTER STATUS parou de incrementar, inicie o backup e libere esses bloqueios.

Se você usar qualquer uma dessas abordagens além da última, é especialmente crítico que você faça comparações de tabelas para ter certeza de que seu escravo é idêntico ao mestre quando estiver em execução. Se você encontrar erros de replicação subsequentes... então não foi.

Provavelmente a opção mais segura -- mas também talvez a mais irritante já que parece que não deve ser necessário - é começar criando uma réplica de leitura RDS do seu mestre RDS. Quando estiver ativo e sincronizado com o mestre, você poderá interromper a replicação na réplica de leitura do RDS executando um procedimento armazenado fornecido pelo RDS, CALL mysql.rds_stop_replication que foi introduzido no RDS 5.6.13 e 5.5.33 que não requer o SUPER privilégio.

Com o slave de réplica RDS parado, pegue seu mysqldump da réplica de leitura do RDS, que agora terá um conjunto de dados imutável a partir de um conjunto específico de coordenadas mestre. Restaure este backup para seu escravo externo e, em seguida, use as coordenadas mestre da réplica de leitura RDS de SHOW SLAVE STATUS Exec_Master_Log_Pos e Relay_Master_Log_File como seu CHANGE MASTER TO coordenadas.

O valor mostrado em Exec_Master_Log_Pos em um escravo é o início da próxima transação ou evento a ser processado , e é exatamente aí que seu novo escravo precisa começar a ler no mestre.

Em seguida, você pode desativar a réplica de leitura do RDS assim que seu escravo externo estiver funcionando.