A Replicação será feita corretamente com valores AUTO_INCREMENT, LAST_INSERT_ID e TIMESTAMP.

As funções USER() e LOAD_FILE() são replicadas sem alterações e não funcionarão de forma confiável no slave. Isto também é verdade para CONNECTION_ID() em versões de servidor slaves mais antigas que 4.1.1. A nova função PASSWORD() no MySQL 4.1, é bem replicada desde os masters 4.1.1; o seu slave deve ser 4.1.0 ou acima para replicá-la. Se você tem slaves mais antigos e precisa replicar PASSWORD() do seu master 4.1.x, você deve iniciar o master com a opção --old-password.

As variávies SQL_MODE, UNIQUE_CHECKS, SQL_SELECT_LIMIT, SQL_AUTO_IS_NULL e TABLE_TYPE não são replicados ainda. FOREIGN_KEY_CHECKS é replicado desde a versão 4.0.14.

Você deve uilizar o mesmo conjunto de caracteres (--default-character-set) no master e slave. Senão, você pode conseguir erros de chaves duplicadas no slave, pois uma chave que é considrada como única no conjunto de caracteres no master pode não ser único no conjunto de caracteres do slave.

Se você estiver usando tabelas transacionais no master e não transacionais (para as mesmas tabelas) no slave, você terá prblemas se o slave for parado no meio de um bloco BEGIN/COMMIT, já que o slave irá, mais tarde, iniciar a partir do início do bloco BEGIN. Este assunto está em nosso TODO e será corrigido em um futuro próximo.

Consultas de atualização que usam variáveis de usuários são mal replicadas nas versões 3.23 e 4.0. Isto é corrigido no MySQL 4.1. Note que nomes de variáveis de usuários são caso insensitivo a partir da versão 5.0, assim você deve levar isto em conta quando configurar uma replicação entre um servidor com versão 5.0 e outro com uma versão anterior.

O slave pode se conectar ao master usando SSL, se o master e o slave forem ambos 4.1.1 ou mais novos.

Embora nunca tenhamos tido casos de ocorrênciar reais, é teoricamente possível de que o dado no master e no slave podem estar diferentes se uma consulta é projetada de modo que a modificação do dado seja não determinística, p.ex. deixar a vontade do otimizados de consultas (o que geralmente não é uma boa prática, mesmo fora da replicação!). Para uma explicação detalhada Secção 1.8.6.2, “Open Bugs / Deficiências de Projeto no MySQL”.

Antes do MySQL 4.1.1, os comandos FLUSH, ANALYZE, OPTIMIZE e REPAIR não são armazenados no log binário e por isto não são replicados para o slave. Isto normalmente não é um problema já que estes comandos não alteram nada. Isto significa, no entanto, que se você atualizar a tabela de privilégio do MySQL diretamente sem usar a instrução GRANT e replicar o banco de dados de privilégios mysql, você deve fazer um FLUSH PRIVILEGES em seu slave para que os novos privilégios tenham efeito. Também, se você utilizar FLUSH TABLES ao renomear uma tabela MyISAM envolvida em uma tabela MERGE, você terá uqe executar FLUSH TABLES manualmente no servidor. Desde o MySQL 4.1.1, estes comandos são escritos no log binário (exceto FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE, FLUSH TABLES WITH READ LOCK) a menos que você especifique NO_WRITE_TO_BINLOG (ou seu alias LOCAL). Para um exemplo da sintaxe Secção 4.6.4, “Sintaxe de FLUSH”.

O MySQL suporta somente um master e vários slaves. Posteriormente adicionaremos um algorítimo de votação para trocar automaticamente o master se alguma coisa estiver errada com o master atual. Iremos também introduzir processos agentes para ajudar a fazer o balanceamento de carga enviando consultas SELECT para diferentes slaves.

Tabelas temporárias são replicadas, exceto no caso em que você desliga o servidor slave (e não apenas a thread slave), e você tem alguns tabelas temporárias replicadas e são usadas em instruções UPDATES que ainda não foram executadas no slave. (Se você desligar o slave, as tabelas temporárias necessárias por estas atualizações não estarão mais disponíveis quando o slave iniciar novamente.) Para evitar este problema, não desligue o servidor enquanto ele tiver tabelas temporárias abertas. Em vez disto, use este procedimento:

Planejamoc corrigir este problema em um futuro próximo.

