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 comCHANGE MASTER TO
. Se obinlog_format
do seu mestre está definido comoROW
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 usandomysqlbinlog --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 paraCHANGE 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 deSHOW 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.