Você deve utilizar a opção server-id
no
master e no slave para estabelecer uma ID de conexão única em
cada servidor. Você deve escolher um valor único no intervalo
de 1 a 2^32-1 para cada master e slave. Example:
server-id=3
As opções que você pode utilizar no servidor master para controle do log binário estão todas descritas em Secção 4.10.4, “O Log Binário”.
A seguinte tabela descreve as opções que você pode utilizar nos servidores slaves. Você pode especificá-las na lina de comando ou no arquivo de opção.
NOTA: A replicação trata das seguintes opções de um modo especial:
--master-host
--master-user
--master-password
--master-port
--master-connect-retry
Se não existir nenhum arquivo master.info
quando o servidor slave inicia, ele usa valores específicados
no arquivo de opções ou na linha de comando. Isto irá ocorrer
quando você iniciar o servidor como um slave de replicação
pela primeira vez, ou você executar RESET
SLAVE
e desliga e reiniciar o servidor slave.
No entanto, se o arquivo master.info
existe
quando o servidor slave iniciar, ele usa o valor no arquivo e
IGNORA qualquer valor
especificado para aquelas opções no arquivo de opção ou na
linha de comando.
Suponha que você especifique esta opção em seu arquivo
my.cnf
:
[mysqld] master-host=this_host
A primeira vez que você iniciar o servidor como um slave de
replicação, ele irá ler e usar a opção do arquivo
my.cnf
. O servidor gravará então aquele
valor no arquivo master.info
. A próxima
vez que você iniciar o servidor, ele irá ler o valor da
máquina master a partir do arquivo
master.info
. Se você modificar o arquivo
my.cnf
para especificar uma máquina master
diferente, ele não terá efeito. Você deve usar
CHANGE MASTER TO
.
A partir do MySQL 4.1.1, as seguintes opções também é tratada de forma especial:
--master-ssl
--master-ssl-ca
--master-ssl-capath
--master-ssl-cert
--master-ssl-cipher
--master-ssl-key
O arquivo master.info
inclui os valores
correspondentes a essas opções. Adicionalmente, o formato do
arquivo na versão 4.1.1 inclui na sua primeira linha o número
de linhas no arquivo. Se você atualizar um servidor mais antigo
para a versão 4.1.1, o master.info
será
atualizado para o novo formato automaticamente quando o novo
servidor iniciar. (Se você substituir um MySQL 4.1.1 ou mais
novo por uma versão mais antiga que a 4.1.1, você deve remover
a primeira linha manualmente antes de iniciar o servidor mais
antigo pela primeira vez.)
Como o servidor da precedência a uma arquivo
master.info
existente sobre as opções de
inicialização acima descrito, você pode preferir usar as
opções de inicialização para estes valores, e especifique-os
usando a instrução CHANGE MASTER TO
. See
Secção 4.11.8.1, “CHANGE MASTER TO
”.
Este exemplo mostra um uso mais extensivo das opções de inicialização para configurar um servidor slave:
[mysqld] server-id=2 master-host=db-master.mycompany.com master-port=3306 master-user=pertinax master-password=freitag master-connect-retry=60 report-host=db-slave.mycompany.com
The following list describes startup options for controlling replication:
--log-slave-updates
Diz ao slave para registrar as atualizações feitas pela
thread da SQL do slave no log binário do slave. É
desligado por padrão. É claro que ele exige que ele exige
que o slave seja iniciado com o log binário habilitado
(opção --log-bin
).
--log-slave-updates
é usado quando você
deseja colocar diversos servidores em cadeia. Por exemplo,
você pode querer uma configuração como esta:
A -> B -> C
Isto é, A é o servidor master do slave B, e B é o
servidor master do slave C. Para isto funcionar, onde B é
tanto uma master quanto um slave, você deve iniciar B com a
opção --log-slave-updates
. A e B devem
ser iniciados com o log binário habilitado.
--log-warnings
Fazer slave exibir mais mensagens sobre o que está sendo feito. Por exemplo, ele avisará que ele obteve sucesso em reconectar depois de uma falha de conexão/rede, o avisrá sobre cada thread slave iniciada.
Esta opção não está limitada apenas ao uso da replicação. Ela produz avisos através de um espectro de servidores ativos.
--master-host=host
Especifica o nome de máquina ou endereço de IP do master
para replicação. Se esta opção não for dada, a thread
slave não será iniciada. O valor em
master.info
tem precedência se ele
puder ser lido. Provavelmemte um nome nelhor para está
opção seria algo do tipo
--bootstrap-master-host
, mas é muito tarde
para alterá-la agora.
--master-user=nome_usuário
O usuário da conta que a thread slave usará para
autenticar ao conectar ao master. A conrta deve ter o
privilégio REPLICATION SLAVE
(Em
versões anteriores a 4.0.2 ele devia ter o privilégio
FILE
). Se o usuário do master não for
configurado, assume-se o usuário teste
.
O valor em master.info
toma
precedência se puder ser lida.
--master-password=password
A senha da conta com a qual a thread slave autenticará
quando conectar ao master. Se não definida, um senha vazia
é considerada. O valor em master.info
toma precedência se puder ser lido.
--master-port=portnumber
A porta que o master está escutando. Se não definifa, a
configuração de compilação do
MYSQL_PORT
é consierada. Se você não
alterou as opções do configure
, ela
deve ser 3306. O valor em master.info
toma precedência se ele puder ser lido.
--master-connect-retry=seconds
O número de segundos que a thread slave espera antes de
tentar se conectar ao master no caso do master ter caído ou
a conexão for perdida. O padrão é 60. O valor em
master.info
toma precedência se puder
ser lido.
--master-info-file=filename
Especifica o nome a ser usado no arquivo que o slave grava a
informação sobre o master. O nome padrão é
master.info
no diretório de dados.
--master-ssl
,
--master-ssl-ca=file_name
,
--master-ssl-capath=directory_name
,
--master-ssl-cert=file_name
,
--master-ssl-cipher=cipher_list
,
--master-ssl-key=filename
Estas opções são usadas para configurar um conexão de
replicação segura para o servidor master usando SSL. Os
seus significados são os mesmos das opções
correspondentes --ssl
,
--ssl-ca
, --ssl-capath
,
--ssl-cert
, --ssl-cipher
,
--ssl-key
descritas em
Secção 4.4.10.5, “Opções SSL de Linha de Comando”.
Estas opções estão operacionais a partir do MySQL 4.1.1.
--max-relay-log-size=#
Para rotacionar o relay log automaticamente. See
Secção 4.6.8.4, “SHOW VARIABLES
”.
--relay-log=filename
Para especificar a localização e nome que deve ser usado
os relay logs. Você pode usá-lo para ter nomes de relay
logs independentes do nome de máquina, ou se o seu relay
log tend a ser grande (e você não que diminuir
max_relay_log_size
) e você precisa
colocá-los em alguma área diferente do diretório de
dados, ou se você quiser aumentar a velocidade balanceando
as cargas entre os discos.
--relay-log-index=filename
Para especificar a localização e nome que deve ser usado para arquivo de índice dos relay logs.
--relay-log-info-file=filename
Para dar outro nome a relay-log.info
e/ou colocá-lo em outro diretório, diferente do diretório
de dados.
--relay-log-purge=0|1
Disabilita/habilita a remoção automática dos relay logs
assim que ele não são mais necessários. Esta é uma
variável global que ode ser alterada dinâmicamente com
SET GLOBAL RELAY_LOG_PURGE=0|1
. o valor
padrão é 1.
Esta opção está disponível a partir do MySQL 4.1.1.
--relay-log-space-limit=#
Para colocar um limite superior no tamanho total de todos os
relay logs no slave (Um valor 0 significa ``ilimitado'').
Isto é útil se você tiver um disco rígido pequeno em.
sua máquina slave. Quando o limite é alcançado, a thread
de E/S fica em pausa (não lê o log binário do master)
até que a thread de SQL tenha buscado e deletado alguns dos
relay logs não utilizados. Note que este limite não é
absoluto: existem casos onde a thread SQL precisa de mais
eventos para poder deletar, neste caso a thread de E/S irá
superar o limite até que a deleção seja possível. Se
isto não for feito ela entra em deadlock (o que acontecia
antes do MySQL 4.0.13). Os usuários não devem configurar
--relay-log-space-limit
para menos que duas
vezes o valor de --max-binlog-size
(ou
--max-binlog-size
se
--max-relay-log-size
for 0) porque neste
caso há a chance de que quando a thread de E/S espera por
espaço livre porque
--relay-log-space-limit
é excedido, a
thread de SQL não tem relay log para apagar e assim não
pode satisfazer a thread de E/S, forçando-a a ignorar
temporariamente --relay-log-space-limit
.
--replicate-do-table=db_name.nome_tabela
Diz para thread slave restrigir a replicação a uma tabela
específica. Para especificar mais de uma tabela, use a
diretiva múltiplas vezes, uma para cada tabela. Isto
funcionará para atualizações através de bancos de dados,
em contraste com --replicate-do-db
. Por
favor, leia as notas que seguem esta lista de opções
--replicate-ignore-table=db_name.nome_tabela
Diz a thread slave para não replicar qualquer comando que
atualiza a tabela especificada (mesmo se qualquer outra
tabela puder ser atualizada pelo mesmo comando). Para
especificar mais de uma tabela a ser ignorada, use a
diretiva várias vezes, para cada tabela. Isto funcionará
para atualizações através de bancos de dados, em
contraste com --replicate-ignore-db
. Por
favor, leia as notas que seguem esta lista de opções
--replicate-wild-do-table=db_name.nome_tabela
Diz a thread slave para restringir a replicação a consultas onde qualquer das tabelas atualizadas correspondam a padrão de meta caracteres especificado. Para especificar mais de uma tabela, use a diretiva vária vezes, uma para cada tabela, Isto funciona para atualizações através de banco de dados. Por favor, leia as notas que seguem esta lista de opções
Exemplo:
--replicate-wild-do-table=foo%.bar%
replicará apenas atualizações que usam uma tabela em
qualquer banco de dadis que comece com
foo
e cujos nomes de tabelas comecem com
bar
.
Note que se você fizer
--replicate-wild-do-table=foo%.%
então a
regra será propagada para CREATE
DATABASE
e DROP DATABASE
, ex.:
estas duas instruções serão replicadas se o nome de banco
de dados corresponder ao padrão do banco de dados
('foo%'
aqui) (testa mágica é possível
por '%'
ser o padrão da tabela).
Caracteres curingas _
e
%
escapados: se você quiser replicar,
por exemplo, todas as tableas do banco de dados
my_own%db
(este é o nome exato do banco
de dados), e não replicar tabelas do banco de dados
my1ownAABCdb
, você deve escapar o
_
e %
: você deve usar
algo como isto:
replicate-wild-do-table=my\_own\%db
. E se
você estiver especificando esta opção para a linha de
comando, dependendo do seu sistema, você precisará escapar
o \
(por exemplo, com uma shell
bash
, você precisaria digitar
--replicate-wild-do-table=my\\_own\\%db
).
--replicate-wild-ignore-table=db_name.nome_tabela
Diz a thread slave pra não replicar um consulta onde qualquer tabela corresponda ao padrão de meta caracteres dado. Para especificar mais de uma tabela, use a diretiva várias vezes, uma vez para cada tabela. Isto funcionará para atualizações através de banco de dados. Por favor, leia as notas que seguem esta lista de opções
Exemplo:
--replicate-wild-ignore-table=foo%.bar%
não atualizará tabelas no banco de dados que iniciar com
foo
e cujo os nomes de tabela iniciem com
bar
.
Note que se você fizer
--replicate-wild-ignore-table=foo%.%
então
a regra será propagada para CREATE
DATABASE
e DROP DATABASE
, ex.
estas duas instruções não serão replciadas se o nome do
banco de dados não corresponder ao padrão
('foo%'
aqui) (esta mágica ocorre devido
ao '%'
como padrão da tabela).
Caracteres curingas _
e
%
escapados: veja as anotações na
descrição de replicate-wild-do-table
logo acima.
--replicate-do-db=nome_bd
Diz ao slave para restringir a replicação a comandos onde
o banco de dados atual (p.ex., aquele selecionado por
USE
) é nome_bd
. Para
especificar mais de uym banco de dadosm use a diretiva
várias vezes, uma vez por tabela. Note que isto não
replicará consultas entre bancos de dados tais como
UPDATE algum_bd.alguma_tabela SET
foo='bar'
se for selecionado outro banco de dados
ou nenhum banco de dados. Se você precisa que
atualizações entre bancos de dados funcionem,
certifique-se de que você tem o MySQL 3.23.28 ou posterior,
e use --replicate-wild-do-table=db_name.%
.
Por favor, leia as notas que seguem esta lista de opções
Exemplo do que não funciona como você espera: se o slave
é iniciado com --replicate-do-db=sales
, e
você faz USE prices; UPDATE sales.january SET
amount=amount+1000;
, esta consulta não será
replicada.
Se você precisar que atualizações entre bancos de dados
funcionem, use
--replicate-wild-do-table=db_name.%
.
A principal razão para este comportamento de apenas verificar o banco de dados atual é que é difícil para um comando sozinho saber se deve ser replicado ou não; por exemplo se você está usando comandos delete ou update multi-tabelas que continuam entre múltiplos bancos de dados. Também é muito mais rápido verificar apenas o banco de dados atual.
--replicate-ignore-db=nome_bd
Diz ao slave para não replicar qualquer comando onde o
banco de dados atual (p.ex. o selecionado por
USE
) é nome_bd
. Para
especificar mais bancos de daods use a diretiva diversas
vezes, uma para cada banco de dados. Você não deve
utilizar esta diretiva se você está usando atualização
através de tabelas e você não quer que estas
atualizações sejam replicadas. Por favor, leia as notas
que seguem esta lista de opções
Exemplo do que não funcionaria como esperado: se o slave é
iniciado com --replicate-ignore-db=sales
, e
você faz USE prices; UPDATE sales.january SET
amount=amount+1000;
, esta consulta será
replicada.
Se você precisar de atualizações entre banco de dados
funcione, use
--replicate-wild-ignore-table=db_name.%
.
--replicate-rewrite-db=de_nome->para_nome
Diz ao slave para traduzir o banco de dados atual (p.ex.
aquele selecionado por USE
) para
para_nome
se ele era
de_nome
no master. Apenas instruções
envolvendo a tabela podem ser afetadas (CREATE
DATABASE
, DROP DATABASE
não
poderão), e apenas se de_nome
era o
banco de dados atual no master. Isto não funcionará para
atualizações entre banco de dados. Note que a translação
é feita antes das regras de --replicate-*
serem testadas.
Exemplo:
replicate-rewrite-db=master_db_name->slave_db_name
--report-host=host
O Nome de máquina ou número IP do slave a ser relatado ao
master durante o registro do slave. Aparecerá na saída de
SHOW SLAVE HOSTS
. Deixe indefinido se
você não quiser que o slave se registre no master. Note
que ele não é suficiente para o master simplesmente ler o
número IP do slave fora dos sockets uma vez que o slave se
conecte. Devido ao NAT
e outros assuntos
de roteamento,a quele IP pode não ser válido para se
conectar ao slave a partir do master ou outras máquinas.
Esta opção está disponível a partir do MySQL 4.0.0.
--report-port=portnumber
Porta para conexão do slave relatado ao master durante o registro do slave. Defina-o apenas se o slave está escutando por uma porta diferente da padrão ou se você tiver um tunel especial do master ou outros clientes para o slave. Se não tiver certeza, deixe esta opção indefinida.
Esta opção está disponível a partir do MySQL 4.0.0.
--skip-slave-start
Diz ao servidor slave para não iniciar a thread slave na
iicialização do servidor. O usuário pode iniciá-las mais
tarde com START SLAVE
.
--slave_compressed_protocol=#
Se 1, usa compactação no protocolo cliente/servidor se tanto o slave quanto o mester suportá-la.
--slave-load-tmpdir=filename
Esta opção é igual ao valor da variável
tmpdir
por padrão. Quando a thread SQL
do slave replica um comando LOAD DATA
INFILE
, ele extrai os arquivos a serem carregados
do relay logs em arquivos temporários, e então os carrega
dentro da tabela. Se o arquivo carregado no master era
enorme, os arquivos temporários no slave também serão
enormes; embora você possa desejar que o slave coloque o
arquivo temporário em algum disco grande diferente de
tmpdir
, usando esta opção. Nestes caso,
você também pode usar a opção
--relay-log
, já que os relay logs serão
grandes também. --slave-load-tmpdir
deve
apontar para o sistema de arquivo baseado em disco; não em
um baseado em memória. Como o slave precisa de arquivos
temporários usados para replicar LOAD DATA
INFILE
) para sobreviver a uma reinicialização da
máquina.
--slave-net-timeout=#
Número de segundos a esperer por mais dados do master antes
de abortar a leitura, considerando o quebra de conexão e as
tentativas de reconectar. A primeira vez ocorre
imediatamente depois do tempo limite. O intervalo entre
tentativas é controlado pela opção
--master-connect-retry
.
--slave-skip-errors= [err_code1,err_code2,... |
all]
Diz ao a thread SQL do slave para continuar a replicação quando uma consulta retornar um erro de uma lista fornecida. Normalmente, a replicação irá parar ao encontrar um erro, dando ao usuário a chance de resolver a inconsistêncian nos dados manualmente. Não use esta opção a menos que você saiba exetamente o motivo dos erros. Se não houver erros em sua configuração da replicação e programas clientes, e não houver erros no MySQL, você nunca deve ter uma replicação abortada com erro. O uso indiscriminado desta opção resultará em slaves fora de sincronia com o master e você não terá idéia de como o problema aconteceu.
Para códigos de erros, você deve usar o número fornecido
pela mensagem de erron no seu log de erros do slave e na
saída de SHOW SLAVE STATUS
. Uma lista
completa de mensagens de erro podem ser encontradas na
distribuição fonte em
Docs/mysqld_error.txt
. Os códigos de
erros do servidor também são listados em
Secção 13.1, “Erros Retornados”.
Você também pode (mas não deve) usar um valor não
recomendado de all
o que irá ignorar
todas as mensagens de erro e continua em frente
indiferentemente. Não é preciso dizer, que se você usar
isto, não podemos garantir a integridade dos seus dados.
Por favor, não reclame se seus dados no slave não estiver
nem próximo daqueles em seu master neste caso --- você foi
avisado.
Exemplos:
--slave-skip-errors=1062,1053 --slave-skip-errors=all
Algumas destas opções, como todas as opções
--replicate-*
, só podem ser definidas na
inicialização do servidor slave, e não com ele ligado.
Planejamos corrigir isto.
Aqui está a ordem de avaliação das regras
--replicate-*
, para decidir se a consulta será
executada pelo slave ou ignorada por ele:
Existe alguma regra --replicate-do-db
ou
--replicate-ignore-db
?
Sim: teste-as como para --binlog-do-db
e --binlog-ignore-db
(see
Secção 4.10.4, “O Log Binário”). Qual é o resultado do
teste?
ignore a consulta: ignore-a e saia.
execute a consulta: não execute-a imediatamente, adie a decisão, vá para o passo abaixo.
Não: vá para o passo abaixo.
Existe alguma regra --replicate-*-table
?
Não: execute a consulta e saia.
Sim: vá para o passo abaixo. Apenas tabela que serão
atualizadas serão comparadas às regras
(INSERT INTO sales SELECT * from
prices
: apenas sales
será
comparada às regras). Se várias tabelas forem ser
atualizadas (instruções multi-tabelas) a primeira a
corresponder a regra (com ``do'' ou ``ignore'') vence
(isto é, a primeira tabela é comparada a regra. se
nenhuma decisão pode ser tomada a segunda tabela é
compara às regras, etc).
Existe alguma regra --replicate-do-table
?
Sim: o tabela encaixa em alguma delas?
Sim: execute a consulta e saia.
Não: vá para o passo abaixo.
Não: vá para o passo abaixo.
Existe alguma regra
--replicate-ignore-table
?
Sim: a tabela encaixa em alguma delas?
Sim: ignore a consulta e saia.
Não: vá para o passo abaixo.
Não: vá para o passo abaixo.
Existe alguma regra
--replicate-wild-do-table
?
Sim: a tabela se encaixa em qualquer uma delas?
Sim: execute a consulta e saia.
Não: vá para o passo abaixo.
Não: vá para o passo abaixo.
Existe alguma regra
--replicate-wild-ignore-table
?
Sim: a tabela se encaixa em qualquer uma delas?
Sim: ignore a consulta e saia.
Não: vá para o passo abaixo.
Não: vá para o passo abaixo.
Nenhuma regra --replicate-*-table
foi
correspondida. Existe outra tabela para se testar com estas
regras?
Sim: loop.
Não: testamos todas as tabelas a serem atualizadas,
nenhuma regra foi obedecida. Existem regras
--replicate-do-table
ou
--replicate-wild-do-table
?
Sim: ignore a consulta e saia.
Não: execute a consulta e saia.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.