Estou procurando melhorar nossa tolerância a falhas para nosso armazenamento persistente. Depois de ler vários documentos on-line sobre como configurar a replicação master <> master, ainda gostaria de perguntar aos especialistas sobre a ordem de configuração, para garantir que não perca nada importante.
Nossa configuração será um mestre <> mestre, no entanto, apenas um mestre será gravado por vez. Isso será controlado via "ip flutuante", que pode ser configurado para apontar para o mestre secundário, se o mestre primário falhar.
Com uma única configuração mestre de gravação <> mestre, não preciso me preocupar em definir a configuração
auto_increment_offset
correta?O MySQL replica todos os bancos de dados por padrão ou preciso identificá-los explicitamente por meio de
binlog-do-db
?Preciso fazer uma exportação do master1 e importar para o master2, antes de iniciar a replicação, ou posso iniciar o master 2 para coletar todas as transações dos últimos meses?
Só para esclarecer, preciso configurar um usuário "replicador" (com permissões de replicação) em master1 e master2?
-- Atualização 15/08/2014 --
Este é o guia que segui para minha configuração inicial
Para responder à pergunta nº 2 , fiz o seguinte:
Observe que tenho uma performance_schema
tabela, porque estou usando o Percona MySQL. Pela edição de Rolando, o seguinte não é necessário se você deseja replicar TODOS os bancos de dados, no entanto, estou deixando aqui para a posteridade mostrar aos outros como eles podem especificar vários bancos de dados, se não quiserem exportar todos.
binlog_do_db = information_schema
binlog_do_db = mysql
binlog_do_db = performance_schema
binlog_do_db = example_blog
binlog_do_db = example_core
binlog_do_db = example_log
Para responder à pergunta nº 3 , acabei criando um instantâneo do Master1 emitindo o seguinte comando:
mysqldump -h localhost -p -u root --opt --all-databases --single-transaction --master-data > /tmp/example_snapshot_`date +%Y_%m_%d__%H_%M_%S`.sql
Observe o --master-data
parâmetro, de acordo com a documentação do mysql, isso nos permite criar um instantâneo sem precisar criar uma nova sessão e lidar com o bloqueio da tabela. No entanto, adiciona uma linha extra ao .sql
arquivo resultante:
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000029', MASTER_LOG_POS=107;
Eu removi esta linha porque queria fazer essa alteração manualmente, em cada mestre.
Fico feliz em informar que a replicação parece estar funcionando. Obrigado Rolando!
Sim você está certo. Eu configurei configurações Master-Master por anos com um Write Master. Eu nunca toquei nas opções auto_increment. Nunca teve um incidente.
Sim, é por padrão. Embora o binlog-do-db exista, eu não o recomendaria, pois você está fazendo Master-Master. Se você tiver escravos adicionais, é melhor configurar a filtragem no escravo. Dessa forma, você tem todos os eventos binlog para recuperação pontual e outros incidentes. Esses incidentes podem incluir topologias em estrela (que apresentam mestres de distribuição, um mestre que não hospeda nenhum dado, apenas binlogs. Esses binlogs podem ser filtrados com binlog_do_db para reduzir o tráfego de binlog para escravos).
Você precisa exportar de master1 e importar para master2.
A única maneira de fazer isso é se você tiver todos os binlogs desde que carregou o master1 e nunca apagou nenhum dos binlogs. A maioria das pessoas gira seus binlogs, tornando isso impossível.
Preciso configurar um usuário "replicador" (com permissões de replicação) em master1 e master2?
Sim
EPÍLOGO
Eu configurei o ucarp ao longo dos anos como o mecanismo de failover para o IP flutuante. A maioria usa Linux Heartbeat, Pacemaker e outros. Então, você está no estádio do que precisa ser feito.