O log binário deve substituiu o log de atualizações. O log de atualizações será removido do MySQL 5.0. O log binário contém toda informação que está disponível no log de atualizações em um formato mais eficiente e de maneira transacionalmente segura.

O log binário, como o antigo log de atualização, apenas registra instruções que realmente atualizam os dados. Assim um UPDATE ou um DELETE com um WHERE que não encontra nenhum registro não é gravado no log. Ele ignora mesmo instruções UPDATE que definam a uma coluna um valor que ela já tenha.

O propósito principal do log binário é poder atualizar o banco de dados durante uma operação de restauração de forma mais completa possível, já que o log binário conteria todas as atualizações feitas depois que um backup foi realizado.

O log binário é também usado para replicar um mysqld slave a partir de um master. See Secção 4.11, “Replicação no MySQL”.

O log binário também contém informação sobre o tempo que cada consulta leva para atualizar o banco de dados. Ele não contém consultas que não modificam dados. Se você quiser registrar todas as consultas (por exemplo, para encontrar um consulta com problema) você deve usar o log geral de consultas. See Secção 4.10.2, “O Log de Consultas”.

Quando iniciado com a opção --log-bin[=nome_arquivo], o mysqld escreve um arquivo de log contendo todos comandos SQL que atualizam dados. Se nenhum arquivo for fornecido, ele aponta para o nome da máquina seguido de -bin. Se for fornecido o nome do arquivo, mas ele não tiver o caminho, o arquivo é escrito no diretório de dados.

Se você fornecer uma extensão à --log-bin=nome_arquivo.extensão, a extensão será removida sem aviso.

O mysqld irá acrescentar uma extensão ao nome de arquivo do log binário que é um número que é incrementado cada vez que mysqladmin refresh, mysqladmin flush-logs, a instrução FLUSH LOGS forem executados ou o servidor for reiniciado. Um novo log binário também será automaticamente criado quando o tamanho do log atual alcançar max_binlog_size. Nota se você estiver usando transações: uma transação é escrita em um bloco no arquivo de log binário, já que ele nunca é separado entre diversos logs binários. Desta forma, se você tiver grnades transações, você pode ter logs binários maiores que max_binlog_size.

Você pode deletar todos os arquivos de log binário com o comando RESET MASTER (see Secção 4.6.5, “Sintaxe de RESET”), ou apenas alguns deles com PURGE MASTER LOGS (see Secção 4.11.7, “Instruções SQL para Controle do Servidor Master”).

Você pode utilizar as seguintes opções ao mysqld para afetar o que é documentado pelo log binário (tenha certeza de ler as notas que seguem esta tabela):

As regras estão avaliadas na seguinte ordem, para decidir se a consulta deve ser escrita no log binário ou não:

Então, por exemplo, um slave em execução com apenas binlog-do-db=sales não gravará no log binário qualquer consulta em que o banco de dados atual é diferente de sales (em outras palavras, binlog-do-db pode, significar algumas vezes, ``ignore outros bancos de dados'').

Para saber quais arquivos binários foram usados, o mysqld irá criar também um arquivo de índice para o log binário que contém o nome de todos os arquivos de log binário usados. Por padrão este arquivo tem o mesmo nome que o arquivo de log binário, com a extensão '.index'. Você pode alterar o nome do arquivo de índice do log binário com a opção --log-bin-index=[nome_arquivo]. Você não deve eduitar este arquivo manualmente enquanto o mysqld estiver em execução; fazer isto confundiria o mysqld.

Se estiver sendo usado replicação, os arquivos de log binário antigos não devem ser apagados até ter certeza que nenhum slave irá mais precisar deles. Uma forma de fazer isto é o utilizar mysqladmin flush-logs uma vez por dia e então remover qualquer log com mais de 3 dias. Você pode removê-los manualmente, ou de preferência usando PURGE MASTER LOGS (see Secção 4.11.7, “Instruções SQL para Controle do Servidor Master”) o qual atualizará de forma segura o arquivo de índice do log binário para você (e que pode ter um argumento de data desde o MySQL 4.1)

Uma conexão com o privilégio SUPER pode desabilitar o registro no log binário de suas consultas usando SET SQL_LOG_BIN=0. See Secção 4.11.7, “Instruções SQL para Controle do Servidor Master”.

Você pode examinar o arquivo de log binário com o utilitário mysqlbinlog. Por exemplo, você pode atualizar um servidor MySQL a partir de um log binário como mostrado a seguir:

mysqlbinlog arquivo-log | mysql -h nome_servidor

Veja Secção 4.9.5, “mysqlbinlog, Executando as Consultas a Partir de um Log Binário” para mais informações sobre o utilitário mysqlbinlog e como utilizá-lo.

mysqlbinlog --help irá lhe fornecer mais informações de como usar este programa!

Se você estiver utilizando BEGIN [WORK] ou SET AUTOCOMMIT=0, você deve utilizar o log binário do MySQL para backups no lugar do antigo log de atualização.

O Log binário é feito imedatamente depois que uma consulta terminar mas antes que os bloqueios sejam liberados ou algum commit seja feito. Isto garante que o log seja feito na ordem de execução.

Atualizações em tabelas não transacionais são armazenadas o log binário imediatamentedepois da execução. Para tabelas tranascionais como BDB ou InnoDB, Todas atualizações (UPDATE, DELETE ou INSERT) que alteram uma tabela transacional são armazenadas no cache até um COMMIT. Quaisquer atualizações a uma tabela não transacional são armazenadas no log binário de uma vez. Todas as threads irão, no início, alocar um buffer de binlog_cache_size para registrar consultas. Se uma conaulta é maior que o registro, a thread irá criar um arquivo temporário para lidar com a mesma. O arquivo temporário será apagado quando a thread terminar.

O max_binlog_cache_size (padrão 4G) pode ser usado para restringir o tamanho total usado para armazenar uma consulta multi-transacional. Se uma transação é maior que isto ela falhará e fará um roll back.

Se você estiver utilizando o log de atualização ou o binário, inserções concorrentes não funcionarão juntas com CREATE ... INSERT e INSERT ... SELECT. Isto é para garantir que você possa recriar uma cópia exata de suas tabelas aplicando o log em um backup.