É seguro conectar servidores em um relacionamento master/slave circular com log-slave-updates habilitado. Note, entretanto, que várias consultas não irão funcionar corretamente neste tipo de configuração a menos que o código do cliente seja escrito para tomar cuidado dos potenciais problemas que podem ocorrer em diferentes sequências em servidores diferentes.

Isto significa que você pode fazer uma configuração parecida com o seguinte:

A -> B -> C -> A

As IDs do servidor são codificadas nos eventos do log binário. A saberá quando o evento que ele lê é foi originalmente criado por A, assim A não o executará não haverá loop infinito. Mas esta configuração circular só funcionará se você realizar atualizações não conflitantes entre as tabelas. Em outras palavras, se você insere dados em A e C, você nunca deve inserir um registro em A que pode ter uma chave confiltante com um registro em C. Você também não deve atualizar os mesmos registros em dois servidores se a ordem que a atualização é aplicada importa.

Se houver um erro em uma consulta no slave, a thread slave irá terminar e uma mensagem irá aparecer no log de erro do slave. Você deve então conectar a um slave manualmente, corrigir a causa do erro (por exemplo, tabela não existente), e então executar o comando sql SLAVE START.

Se a conexão para o master for perdida, o slave irá tentar se reconectar imediatamente. Se ele falhar, o slave irá tenatr a cada master-connect-retry segundos (padrão 60). Por causa disto, é seguro desligar o master, e então reiniciá-lo depois de um tempo. O slave também está apto para lidar com interrupções de rede. No entanto o slave notificará a a perda da rede apenas após não ter recebido dados do master por slave_net_timeout segundos. Assim se sua perda for pequena, você pode querer diminuir slave_net_timeout. See Secção 4.6.8.4, “SHOW VARIABLES”.

Desligar o slave (corretamente) também é seguro, pois mantém sinais de onde parou. Desligamentos incorretos podem produzir problemas, especialmente se o cache de disco não foi sincronizado antes do sistema morrer. Seu sistema de tolerância a falhas será melhorado se você possuir um bom No-Break ou UPS.

Devido a natureza não trabnsacional das tabelas MyISAM, é possível ter uma consulta que atulizará apenas parcialmente uma taela e retornará um código de erro. Isto pode acontecer, por exemplo, em uma inserção multi-registro que tem uma violação da restrição da chave o use uma consulta de atualização é finalizada após atualizar alguns dos registros. Se isto acontecer no master, a thread slave sairá e irá esperar o DBA decidir o que fazer com isto a menos que seja autenticado e a execução da consulta resulte no mesmo código de erro. Se este comportamento da validação do código de erro não for desejável, algum (ou todos) os erros podem ser ignorados com a opção --slave-skip-errors. Ela está disponível a partir da versão 3.23.47.

Se você atualiza tabelas transacionais a partir de tabelas não-transacioanis dentro de um segmento BEGIN/COMMIT, a atualização no log binário pode estar fora de sincronia se algumas threads alterarem a tabela não transacional antes do commit da transação. Isto é porque a transação é escrita no log binário apenas quando é feito o commit.

Antes da versão 4.0.15, qualquer atualização de uma tabela não transacional é gravada no log binário imeditamente quando a atualização é feita enquanto atualizações transacionais são gravadas no COMMIT ou não gravadas se você utilizar um ROLLBACK. Você deve levar isto em conta quando atualizar tabelas transacionais e não transacionais na mesma transação e você estiver usando o log binário para backup ou replicação. Na versão 4.0.15 nós alteramos o comportamento do registro de transações que misturam atualizações de tabelas transacionais e não transacionais, que soluciona o problema (ordem das consultas boas no log binário, e todas as consultas necessárias são gravadas no log binário mesmo no caso de um ROLLBACK). O problema que permanece é quando uma segunda conexão atualiza uma tabela não transacional enquanto a primeira transação da conexão ainda não está finalizada (ordenação errada ainda pode ocorrer, porque a atualização da segunda conexão será gravada imediatamente depois de ela ter sido feita).

LOAD DATA INFILE é tratado apropriadamente desde que o arquivo ainda esteja no servidor master no momento da propagação da atualização.

LOAD LOCAL DATA INFILE será ignorado.

Na versão 3.23 RAND() em atualizações não é replicado apropriadamente. Use RAND(alguma_expr_nao_rand) se você estiver replicando atualizções com RAND(). Você pode, por exemplo, utilizar UNIX_TIMESTAMP() para o argumento de RAND(). Isto é corrigido na versão 4.0.