Administração do Bancos de Dados MariaDB - Databases - Software - Computers

Administração do Bancos de Dados MariaDB

Índice

Configurando o MySQL
Opções de Linha de Comando do mysqld
Arquivo de Opções my.cnf
Executando Múltiplos MariaDB Servers na Mesma Máquina
Executando Múltiplos Servidores no Windows
Executando Múltiplos Servidores no Unix
Usando Programas Clientes em um Ambiente Multi-Servidor
Detalhes Gerais de Segurança e o Sistema de Privilégio de Acesso do MariaDB
Segurança Geral
Como Tornar o MariaDB Seguro contra Crackers
Opções de Inicialização para o mysqld em Relação a Segurança.
Detalhes de Segurança com LOAD DATA LOCAL
O Que o Sistema de Privilégios Faz
Como o Sistema de Privilégios Funciona
Privilégios Fornecidos pelo MySQL
Conectando ao Servidor MySQL
Controle de Acesso, Estágio 1: Verificação da Conexão
Controle de Acesso, Estágio 2: Verificação da Requisição
Hashing de Senhas no MariaDB 4.1
Causas dos Erros de Accesso Negado
Gerenciamento das Contas dos Usuários no MySQL
A Sintaxe de GRANT e REVOKE
Nomes de Usuários e Senhas do MariaDB
Quando as Alterações nos Privilégios tem Efeito
Configurando os Privilégios Iniciais do MariaDB
Adicionando Novos Usuários ao MySQL
Deletando Usuários do MariaDB
Limitando os Recursos dos Usuários
Configurando Senhas
Mantendo Sua Senha Segura
Usando Conexões Seguras
Prevenção de Disastres e Recuperação
Backups dos Bancos de Dados
Sintaxe de BACKUP TABLE
Sintaxe de RESTORE TABLE
Sintaxe de CHECK TABLE
Sintaxe do REPAIR TABLE
Utilizando myisamchk para Manutenção de Tabelas e Recuperação em Caso de Falhas
Configurando um Regime de Manutenção das Tabelas
Obtendo Informações sobre as Tabelas
Adiministração do Banco de Dados e Referência de Linguagem
Sintaxe de OPTIMIZE TABLE
Sintaxe de ANALYZE TABLE
Sintaxe de CHECKSUM TABLE
Sintaxe de FLUSH
Sintaxe de RESET
Sintaxe de PURGE MASTER LOGS
Sintaxe de KILL
Sintaxe de SHOW
Localização do MariaDB e Utilização Internacional
O Conjunto de Caracteres Utilizado para Dados e Ordenação
Mensagens de Erros em Outras Línguas
Adicionando um Novo Conjunto de Caracteres
Os Vetores de Definições de Caracteres
Suporte à Ordenação de Strings
Suporte à Caracteres Multi-byte
Problemas com Conjuntos de Caracteres
Utilitários e Scripts do Lado do Servidor MySQL
Visão Geral dos Scripts e Utilitários do Lado Servidor
mysqld-safe, o wrapper do mysqld
mysqld_multi, programa para gerenciar múltiplos servidores MySQL
myisampack, O Gerador de Tabelas Compactadas de Somente Leitura do MariaDB
mysqld-max, om servidor mysqld extendido
Utilitários e Scripts do Lado do Cliente MySQL
Visão Geral dos Utilitários e Scripts do Lado do Cliente
MariaDB, A Ferramenta de Linha de Comando
mysqlcc, The MariaDB Control Center
mysqladmin, Administrando um Servidor MySQL
mysqlbinlog, Executando as Consultas a Partir de um Log Binário
Usando mysqlcheck para Manutenção de Tabelas e Recuperação em Caso de Falhas
mysqldump, Descarregando a Estrutura de Tabelas e Dados
mysqlhotcopy, Copiando Bancos de Dados e Tabelas do MariaDB
mysqlimport, Importando Dados de Arquivos Texto
mysqlshow, Exibindo Bancos de Dados, Tabelas e Colunas
mysql_config, Opções para compilação do cliente MySQL
perror, Explicando Códigos de Erros
Como Executar Comandos SQL a Partir de um Arquivo Texto
Os Arquivos de Log do MariaDB
O Log de Erros
O Log de Consultas
O Log de Atualizações
O Log Binário
O Log para Consultas Lentas
Manutenção do Log de Arquivo
Replicação no MySQL
Introdução
Visão Geral da Implementação da Replicação
Detalhes de Implementação da Replicação
Como Configurar a Replicação
Recursos de Replicação e Problemas Conhecidos
Opções de Inicialização da Replicação
Instruções SQL para Controle do Servidor Master
Instruções SQL para Controle do Servidor Slave
FAQ da Replicação
Problemas com Replicação
Relatando Problemas de Replicação

Configurando o MariaDB

Opções de Linha de Comando do mysqld
Arquivo de Opções my.cnf

Opções de Linha de Comando do mysqld

Na maioria dos casos você deve gerenciar as opções do mysqld por meio dos arquivos de opções. Leia 'Arquivo de Opções my.cnf'.

mysqld e mysqld.server lêem opções dos grupos mysqld e server. mysqld_safe lê as opções dos grupos mysqld, server, mysqld_safe e mysqld_safe. Um servidor MariaDB embutido normalmente lê opções do grupos server, embedded e xxxxx_SERVER, onde xxxxx é o nome da aplicação.

mysqld aceita os seguintes opções de linha de comando. Aqui está uma lista das mais comuns. Para uma lista completa execute mysqld --help. As opções usadas para replicação estào listadas em uma seção separada, veja 'Opções de Inicialização da Replicação'.

Pode se alterar a maioria dos valores de um servidor em execução com o comnado SET. Leia 'Sintaxe de SET'.

Arquivo de Opções my.cnf

O MariaDB pode, desde a versão 3.22, ler as opções padrões de inicialização para o servidor e para clientes dos arquivos de opções.

No Windows, o MariaDB lê opções padrões dos seguintes arquivos:

Nome do Arquivo Propósito
Windows-directory\my.ini Opções globais
C:\my.cnf Opções globais

Windows-directory é a localização do seu diretório Windows.

No Unix, o MariaDB lê opções padrões dos seguintes arquivos:

Nome do arquivo Propósito
/etc/my.cnf Opções globais
DATADIR/my.cnf Opções específicas do servidor
defaults-extra-file O arquivo especificado com --defaults-extra-file=#
~/.my.cnf Opções específicas do usuário

DATADIR é o diretório de dados do MariaDB (normalmente /usr/local/mysql/data para instalações binárias ou /usr/local/var para instalações de código fonte). Perceba que este é o diretório que foi especificado na hora da configuração, não o especificado com --datadir quando o mysqld inicia! (--datadir não tem efeito sobre o local onde o servidor procura por arquivos de opções, porque ele procura pelos arquivos antes de processar qualquer argumento da linha de comando.)

Note que no Windows, você deve especificar todos os caminhos no arquivo de opção com / no lugar de \. Se for utilizado o \, será necessário digitá-lo duas vezes, pois o \ é o caractere de escape no MariaDB.

O MariaDB tenta ler os arquivos de opções na ordem listada acima. Se múltiplos arquivos de opções existirem, uma opção especificada em um arquivo lido depois recebe a precedência sobre a mesma opção especificada em um arquivo lido anteriormente. Opções especificadas na linha de comando recebem a precedência sobre opções especificadas em qualquer arquivo de opções. Algumas opções podem ser especificadas usando variáveis de ambiente. Opções especificadas na linha de comando ou nos arquivos de opção tem precendencia sobre valores nas variáveis de ambiente. Leia Apêndice F, Variáveis de Ambientes do MariaDB.

Os seguintes programas suportam arquivos de opções: MariaDB, mysqladmin, mysqld, mysqld_safe, mysql.server, mysqldump, mysqlimport, mysqlshow, mysqlcheck, myisamchk, e myisampack.

Desde a versão 4.0.2, você pode usar o prefixo loose para opções de linha de comando (ou opções no my.cnf). Se uma opção possui o prefixo loose, o programa que a ler não finalizará com um erro se uma opção for desconhecida, mas apenas enviará um aviso:

shell> mysql --loose-no-such-option

Você pode usar arquivos de opções para especificar qualquer opção extendida que o programa suporte! Execute o programa com --help para obter uma lista das opções disponíveis.

Um arquivo de opções pode conter linhas na seguinte forma:

O grupo [client] permite especificar opções para todos clientes MariaDB (não o mysqld). Este é o grupo perfeito de se usar para espeficar a senha que você usa para conectar ao servidor. (Mas tenha certeza que o arquivo de opções só pode ser lido e gravado por você)

Se você quiser criar opções que devem ser lidas por uma versão específica do servidor mysqld você pode fazer isto com [mysqld-4.0], [mysqld-4.1] etc:

[mysqld-4.0]
new

A nova opção acima só será usada com o versões 4.0.x do servidor MySQL.

Perceba que para opções e valores, todos espaços em branco são automaticamente apagados. Você pode usar a sequencia de escape '\b', '\t', '\n', '\r', '\\' e '\s' no valor da string ('\s' == espaço).

Aqui está um típico arquivo de opções globais.

[client]
port=3306
socket=/tmp/mysql.sock
[mysqld]
port=3306
socket=/tmp/mysql.sock set-variable = key_buffer_size=16M set-variable = max_allowed_packet=1M
[mysqldump]
quick

Aqui está um típico arquivo de opções do usuário

[client]
# A senha seguinte será enviada para todos clientes MariaDB password='minha_senha'
[mysql]
no-auto-rehash set-variable = connect_timeout=2
[mysqlhotcopy]
interactive-timeout

Se você tem uma distribuição fonte, você encontrará arquivos de exemplo de configuração chamados my-xxxx.cnf no diretório support-files. Se você tem uma distribuição binária olhe no diretório de instalação DIR/support-file, onde DIR é o caminho para o diretório de instalação (normalmente C:\mysql ou /usr/local/mysql). Atualmente existem arquivos de configuração para sistemas pequenos, médios, grandes e enormes. Você pode copiar my-xxxx.cnf para seu diretório home (renomeie a cópia para .my.cnf para experimentar.

Todos os programas MariaDB que suportam arquivos de opções aceitam opções:

Opção Descrição
--no-defaults Não lê nenhum arquivo de opções.
--print-defaults Imprima o nome do programa e todas opções.
--defaults-file=caminho-para-arquivo-padrão Utilize somente o arquivo de configuração específicado.
--defaults-extra-file=caminho-para-arquivo-padrão Leia este arquivo de configuração depois do arquivo de configuração global mas antes do arquivo de configuração do usuário.

Perceba que as opções acima devem vir primeiro na linha de comando para funcionar, com exceção que --print-defaults deve ser usado logo depois dos comandos --defaults-file ou --defaults-extra-file.

Notas para desenvolvedores: O tratamento de arquivos de opções é implementado simplesmente processando todos as opções coincidentes (isto é, opções no grupo apropriado) antes de qualquer argumento da linha de comando. Isto funciona bem para programas que usam a última instância de uma opção que é especificada diversas vezes. Se você tem um programa antigo que trata opções especificadas várias vezes desta forma mas não lê arquivos de opções, você só precisa adicionar duas linhas para lhe dar esta capacidade. Verifique o código fonte de qualquer um dos clientes MariaDB padrão para ver como fazer isto.

Nos scripts shell você pode usar o comando my_print_defaults para analisar os arquivos de opção. O seguinte exemplo mostar a saída que my_print_defaults pode produzir quando quando pedido para mostrar as opções encontradas nos grupos [client] e [mysql]:

shell> my_print_defaults client mysql
--port=3306
--socket=/tmp/mysql.sock
--no-auto-rehash

Executando Múltiplos MariaDB Servers na Mesma Máquina

Executando Múltiplos Servidores no Windows
Executando Múltiplos Servidores no Unix
Usando Programas Clientes em um Ambiente Multi-Servidor

Em alguns casos você pode precisar de executar múltiplos servidores mysqld executando na mesma máquina. Você pode desejar testar uma nova versão do MariaDB enquanto a deixa a sua instalação da versão de produção existente sem perturbação. Ou você pode desejar dar acesso a diferentes usuários em diferentes servidores mysqld gerenciados por eles mesmos. (Por exemplo, você pode seu um provedor de serviços de internet que quer fornecer instalações independentes do MariaDB para clientes diferentes).

Para executar múltiplos servidores em uma única máquina, cada servidor deve ter valores únicos para diversos parâmetros operacionais. Isto deve ser configurado na linha de comando ou em arquivos de opções. Veja 'Opções de Linha de Comando do mysqld' e 'Arquivo de Opções my.cnf'.

Pelo menos as seguintes opções devem ser diferente para cada servidor:

--port controla o número da porta para conexões TCP/IP. --socket controla o caminho do arquivo de socket no Unix e o nome do named pipe no Windows. (É necessário nomes de pipes distintos no Windows apenas para aqueles servidores que suportam conexão named pipes.)

--shared-memory-base-name designa o nome da memória compartilhada por um servidor Windows para permitir que o cliente se conecte via memória compartilhada. --pid-file indice o nome do arquivo no qual o Unix gravar a ID do seu processo.

Se você usar as seguintes opções, elas deve ser diferentes para cada servidor:

Se você quiser mais desempenho, você também pode especificar as seguinte opções diferentemente para cada servidor para distribuir a carga entre vários discos físicos:

Normalmente, cada servidor também deve usar um diretório de dados diferentes, que é especificado usando a opção --datadir=path.

AVISO: Normalmente você nunca deve ter dois servidores que atualizam dados no mesmo banco de dados! Isto pode levar a supresas inesperadas se seu o seu sistema operacionalnão suporta lock de sistema a prova de falhas, isto pode provocar surpresas indesejáveis! Se (apesar deste aviso) você executar diversos servidores usando o mesmo diretório de dados e eles tiverem com o log habilitado, você usar as opções apropriadas para especificar os nomes dos arquivos de log que são únicos em cada servidor. Senão, o servidores podem tentar gravar no mesmo arquivo de log.

Este aviso contra o compartilhamento de arquivos de dados entre servidores também se aplica em um ambeinte NFS. Permitir vários servidores MariaDB acessarem um diretório de dados comum sobre NFS, é normalmente uma MÁ IDÉIA!

Facilite a sua vida: esqueça sobre compartilhar um diretório de dados entre servidores sobre NFS. A solução melhor é ter um computador com um sistema operacional que manipule threads de forma eficiente threads e tenha diversas CPUs nele.

Se você tiver múltiplas instalações do MariaDB em diferentes locais, normalemente você pode especificar o diretório de instalação base de cada servidor com a opção --basedir=caminho para fazer que cada servidor use diferentes diretórios de dados, arquivos de log e arquivos PID. (O padrão para todos estes valores são determinados em relação ao diretório base.) Neste caso, as únicas outras opções que você precisa especificar são as opções --socket e --port. Por exempo, suponha que você instalou a versão binária do MariaDB (arquivos .tar) em diferentes locais, assim você pode iniciar o servidor usando o comando ./bin/mysqld_safe sob o diretório base correspondente de cada instalação. mysqld_safe determinará a opção --basedir apropriada para passar para mysqld, e você precisa especificar apenas as opções --socket e --port para o mysqld_safe.

Como discutido nas seções a seguir, é possível iniciar servidores adicionais configurando variáveis de ambiente ou especificando as opções de linha de comando apropriada. No entanto, se você precisa executar múltiplos servidores em uma base mais permanente, será mais coonveniente usar os arquivos de opções para especificar, para cada servidor, aquelas opções que devem ser únicas para ele. Leia Seção 4.1.2, 'Arquivo de Opções my.cnf'.

Executando Múltiplos Servidores no Windows

Iniciando Múltiplos Servidores na Linha de Comando
Iniciando Múltiplos Servidores Como Serviços

Você pode executar múltiplos servidor no Windows iniciando-os manualmente a partir da linha de comando, cada um com o parâmetro operacional apropriado. Em sistemas baseados no Windows NT, você também tem a opção de instalar vários servidores como serviços Windows e executá-los deste modo. Instruções gerais sobre a execucão de servidores MariaDB a partir da linha de comando ou como serviços são dados em 'Notas Windows'. Esta seção descreve como se certificar de que você inicioou cada servidor com valores diferentes para aquelas opções de inicialização que devem ser unicas por servidor, como o diretório de dados. (Estas opções são descritas em 'Executando Múltiplos MariaDB Servers na Mesma Máquina'.)

Iniciando Múltiplos Servidores na Linha de Comando

Para iniciar vários servidores manualmente na linha de comando, você pode especificar a opção apropriada na linha de comando ou no arquivo de opções. É mais conveniente colocar as opções em um arquivo de opção. Para fazer isto, crie uma arquivo de opção para cada servidor e mostre ao servidor o nome do arquivo com a opção --defaults-file quando você executá-lo.

Suponha que você queira executar o mysqld na porta 3307 com um diretório de dados de C:\mydata1, e mysqld-max na porta 3308 com um diretório de dados de C:\mydata2. Para conseguir isto, crie dois arquivos de opções. Por exemplo, crie um arquivo chamado C:\my-opts1.cnf que se pareça com isto:

[mysqld]
datadir = C:/mydata1
port = 3307

Crie um segundo arquivo chamado C:\my-opts2.cnf que se pareça com isto:

[mysqld]
datadir = C:/mydata2
port = 3308

Então inicie cada servidor com seus próprios arquivos de opção:

shell> mysqld --defaults-file=C:\my-opts1.cnf
shell> mysqld-max --defaults-file=C:\my-opts2.cnf

(No NT, o servidor iniciará em segundo plano, assim você precisará enviar estes dois comandos em janelas de console separadas.)

Para desligar o servidor, você deve conectar a porta apropriada:

shell> mysqladmin --port=3307 shutdown
shell> mysqladmin --port=3308 shutdown

Servidores configurados como descrito permitirá que clientes se conectem por TCP/IP. Se você também quiser permitir conexões named pipe, use os servidores mysqld-nt ou mysqld-max-nt e especifique as opção que habilitem o named pipe e especifique os seus nomes. (Cada servidor que suporta conexões named pipes deve ter um nome único). Por exemplo, o arquivo C:\my-opts1.cnf pode ser escrito da seguinte maneira:

[mysqld]
datadir = C:/mydata1
port = 3307
enable-named-pipe socket = mypipe1

Estão inicie o servidor desta forma:

shell> mysqld-nt --defaults-file=C:\my-opts1.cnf

C:\my-opts2.cnf seria modificado de forma parecida para uso com o segundo servidor.

Iniciando Múltiplos Servidores Como Serviços

Em sistemas baseados no NT, um servidor MariaDB pode ser executado como um serviço Windows. O procedimento para instalação, controle e remoção de um único serviço MariaDB está descrito em 'Iniciando o MariaDB no Windows NT, 2000, ou XP'.

A partir do MariaDB 4.0.2, você pode instalar vários servidores como serviços. Neste caso, você deve ter certeza de que cada servidor usa um nome de serviço diferente junto com todos os outros parâmetros que devem ser único por servidor.

Para as seguintes instruções, assuma que você queira executar o servidor mysqld-nt a partir de duas versões diferentes do MariaDB que está instalado em C:\mysql-4.0.8 e C:\mysql-4.0.17, respectivamente. (Este pode ser o caso se você estiver executando a versão 4.0.8 como seu servidor de produção, mas queira testar o 4.0.17 antes de atualizá-lo.)

Os seguintes princípios são relevantes ao instalr um serviço MariaDB com a opção --install:

Este princípios também se aplicam se você intalar um servidor usando a opção --install-manual.

Baseado na informação anterior, você tem diversos de configurar vários serviços. As seguintes instruções descrevem alguns exemplos. Antes de tentar qualquer uma delas esteja certo de que você desligou e removeu qualquer serviço MariaDB existente primeiro.

Para remover vários serviços, use mysqld --remove para cada um, especificando um nome de serviço depois da opção --remove se o serviço a ser removido tiver um nome difertente do padrão.

Executando Múltiplos Servidores no Unix

O modo mais fácil de executar diversos servidores no Unix é compilá-los com diferentes portas TCP/IP e arquivos socket, assim cada um está escutando em diferentes interfaces de rede. Também, compilando em diferentes diretórios bases para instalação, que automaticamente resulta em diferentes localizações de diretórios de dados, arquivos log e arquivos PID para cada um dos seus servidores.

Considere que um servidor existente está configurado para a porta e arquivo socket padrões. Para configurar um novo servidor para ter parâmetros operacionais diferentes, use um comando configure assim:

shell> ./configure --with-tcp-port=port_number \
 --with-unix-socket-path=nome_arquivo \
 --prefix=/usr/local/mysql-4.0.17

Aqui número_porta e nome_arquivo deve ser diferente que o número da porta e o caminho do arquivo socket padrões e o valor --prefix deve especificar um diretório de instalação diferente daquele usado pelo servidor existente.

Você pode conferir o socket usado por qualquer servidor MariaDB em execução com este comando:

Se você tem um servidor MariaDB escutando em uma porta dada, você pode usar o seguinte comando para descobrir quaie parâmetros operacionais ele está usando para diversas variáveis importantes configuráveis, incluíndo o diretório base e o nome do socket:

shell> mysqladmin --host=host_name --port=port_number variables

Com a informação exibida por aquele comando, você pode dizer quais valores de opção não usar ao configurar um servidor adicional.

Note que se você especificar localhost como o nome da máquina, mysqladmin irá por padrão usar uma conexão sockets Unix em vez de TCP/IP. No MariaDB você também pode especificar o protocolo a ser usado com a opção --protocol={TCP | SOCKET | PIPE | MEMORY}.

Não é necessário compilar um novo servidor MariaDB apenas para iniciar com uma arquivo socket ou número de porta TCP/IP diferentes. Também é possível especificar estes valores em tempo de execução. Um modo de fazê-lo é usando as opções de linha de comando:

shell> /path/to/mysqld_safe --socket=file_name --port=port_number

Para usar outro diretório de banco de dados para o segundo servidor, passe uma opção --datadir=caminho para o mysqld_safe.

Um outro modo de conseguir este efeito é usar as variáveis de ambiente para configurar o nome do socket e o número da porta:

shell> MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
shell> MYSQL_TCP_PORT=3307
shell> export MYSQL_UNIX_PORT MYSQL_TCP_PORT
shell> scripts/mysql_install_db
shell> bin/mysqld_safe &

Este é um modo rápido para iniciar um segundo servidor para teste. O bom deste método é que a configuração das variáveis de ambiente se aplicarão a qualquer programa cliente que você chame da shell acima. Assim, as conexões para estes clientes serão automaticamente direcionadas para o segundo servidor!

Apêndice F, Variáveis de Ambientes do MariaDB inclue uma lista de outras variáveis de ambiente que você pode usar e que afetam o mysqld.

Para a execução automatica do servidor, seu script de inicialização que é executado no tempo de boot deve executar o seguinte comando uma vez para cada servidor com um caminmho apropriado do arquivo de opção para cada comando:

mysqld_safe --defaults-file=path-to-option-file

Cada arquivo de opção deve conter valores específicos para um dados servidor.

No Unix, o script mysqld_multi é outro modo de de iniciar vários servidores. Leia 'mysqld_multi, programa para gerenciar múltiplos servidores MySQL'.

Usando Programas Clientes em um Ambiente Multi-Servidor

Quando você quiser conectar com um programa cliente a um servidor MariaDB que está escutando diferentes interfaces de rede em vez daquelas compiladas em seu programa cliente, você pode conectar usando um dos seguintes métodos:

Detalhes Gerais de Segurança e o Sistema de Privilégio de Acesso do MariaDB

Segurança Geral
Como Tornar o MariaDB Seguro contra Crackers
Opções de Inicialização para o mysqld em Relação a Segurança.
Detalhes de Segurança com LOAD DATA LOCAL
O Que o Sistema de Privilégios Faz
Como o Sistema de Privilégios Funciona
Privilégios Fornecidos pelo MySQL
Conectando ao Servidor MySQL
Controle de Acesso, Estágio 1: Verificação da Conexão
Controle de Acesso, Estágio 2: Verificação da Requisição
Hashing de Senhas no MariaDB 4.1
Causas dos Erros de Accesso Negado

O MariaDB tem um sistema de segurança/privilégios avançado mas não padrão. A próxima seção descreve como ele funciona.

Segurança Geral

Qualquer um usando o MariaDB em um computador conectado à internet deve ler esta seção para evitar os erros de segurança mais comuns.

Discutindo segurança, nós enfatizamos a a necessidade de proteger completamente o servidor (não simplesmente o servidor MySQL) contra todos os tipos de ataques aplicáveis: eavesdropping, altering, playback e denial of service. Não cobriremos todos os aspectos de disponibilidade e tolerância a falhas aqui.

O MariaDB utiliza a segurança baseado em Listas de Controle de Acesso (ACL) para todas conexões, consultas e outras operações que um usuário pode tentar realizar. Existe também algum suporte para conexões criptografadasSSL entre clientes MariaDB e servidores. Vários dos conceitos discutidos aqui não são específicos do MariaDB; as mesmas idéias podem ser aplicadas para a maioria das aplicações.

Quando executando o MySQL, siga estes procedimentos sempre que possível:

Como Tornar o MariaDB Seguro contra Crackers

Quando você conectar a um servidor MySQL, você normalmente deve usar uma senha. A senha não é transmitida em texto puro sobre a conexão, porém o algorítimo de criptografica não é muito forte e com algum esforço um atacante engenhoso pode quebrar a senha se ele conseguir capturar o tráfego entre o cliente e o servidor. Se a conexão entre o cliente e o servidor passar por uma rede não confiável, você deve usar um tunnel SSH para criptografar a comunicação.

Todas outras informações são transferidas como texto que podem ser lido por qualquer um que consiga ver a conexão. Se você se preocupa com isto, você pode usar o protocol de compressão (No MariaDB versão 3.22 e superiores) para tornar o tráfico muito mais dificil de decifrar. Para deixar tudo ainda mais seguro você deve usar ssh. Você pode encontrar um cliente ssh open source em http://www.openssh.org, e um cliente ssh comercial em http://www.ssh.com. Com isto, você pode obter uma conexão TCP/IP critografada entre um servidor MariaDB e um cliente MySQL.

Se você estiver usando o MariaDB 4.0, você também pode usar o suporte interno OpenSSL Leia 'Usando Conexões Seguras'.

Para deixar um sistema MariaDB seguro, você deve considerar as seguintes sugestões:

Opções de Inicialização para o mysqld em Relação a Segurança.

As seguintes opções do mysqld afetam a segurança:

Detalhes de Segurança com LOAD DATA LOCAL

No MariaDB 3.23.49 e MariaDB 4.0.2 (4.0.13 no Windows), adicionamos algumas novas opções para lidar com possíveis detalhes de segurança junto ao LOAD DATA LOCAL.

Exstem dois problemas possíveis com o suporte a este comando:

Como a leitura deste arquivo é iniciada por um servidor, pode-se teoricamente criar um servidor MariaDB corrigido que poderia ler qualquer arquivo na máquina cliente na qual o usuário atual tenha acesso, quando o cliente envia uma consulta a tabela.

Em um ambiente web onde os clientes estão conectados a um servidor web, um usuário poderia usar LOAD DATA LOCAL para ler qualquer arquivo no qual o processo do servidor web tenha acesso de leitura (assumindo que um usuário poderia executar qualquer comando no servidor SQL).

Existem dois arquivos separados para isto:

Se você não configurar o MariaDB com --enable-local-infile, então LOAD DATA LOCAL será disabilitado por todos os clientes, a menos que se chame mysql_options(... MYSQL_OPT_LOCAL_INFILE, 0) no cliente. Leia Seção 12.1.3.40, 'mysql_options()'.

Para o cliente de linha de comando MariaDB, LOAD DATA LOCAL pode ser habilitado especificado a opção --local-infile[=1], ou disabilitando com --local-infile=0.

Por padrão, todos os clientes e bibliotacas MariaDB são compilados com --enable-local-infile, para ser compatível com o MariaDB 3.23.48 e anterior.

Pode se desabilitar todos os comandos LOAD DATA LOCAL no servidor MariaDB iniciando o mysqld com --local-infile=0.

No caso em que LOAD DATA LOCAL INFILE está disabilitado no servidor ou no cliente, você receberá a seguinte mensagem de erro (1148):

The used command is not allowed with this MariaDB version

O Que o Sistema de Privilégios Faz

A função primária do sistema de privilégios do MariaDB é autenticar um usuário a partir de uma determinada máquina e associar este usuário com privilégios a banco de dados como como select, insert, update e delete.

Funcionalidades adicionais incluem a habilidade de ter um usuário anônimo e conceder privilégio para funções específicas do MariaDB como em LOAD DATA INFILE e operações administrativas.

Como o Sistema de Privilégios Funciona

O sistema de privilégios do MariaDB garante que todos usuários possam fazer exatamente as operações que lhe é permitido. Quando você conecta a um servidor MySQL, sua identidade é determinada pela maquina de onde você conectou e o nome de usuário que você especificou. O sistema concede privilégios de acordo com sua identidade e com o que você deseja fazer.

O MariaDB considera tanto os nomes de máquinas como os nomes de usuários porque existem poucas razões para assumir que um determinado nome de usuário pertence a mesma pessoa em todo lugar na Internet. Por exemplo, o usuário bill que conecta de whitehouse.gov não deve necessariamente ser a mesma pessoa que o usuário bill que conecta da microsoft.com O MariaDB lida com isto, permitindo a distinção de usuários em diferentes máquinas que podem ter o mesmo nome: Você pode conceder a bill um conjunto de privilégios para conexões de whitehouse.gov e um conjunto diferente de privilégios para conexões de microsoft.com.

O controle de acesso do MariaDB é composto de dois estágios:

Note que se os seus privilégios são alterados (tanto por você quanto por outro) enquanto você está conectado, estas alterações não irão necessariamente ter efeito com a sus próxima consulta ou consultas. Veja 'Quando as Alterações nos Privilégios tem Efeito' para maiores detalhes.

O servidor utiliza as tabelas user, db e host no banco de dados MariaDB em ambos estágios do controle de acesso. Os campos nestas tabelas de permissão são detalhados abaixo:

Nome da Tabela user db host
Campos de Escopo Host Host Host
User Db Db
Password User
Campos de Privilégio Select_priv Select_priv Select_priv
Insert_priv Insert_priv Insert_priv
Update_priv Update_priv Update_priv
Delete_priv Delete_priv Delete_priv
Index_priv Index_priv Index_priv
Alter_priv Alter_priv Alter_priv
Create_priv Create_priv Create_priv
Drop_priv Drop_priv Drop_priv
Grant_priv Grant_priv Grant_priv
References_priv References_priv References_priv
Reload_priv
Shutdown_priv
Process_priv
File_priv
Show_db_priv
Super_priv
Create_tmp_table_priv Create_tmp_table_priv Create_tmp_table_priv
Lock_tables_priv Lock_tables_priv Lock_tables_priv
Execute_priv
Repl_slave_priv
Repl_client_priv
ssl_type
ssl_cypher
x509_issuer
x509_cubject
max_questions
max_updates
max_connections

No segundo estágio do controle de acesso (verificação da solicitação), o servidor pode, se a solicitação involver tabelas, consultar adicionalmente as tabelas tables_priv e columns_priv. Os campos nestas tabelas são mostrados abaixo:

Nome da tabela tables_priv columns_priv
Campos de escopop Host Host
Db Db
User User
Table_name Table_name
Column_name
Campos de privilégio Table_priv Column_priv
Column_priv
Outros campos Timestamp Timestamp
Grantor

Cada tabela de permissões contêm campos de escopo e campos de privilégios.

Campos de escopo determinam o escopo de cada entrada nas tabelas, isto é, o contexto no qual a entrada se aplica. Por exemplo, uma entrada na tabela user com valores Host e User de 'thomas.loc.gov' e 'bob' devem ser usados para autenticar conexões feitas ao servidor por bob da máquina thomas.loc.gov. De maneira similar, uma entrada na tabela db com campos Host, User e Db de 'thomas.loc.gov', 'bob' e 'reports' devem ser usados quando bob conecta da máquina thomas.loc.gov para acessar o banco de dados reports. As tabelas tables_priv e columns_priv contem campos de escopo indicando as combinações de tabelas ou tabela/coluna para o qual cada entrada se aplica.

Para propósitos de verificação de acessos, comparações de valores Host são caso insensitivo, valores User, Password, Db e Table_name são caso sensitivo. Valores Column_name são caso insensitivo no MariaDB versão 3.22.12 ou posterior.

Campos de privilégios indicam os privilégios concedidos por uma entrada na tabela, isto é, quais operações podem ser realizadas. O servidor combina as informações de várias tabelas de concessão para formar uma descrição completa dos privilégios de um usuário. As regras usadas para fazer isto são descritas em 'Controle de Acesso, Estágio 2: Verificação da Requisição'.

Campos de escopo são strings, declaradas como mostrado abaixo; os valores padrão para cada é a string vazia:

Nome do Campo Tipo
Host CHAR(60)
User CHAR(16)
Password CHAR(16)
Db CHAR(64) (CHAR(60) para as tabelas tables_priv e columns_priv)
Table_name CHAR(60)
Column_name CHAR(60)

Nas tabelas user, db e host, todos campos de privilégios são declarados como ENUM('N','Y') --- cada um pode ter um valor de 'N' ou 'Y' e o valor padrão é 'N'.

Nas tabelas tables_ e columns_priv, os campos de privilégios são declarados como campos SET:

Nome de tabela Nome do campo Possíveis elementos do conjunto
tables_priv Table_priv 'Select', 'Insert', 'Update', 'Delete', 'Create', 'Drop', 'Grant', 'References', 'Index', 'Alter'
tables_priv Column_priv 'Select', 'Insert', 'Update', 'References'
columns_priv Column_priv 'Select', 'Insert', 'Update', 'References'

De maneira resumida, o servidor utiliza as tabelas de permissões desta forma:

Perceba que os privilégios administrativos (RELOAD, SHUTDOWN e etc) são especificados somente na tabela user. Isto ocorre porque operações administrativas são operações no próprio servidor e não são específicas e não específicas dos bancos de dados, portanto não existe razão para listar tais privilégios nas outras tabelas de permissão. De fato, somente a tabela user necessita ser consultada para determinar se você pode ou não realizar uma operação administrativa.

O privilégio FILE também só é especificado na tabela user. Ele não é um privilégio administrativo, mas sua habilidade para ler ou escrever arquivo no servidor é independtende do banco de dados que você está acessando.

O servidor mysqld le o conteúdo das tabelas de permissões uma vez, quando é iniciado. Alterações nas tabelas de permissões tem efeito como indicado em 'Quando as Alterações nos Privilégios tem Efeito'.

Quando você modifica o conteúdo das tabelas de permissões, é uma boa idéia ter certeza que suas alterações configuraram os privilégios da forma desejada. Para ajuda no diagnostico de problemas, veja 'Causas dos Erros de Accesso Negado'. Para conselhos sobre asssuntos de segurança, Leia 'Como Tornar o MariaDB Seguro contra Crackers'.

Uma ferramenta de diagnóstico útil é o script mysqlaccess, que Yves Carlier fornece na distribuição MariaDB. Chame mysqlaccess com a opção --help para descobrir como ele funciona. Perceba que o mysqlaccess confere o acesso usando somente as tabelas user, db e host. Ele não confere privilégios no nível de tabelas ou colunas.

Privilégios Fornecidos pelo MariaDB

Informações sobre privilégios de usuários são armazenados nas tabelas user, db, host, tables_priv e columns_priv no banco de dados chamado MariaDB. O servidor MariaDB lê o conteúdo destas tabelas quando ele inicia e sob as circunstâncias indicadas em 'Quando as Alterações nos Privilégios tem Efeito'.

Os nomes usados neste manual que se referem-se aos privilégios fornecidos pelo MariaDB são vistos abaixo juntos com o nome da coluna associada com cada privilégio nas tabelas de permissão e o contexto em que o privilégio se aplica. Informações adicionais sobre o significado de cada privilégio pode ser encontrado em 'A Sintaxe de GRANT e REVOKE'.

Privilégio Coluna Contexto
ALTER Alter_priv tabelas
DELETE Delete_priv tabelas
INDEX Index_priv tabelas
INSERT Insert_priv tabelas
SELECT Select_priv tabelas
UPDATE Update_priv tabelas
CREATE Create_priv banco de dados, tabelas, ou índices
DROP Drop_priv banco de dados ou tabelas
GRANT Grant_priv banco de dados ou tabelas
REFERENCES References_priv banco de dados ou tabelas
CREATE TEMPORARY TABLES Create_tmp_tabela_priv administração do servidor
EXECUTE Execute_priv administração do servidor
FILE File_priv acessa a arquivos no servidor
LOCK TABLES Lock_tabelas_priv administração do servidor
PROCESS Process_priv administração do servidor
RELOAD Reload_priv administração do servidor
REPLICATION CLIENT Repl_client_priv administração do servidor
REPLICATION SLAVE Repl_slave_priv administração do servidor
SHOW DATABASES Show_db_priv administração do servidor
SHUTDOWN Shutdown_priv administração do servidor
SUPER Super_priv administração do servidor

Os priviláegios SELECT, INSERT, UPDATE e DELETE permitem realizar operações em registros nas tabelas existentes em um banco de dados.

Instruções SELECT necessitam do privilégio select somente se ele precisar recuperar registros de uma tabela. Você pode executar certas instruções SELECT mesmo sem permissão para acessar algum dos bancos de dados no servidor. Por exemplo, você pode usar o cliente MariaDB como uma simples calculadora:

mysql> SELECT 1+1;
mysql> SELECT PI()*2;

O privilégio INDEX permite a criação ou remoção de índices.

O privilégio ALTER permite utilizar ALTER TABLE.

Os privilégios CREATE e DROP permitem a criação de novos bancos de dados e tabelas, ou a remoção de bancos de dados e tabelas existentes.

Perceba que se for concedido o privilégio DROP no banco de dados MariaDB para algum usuário, este usuário pode remover o banco de dados no qual os privilégios de acesso do MariaDB estão armazenados!

O privilégio GRANT permite a você fornecer a outros usuários os privilégios que você mesmo possui.

O privilégio FILE fornece permissão para ler e escrever arquivos no servidor usando instruções LOAD DATA INFILE e SELECT ... INTO OUTFILE. Qualquer usuário que tenha este privilégio pode ler ou gravar qualquer arquivo que o servidor MariaDB possa ler ou escrever. O usuário também pode ler qualquer arquivo no diretório de banco de dados atual. O usuário não pode, no entanto, alterar qualquer arquivo existente.

Os privilégios restantes são usados para operações administrativas, que são realizadas utilizando o programa mysqladmin. A tabela abaixo mostra quais comandos do mysqladmin cada privilégio administrativos permite a execução:

Privilégio Comandos permitidos
RELOAD reload, refresh, flush-privileges, flush-hosts, flush-logs, and flush-tables
SHUTDOWN shutdown
PROCESS processlist
SUPER kill

O comando reload diz ao servidor para recarregar as tabelas de permissões. O comando refresh descarrega todas as tabelas e abre e fecha os arquivos de log. flush-privileges é um sinônimo para reload. Os outros comandos flush-* realizam funções similares ao refresh mas são mais limitados no escopo e podem ser preferíveis em alguns casos. Por exemplo, se você deseja descarregar apenas os arquivos log, flush-logs é uma melhor escolha do que refresh.

O comando shutdown desliga o servidor.

O comando processlist mostra informações sobre as threads em execução no servidor. O comando kill mata threads no servidor. Você sempre poderá mostrar ou matar suas próprias threads, mas você precisa do privilégio PROCESS para mostrar e privilégio SUPER para matar threads iniciadas por outros usuários. Leia 'Sintaxe de KILL'.

É uma boa idéia em geral conceder privilégios somente para aqueles usuários que necessitem deles, mas você deve ter muito cuidado ao conceder certos privilégios:

Existema algumas coisas que você não pode fazer com o sistem de privilégios do MariaDB:

Conectando ao Servidor MariaDB

Programas clientes do MariaDB geralmente necessitam de parâmetros de conexão quando você precisar acessar um servidor MySQL: a máquina na qual você deseja se conectar, seu nome de usuário e sua senha. Por exemplo, o cliente MariaDB pode ser iniciado desta forma (argumentos opcionais são colocandos entre '[' e ']'):

shell> mysql [-h nome_máquina] [-u nome_usuário] [-psua_senha]

Formas alternativas das opções -h, -u e -p são --host=nome_máquina, --user=nome_usuário e --password=sua_senha. Perceba que não existe espaço entre -p ou --password= e a senha que deve vir a seguir.

NOTA: Especificar a senha na linha de comando não é seguro! Qualquer usuário no seus sistema pode saber sua senha digitando um comando do tipo: ps auxww. Leia 'Arquivo de Opções my.cnf'.

O MariaDB utiliza valores padrão para parâmetros de conexão que não são passados pela linha de comando:

Então, para um usuário Unix joe, os seguintes comandos são equivalentes:

shell> mysql -h localhost -u joe
shell> mysql -h localhost
shell> mysql -u joe
shell> MariaDB

Outros clientes MariaDB comportam-se de forma similar.

Em sistemas Unix, você pode especificar valores padrões diferentes para serem usados quendo você faz uma conexão, assim você não precisa digitá-los na linha de comando sempre que chamar o programa cliente. Isto pode ser feito de várias maneiras:

Controle de Acesso, Estágio 1: Verificação da Conexão

Quando você tenta se conectar a um servidor MySQL, o servidor aceita ou rejeita a conexão baseado na sua identidade e se pode ou não verificar sua identidade fornecendo a senha correta. Senão, o servidor nega o acesso a você completamente. De outra forma, o servidor aceita a conexão, entra no estágio 2 e espera por requisiçiões.

Sua identidade é baseada em duas partes de informação:

A conferência da identidade é feita utilizando os tres campos de escopo da tabela user (Host, User e Password). O servidor aceita a conexão somente se uma entrada na tabela user coincidir com a máquina, nome de usuário e a senha fornecidos.

Valores dos campos escopo na tabela user podem ser especificados como segue:

Valores de Password que não estão em branco são apresentados como senhas criptografadas. O MariaDB não armazena senhas na forma de texto puro para qualquer um ver. Em vez disso, a senha fornecida por um usuário que está tentando se conectar é criptografada (utilizando a função PASSWORD()). A senha criptografada é então usada quando o cliente/servidor estiver conferindo se a senha é correta (Isto é feito sem a senha criptografada sempre trafegando sobre a conexão.) Perceba que do ponto de vista do MariaDB a senha criptografada é a senha REAL, portanto você não deve passá-la para ninguém! Em particular, não forneça a usuários normais acesso de leitura para as tabelas no banco de dados MariaDB! A partir da versão 4.1, o MariaDB emprega um mecanismo de senha e login diferente que é seguro mesmo se fizerem um sniff nos pacotes TCP/IP e/ou o Banco de Dados MariaDB é capturado.

Os exemplos abaixo mostram várias combinações de valores de Host e User nos registros da tabela user aplicando a novas conexões:

Valor em host Valor em user Conexões casadas com o registro
'thomas.loc.gov' '' Qualquer usuário, conectando de thomas.loc.gov
'%' 'fred' fred, conectando a partir de qualquer máquina
'%' '' Qualquer usuário, conectando a partir de qualquer máquina
'%.loc.gov' 'fred' fred, conectando de qualquer máquina do domínio loc.gov
'x.y.%' 'fred' fred, conectando de x.y.net, x.y.com,x.y.edu, etc. (Isto provavelmente não é útil)
'144.155.166.177' 'fred' fred, conectando da máquina com endereço IP 144.155.166.177
'144.155.166.%' 'fred' fred, conectando de qualquer máquina na subrede de classe C 144.155.166
'144.155.166.0/255.255.255.0' 'fred' o mesmo que no exemplo anterior

Como você pode usar valores coringas de IP no campo Host (por exemplo, '144.155.166.%' combina com todas máquinas em uma subrede), existe a possibilidade que alguém possa tentar explorar esta capacidade nomeando a máquina como 144.155.166.algumlugar.com. Para evitar tais tentativas, O MariaDB desabilita a combinação com nomes de máquina que iniciam com dígitos e um ponto. Portanto se você possui uma máquina nomeada como 1.2.foo.com, este nome nunca irá combinar com uma coluna Host das tabelas de permissões. Somente um número IP pode combinar com um valor coringa de IP.

Uma conexão de entrada pode coincidir com mais de uma entrada na tabela user. Por exemplo, uma conexão a partir de thomas.loc.gov pelo usuário fred pode combinar com diversas das entradas vistas na tabela anterior. Como o servidor escolhe qual entrada usar se mais de uma coincide? O servidor resolve esta questão ordenando a tabela user no tempo de inicialização, depois procura pelas entradas na ordem da classificação quando um usuário tenta se conectar. A primeira entrada que coincidir é a que será usada.

A ordenação da tabela user funciona da forma mostrada a seguir. Suponha que a tabela user se pareça com isto:

+-----------+----------+-
| Host | User | ...
+-----------+----------+-
| % | root | ...
| % | jeffrey | ...
| localhost | root | ...
| localhost | | ...
+-----------+----------+-

Quando o servidor lê a tabela, ele ordena as entradas com os valores mais específicos de Host primeiro ('%' na coluna Host significa qualquer máquina e é menos específico). Entradas com o mesmo valor Host são ordenadas com os valores mais específicos de User primeiro (um valor em branco na coluna User significa qualquer usuário e é menos específico). O resultado da tabela user ordenada ficaria assim:

+-----------+----------+-
| Host | User | ...
+-----------+----------+-
| localhost | root | ...
| localhost | | ...
| % | jeffrey | ...
| % | root | ...
+-----------+----------+-

Quando uma conexão é iniciada, o servidor procura entre as entradas ordenadas e utiliza a primeira entrada coincidente. Para uma conexão a partir de localhost feito por jeffrey, as entradas com 'localhost' na coluna Host coincide primeiro. Destas, a entrada com o nome do usuário em branco combina com o nome da máquina e o nome do usuário. (A entrada '%'/'jeffrey' também casaria, mas ela não é a primeira entrada coincidente na tabela.

Aqui está outro exemplo. Suponha que a tabela user fosse assim:

+----------------+----------+-
| Host | User | ...
+----------------+----------+-
| % | jeffrey | ...
| thomas.loc.gov | | ...
+----------------+----------+-

A tabela ordenada pareceria com isto:

+----------------+----------+-
| Host | User | ...
+----------------+----------+-
| thomas.loc.gov | | ...
| % | jeffrey | ...
+----------------+----------+-

Uma conexão a partir de thomas.loc.gov feita por jeffrey coincide com a primeira entrada, no entanto, uma conexão de whitehouse.gov fetia por jeffrey coincidiria com a segunda entrada na tabela.

Um erro comum é pensar que para um determinado usuário, todas as entradas que citam explicitamente este usuário serão usadas primeiro quando o usuário tentar encontrar uma combinação para a conexão. Simplesmente isto não é verdade. O exemplo anterior ilustra isto, onde uma conexão de thomas.loc.gov feita por jeffrey combina primeiro não com a entrada contendo 'jeffrey' no valor do campo user, mas sim pela entrada sem o nome de usuário!

Se você tiver problemas conectando ao servidor, imprima a tabela user e ordene-a na manualmente para ver onde se deu o primeiro coincidência de valores. Se a conexão obtiver sucesso mas os seus privilégios não são os esperados, você pode usar a função CURRENT_USER() (nova na versão 4.0.6) para ver com qual combinação usuário/máquina a sua conexão coincide. Leia 'Funções Diversas'.

Controle de Acesso, Estágio 2: Verificação da Requisição

Uma vez estabelecida uma conexão, o servidor entra no 2o estágio. Para cada requisição que vem na conexão, o servidor verifica se você tem privilégios suficientes para realizá-la, baseado nas operações que você deseja fazer. É aqui que os campos de concessões nas tabelas de permissões entram em ação. Estes privilégios pode vir de qualquer uma das tabelas user, db, host, tables_priv ou columns_priv. As tabelas de permissões são manipuladas com os comandos GRANT e REVOKE. Leia 'A Sintaxe de GRANT e REVOKE'. (Você pode achar útil fazer referencia a 'Como o Sistema de Privilégios Funciona', que lista os campos presentes em cada uma das tabelas de permissões.)

A tabela user concede privilégios que são especificados por você em uma base global e que se aplicam sem importar qual é o banco de dados atual. Por exemplo, se a tabela user concede a alguém o privilégio delete, este usuário pode apagar linhas de qualquer banco de dados no servidor! Em outras palavras, privilégios na tabela user são privilégios de superusuário. O correto é conceder privilégios na tabela user apenas para superusuários tais como os administradores de servidor ou de bancos de dados. Para outros usuários, você deve deixar os privilégios na tabela user configurados para 'N' e conceder privilégios somente em bancos de dados específicos, utilizando as tabelas db e host.

As tabelas db e host concedem privilégios para bancos de dados específicos. Valores nos campos de escopo podem ser especificados como a seguir:

As tabelas db e host são lidas e ordenadas quando o servidor inicia (ao mesmo tempo que ele lê a tabela user). A tabela db é ordenada nos campos de escopo Host, Db e User e a tabela host é ordenada nos campos de escopo Host e Db. Assim como na tabela user, a ordenação coloca os valores mais específicos no início e os menos específicos por último, e quando o servidor procura por entradas coincidentes, ele usa a primeira combinação que encontrar.

As tabelas tables_priv e columns_priv concedem privilégios específicos para tabelas e campos. Valores nos campos escopo podem ser especificados como a seguir:

As tabelas tables_priv e columns_priv são ordenadas nos campos Host, DB e User. Isto é parecido com a ordenação da tabela db, no entanto, a ordenação é mais simples porque somente o campo Host pode conter meta caracteres.

O processo de verificação da requisição é descrito abaixo. (Se você já está familiarizado com o código de verificação de acesso, você irá perceber que a descrição aqui é um pouco diferente do algorítimo usado no código. A descrição é equivalente ao que o código realmente faz; ele só é diferente para tornar a explicação mais simples.)

Para requisições administrativas (SHUTDOWN, RELOAD, etc.), o servidor confere somente a entrada da tabela user, porque ela é a única tabela que especifica privilégios administrativos. O acesso é concedido se o registro permitir a operação requisitada ou negado caso o contrário. Por exemplo, se você deseja executar mysqladmin shutdown mas a entrada em sua tabela user não lhe concede o privilégio SHUTDOWN, o acesso é negado mesmo sem consultar as tabelas db ou host. (elas não contém o campo Shutdown_priv, portanto não existe esta necessidade.)

Para requisições relacionadas aos bancos de dados (insert, udpdate, etc.), o servidor primeiro confere os privilégios globais do usuário consultando as entradas da tabela user. Se a entrada permitir a operação requisitada, o acesso é concedido. Se os privilégios globais na tabela user são insuficientes, o servidor determina os privilégios específicos de banco de dados para o usuário consultando as tabelas db e host:

  1. O servidor consulta a tabela db por uma combinação nos campos Host, Db e User. Os campos Host e User são comparados com o nome da máquina e o nome do usuário que faz a requisição. O campo Db é comparado com o banco de dados que o usuário deseja acessar. Se não existir entradas coincidentes para o Host e User, o acesso é negado.
  2. Se existir uma combincação com a entrada da tabela db e seu campo Host não estiver em branco, aquela entrada define os privilégios especificos do banco de dados do usuario.
  3. Se o registro coincidente da tabela db tiver o campo Host em branco, significa que a tabela host enumera quais máquinas são permitidas acessar o banco de dados. Neste caso, uma consulta adicional é feita na tabela host para encontrar uma valores coincidentes nos campos Host e Db. Se nenhuma entrada na tabela host coincide, o acesso é negado. Se existir uma coincidência, os privilégios específicos de bancos de dados para o usuário são computados como a interseção (não a união!) dos privilégios nas entradas das tabelas db e host, isto é, os privilégios que são 'Y' em ambas entradas. (Desta forma você pode conceder privilégios gerais em entradas na tabela db e então restringi-los em uma base de máquina a máquina utilizando as entradas da tabela host.)

Depois de determinar os privilégios específicos do banco de dados concedido pelas entradas nas tabelas db e host, o servidor os adiciona aos privilégios globais concedidos pela tabela user. Se o resultado permitir a operação requisitada, o acesso será concedido. De outra forma, o servidor consulta os privilégios de tabelas e campos do usuario nas tabelas tables_priv e columns_priv e os adiciona aos privilégios do usuário. O acesso será permitido ou negado baseado no resultado.

Expresso em termos booleanos, a descrição precedente de como os privilégios de um usuário são calculados podem ser resumido assim:

global privileges OR (database privileges AND host privileges)
OR table privileges OR column privileges

Ele pode não ser aparente porque, se os privilégios da entrada global de user são inicialmente insuficientes para a operação requisitada, o servidor adiciona estes privilégios mais tarde aos privilégios específicos de banco de dados, tabelas e colunas. A razão é que uma requisição pode exigir mais que um tipo de privilégio. Por exemplo, se você executar uma instrução INSERT ... SELECT, você precisa dos privilégios INSERT e SELECT. Seu privilégio pode ser tal que a entrada da tabela user concede um privilégio e a entrada da tabela db concede o outro. Neste caso, você tem os privilégios necessários para realizar a requisição, mas o servidor não pode obtê-los de ambas as tabelas por si próprio; os privilégios concedidos pelas entradas em ambas as tabelas de ser combinados.

A tabela host pode ser usada para manter uma lista dos servidores seguros.

Na Tcx, a tabela host contém uma lista de todas as máquina na rede local. A elas são concedidos todos os privilégios.

Você pode também usar a tabela host para indicar máquinas que não são seguras. Suponha que você tenha uma máquina public.your.domain que está localizada em uma área pública que você não considera segura. Você pode permitir o acesso a todas as máquinas de sua rede exceto a esta máquina usando entradas na tabela host desta forma:

+--------------------+----+-
| Host | Db | ...
+--------------------+----+-
| public.your.domain | % | ... (todos os privilégios configurados para 'N')
| %.your.domain | % | ... (todos os privilégios configurados para 'Y')
+--------------------+----+-

Naturalmente, você deve sempre testar suas entradas nas tabelas de permissões (por exemplo, usar o mysqlaccess para ter certeza que os privilégios de acesso estão atualmente configurados da forma que você imagina.

Hashing de Senhas no MariaDB 4.1

As contas de usuários do MariaDB estão lisatadas na tabela user do banco de dados MariaDB. Para cada conta do MariaDB é definida uma senha, no entanto o que está armazenado na coluna Password da tabela user não seja uma versão da senha em texto puro, mas um valor hash computado para ela. Valores hash de senha são calculados pela função PASSWORD().

O MariaDB usa senhas em duas fases da comunicação cliente/servidor:

Em outra palavras, o servidor usa valores hash durante a autenticação quando um cliente tenta a primeira conexão. O servidor gera os valores hash se um cliente conectado chama a função PASSWORD() ou usa uma instrução GRANT ou SET PASSWORD para definir ou alterar uma senha.

O mecanismo de hash da senha foi atualizado no MariaDB para fornecer melhor segurança e reduzir os riscos de senhas serem roubadas. No entanto, Este novo mecanismo só é interpretado pelo servidor 4.1 e clientes 4.1, que podem resultar em alguns problemas de compatibilidade. Um cliente 4.1 pode conectar a um servidor pre-4.1, porque o cliente entende tanto o antigo quanto o novo mecanismo hash de senha. No entanto, um cliente pre-4.1 que tentar se conectar a um servidor 4.1 pode encontrar dificuldades. Por exemplo, um cliente MariaDB 4.0 que tentar se conectar a um servidor 4.1 pode falhar com a seguinte mensagem de erro:

shell> MariaDB
Client does not support authentication protocol requested by server; consider upgrading MariaDB client

A seguinte discussão descreve a diferença entre o antigo e o novo mecanismo de senha, e o que você deve fazer se você atualizar o seu servidor para a versão 4.1 mas precizar de manter compatibilidade com clientes pre-4.1.

Nota: Esta discussão contrasta no comportamento da versão 4.1 com o comportamento da pre-4.1, mas o da versão 4.1 descrito aqui começa relamente na versão 4.1.1. O MariaDB é uma distribuição disferente porque ela tem um mecanismo um pouco diferente daquele implementado na 4.1.1 e acima. Diferenças entre a versão 4.1.0 e as versões mais recentes são descritas posteriormente.

Antes do MariaDB, o hash de senha calculado pela função PASSWORD() tem tamanho de 16 bytes. Este hash se parece com:

mysql> SELECT PASSWORD('mypass');
+--------------------+
| PASSWORD('mypass') |
+--------------------+
| 6f8c114b58f2ce9e |
+--------------------+

A coluna Password da tabela user (na qual estes hashes são armazenados) também têm 16 bytes de tamanho antes do MariaDB 4.1.

A partir do MariaDB, a função PASSWORD() foi modificada para produzir um valor hash de 41 bytes.

mysql> SELECT PASSWORD('mypass');
+-----------------------------------------------+
| PASSWORD('mypass') |
+-----------------------------------------------+
| *43c8aa34cdc98eddd3de1fe9a9c2c2a9f92bb2098d75 |
+-----------------------------------------------+

De acordo com o mostrado, a coluna Password na tabela user também deve ter 41 bytes para armazeanar estes valores.

Uma coluna Password mais larga pode armazenar hashes de senha no formato novo e no antigo. O formato de qualquer valor de hash de senha dado podeser determinado de dois modos:

O formato maior do hash de senha tetm melhores propriedades criptográficas, e a autenticação do cliente baseada em hashs mais longos é mais segura que aquela baseada nos antigos hashes menores.

A diferença entre os hashs de senhas menores e maiores são relevantes em como o servidor usa as senhas durante a autenticação e como ela gera hash de senhas para clientes conectados que realizam operações de alteração de senha.

O modo no qual o servidor usa o hash de senha durante a autenticação é afetada pela largura da coluna Password:

Para contas com o hash curto, o processo de autenticação é na verdade um pouco mais seguro para clientes 4.1 que para clientes mais antigos. Em termos de segurança, o gradiente do menos para o mais seguro é:

O modo no qual o servidor gera hashes de senhas para clientes conectados é afetado pela largura da coluna Password e pela opção --old-passwords. Um servidor 4.1 gera hashes longos apenas se certas condicões forem encontradas: A coluna Password deve ser grande o suficiente para armazenar valores longos e a opção --old-passwords não deve ser dada. Estas condições se aplicam da seguinte forma:

O propósito da opção --old-passwords é permitir que você mantenha compatibilidade com clientes com versões anteriores à 4.1 sob circunstâncias nas quais os servidores gerariam hashes de senha longos. Ele não afeta a autenticação (clientes 4.1 podem ainda usar contas que possuem hash de senha longo), mas ele não previne a criaçõa de um hash de senha longo na tabela user como resultado de uma operação de troca de senha. Onde isto ocorrer, a conta não mais poderá ser usada por clientes pré-4.1. Se a opção --old-passwords, o seguinte cenário é possível:

Este cenário mostra que é perigoso executar um servidor 4.1 sem usar a opção --old-passwords, operações de alteração de senha não irão gerar hashes de senha longos e assim não faz com que as contas se tornem inacessíveis para clientes mais antigos. (Estes clientes não podem bloquear eles mesmos inadivertidamente alterando suas senhas e ficando com um hash de senha longo.

A desvantagem da opção --old-passwords é que qualquer senha que você criar ou alterar usará hashes curtos, mesmo para clientes 4.1. Assim, você perde a segurança adicional fornecida pelos hashes de senha longos. Se você quiser criar uma conta qye tenha um hash longo (por exemplom parr uso pelos clientes 4.1), você deve fazê-lo enquanto executa o servidor sem a opção --old-passwords.

Os seguintes cenários são possíveis para executar um servidor 4.1:

Cenario 1) Coluna Password menor na tabela de usuários

Cenário 2) Colunas Password longas; servidor não iniciado com a opção --old-passwords

Como indicado anteriormente, o perigoso neste cenário é que é possível que contas com hashes de senha curtos se tornem inacessíveis para cliente anteriores ao 4.1. Qualquer alteração a senha de uma conta feita via GRANT, SET PASSWORD, ou PASSWORD() faz com que a conta tenha um hash de senha longo, e a partir deste ponto, nenhum cliente anterior ao 4.1 poderá autenticar esta conta até que ele seja atualizado para a versão 4.1.

Cenário 3) Coluna Password longa; servidor iniciado com a opção --old-passwords

Neste cenário, você não pode criar contas que tenham hashes de senha longo, porque --old-passwords previne a criação de hashes longos. Também, se você criar uma conta com um hash longo antes de usar a opção --old-passwords, alterar a senha da conta enquanto --old-passwords está funcionando faz com que seja dada a conta uma sena curta, fazendo com que ela perca os benefícios de segurança de um hash longo.

As disvantagens para este cenário pode ser resumido como a seguir:

Cenário 1) Você não pode tirar vantagem do hash longo que fornece mais autenticação segura.

Cenário 2) Contas com hashes curtos tornam clientes anteriores ao 4.1 inacessíveis se você alterar a senha deles sem usar OLD_PASSWORD() explicitamente.

Cenário 3) --old-passwords evita que as contas com hashes curtos se tornem inacessíveis, mas operações de alteração de senhas fazem com que as contas com hashes longos seja revertida para hashes curtos, e você não pode alterá-las de volta para hashes longos enquanto --old-passwords está em efeito.

Implicações de Alteração de Hashes de Senha para Aplicativos

Um atualização para o MariaDB para trazer problemas de compatibilidade para aplicações que usam PASSWORD() para gerar senha para os seus próprios propósitos. (Aplicativos não devem fazer isto, porque PASSWORD() deve ser usado paenas para gerenciar contas do MariaDB. Mas algumas aplicações usam PASSWORD() para seus próprios propósitos.) Se você atualizar para o MariaDB e executar o servidor sob condições onde ele gera hashes de senha longo, uma aplicação que usa PASSWORD() para as suas próprias senhas irá falhar. O curso de ação recomendado é modificar o aplicativo para usar outras funções como SHA1() ou MD5() para produzir valores de hash. Se isto não for possível você pode utilizar a função OLD_PASSWORD(), que é fornecida para gerar hashes curtos no formato antigo. (Mas note que OLD_PASSWORD() pode vir a não ser mais suportado.)

Se o servidor está rodando sob circuntâncias onde ele gera hashes de senha curtos, OLD_PASSWORD() está disponível mas é equivalente a PASSWORD().

Hash de senhas no MariaDB 4.1.0 difere do hash no 4.1.1 e acima. As diferenças da versão 4.1.0 são as seguintes:

Causas dos Erros de Accesso Negado

Se você encontrar erros de Accesso Negado (Access denied) quando tentar conectar-se ao servidor MySQL, a lista abaixo indica alguns caminhos que você pode seguir para corrigir o problema:

Gerenciamento das Contas dos Usuários no MariaDB

A Sintaxe de GRANT e REVOKE
Nomes de Usuários e Senhas do MariaDB
Quando as Alterações nos Privilégios tem Efeito
Configurando os Privilégios Iniciais do MariaDB
Adicionando Novos Usuários ao MySQL
Deletando Usuários do MariaDB
Limitando os Recursos dos Usuários
Configurando Senhas
Mantendo Sua Senha Segura
Usando Conexões Seguras

A Sintaxe de GRANT e REVOKE

GRANT priv_type [(column_list)] [, tipo_priv [(column_list)] ...]
 ON {tbl_name | * | *.* | db_name.*}
 TO user_name [IDENTIFIED BY [PASSWORD] 'password']
 [, user_name [IDENTIFIED BY [PASSWORD] 'password'] ...]
 [REQUIRE
 NONE |
 [{SSL| X509}]
 [CIPHER cipher [AND]]
 [ISSUER issuer [AND]]
 [SUBJECT subject]]
 [WITH [GRANT OPTION | MAX_QUERIES_PER_HOUR # |
 MAX_UPDATES_PER_HOUR # |
 MAX_CONNECTIONS_PER_HOUR #]]
REVOKE priv_type [(column_list)] [, priv_type [(column_list)] ...]
 ON {tbl_name | * | *.* | db_name.*}
 FROM user_name [, user_name ...]

O comando GRANT é implementado no MariaDB versão 3.22.11 ou posterior. Para versões anteriores do MariaDB, a instrução GRANT não faz nada.

Os comandos GRANT e REVOKE permitem aos administradores do sistema criar usuários e conceder e revogar direitos aos usuários do MariaDB em quatro níveis de privilégios:

Para as instruções GRANT e REVOKE, tipo_priv pode ser especificado como um dos seguintes:

ALL [PRIVILEGES] Configura todos os privilégios simples exceto WITH GRANT OPTION
ALTER Permite o uso de ALTER TABLE
CREATE Permite o uso de CREATE TABLE
CREATE TEMPORARY TABLES Permite o uso de CREATE TEMPORARY TABLE
DELETE Permite o uso de DELETE
DROP Permite o uso de DROP TABLE.
EXECUTE Permite que o usuário execute stored procedures (MySQL 5.0)
FILE Permite o uso de SELECT ... INTO OUTFILE e LOAD DATA INFILE.
INDEX Permite o uso de CREATE INDEX e DROP INDEX
INSERT Permite o uso de INSERT
LOCK TABLES Permite o uso de LOCK TABLES em tabelas nas quais se tem o privilégio SELECT.
PROCESS Permite o uso de SHOW FULL PROCESSLIST
REFERENCES Para o futuro
RELOAD Permite o uso de FLUSH
REPLICATION CLIENT Da o direto ao usuário de perguntar onde o slave/master está.
REPLICATION SLAVE Necessário para a replicação dos slaves (para ler logs binário do master).
SELECT Permite o uso de SELECT
SHOW DATABASES SHOW DATABASES exibe todos os banco de dados.
SHUTDOWN Permite o uso de mysqladmin shutdown
SUPER Permite a conexão (uma vez) mesmo se max_connections tiverem sido alcançados e executa o comando CHANGE MASTER, KILL thread, mysqladmin debug, PURGE MASTER LOGS e SET GLOBAL
UPDATE Permite o uso de UPDATE
USAGE Sinônimo para sem privilégios.
GRANT OPTION Sinônimo para WITH GRANT OPTION

USAGE pode ser usado quando você quer criar um usuário sem privilégios.

Os privilégios CREATE TEMPORARY TABLES, EXECUTE, LOCK TABLES, REPLICATION ..., SHOW DATABASES e SUPER são novos na versão 4.0.2. Para usar estes novos privilégios após atualizar para 4.0.2, você tem que executar o script mysql_fix_privilege_tables. Leia 'Atualizando a Tabela de Permissões'.

Em versões anteriores do MariaDB, o privilégio PROCESS dá o mesmo direitos que o novo privilégio SUPER.

Para anular o privilégio grant de um usuário, utilize o valor tipo_priv de GRANT OPTION:

mysql> REVOKE GRANT OPTION ON ... FROM ...;

Os únicos valores de tipo_priv que você pode especificar para uma tabela são SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT, INDEX e ALTER.

Os únicos valores de tipo_priv que você pode especificar para uma coluna (isto é, quando você usar uma cláusula column_list) são SELECT, INSERT e UPDATE.

O MariaDB permite que você crie privilégios a nível de banco de dados mesmo se o banco de dados não existir para tornar fácil de se preparar para o uso do banco de dados. Atualmente, no entanto, o MariaDB não permite criar permissões de a nível de tabela se a tabela não existir. O MariaDB não revogará automaticamente qualquer privilégio, mesmo se você apagar uma tabela ou banco de dados.

Você pode configurar privilégios globais utilizando a sintaxe ON *.*. Você pode configurar privilégios de bancos de dados utilizando a sintaxe ON nome_bd.*. Se você especificar ON * e estiver com algum banco de dados aberto, será configurado os privilégios somente para este banco de dados. (AVISO: Se você especificar ON * e você não tem possui um banco de dados aberto, irá afetar os privilégios globais!).

Note por favor Os metacaracteres '_' e '%' são permitidos na especificação dos nomes de bancos de dados em comandos GRANT. Isto significa que se você deseja usar um caracater '_' como parte de um nome de banco de dados, você deve especificá-lo como '\_' no comando GRANT, para prevenir o usuário de poder acessar bancos de dados adicionais que correspondam ao padrão do metacaracter, ex., GRANT ... ON `foo\_bar`.* TO ....

Para acomodar concessões de direitos para usuários de máquinas arbitrárias, o MariaDB suporta a especificação do valor user_name no formato usuário@máquina. Se você desejar especificar uma string user contendo caracteres especiais (como o '-'), ou uma string contendo caracteres especiais ou meta caracteres (como o '%'), você pode colocar o usuário ou o nome de máquina entre aspas (por exemplo, 'usuário-teste'@'máquina-teste').

Você pode especificar meta caracteres no nome da máquina. Por exemplo, user@'%.loc.gov' se aplica a user para qualquer máquina no domínio loc.gov, e user@'144.155.166.%' se aplica a user em qualquer máquina na subrede de classe C 144.155.166.

O formato simples user é sinônimo de user@'%'.

O MariaDB não suporta metacaracteres em nomes de usuários. Usuários anônimos são definidos inserindo entradas com User='' na tabela mysql.user ou criando um usuário com um nome vazio com o comando GRANT.

Nota: Se você permite o acesso de usuários anônimos ao seu servidor MySQL, você deve também concecder privilégios a todos os usuários locais como user@localhost porque, de outra forma, a entrada de usuário anônimo para a máquina local na tabela mysql.user será usada quando o usuário tentar a conexão ao servidor MariaDB da máquina local!

Você pode verificar se isto se aplica a você executando a seguinte instrução:

mysql> SELECT Host,User FROM mysql.user WHERE User='';

No momento, GRANT suporta somente nomes de máquinas, tabelas bancos de dados e colunas até 60 caracteres. Um nome de usuário pode ter até 16 caracteres.

Os privilégios para uma tabela ou coluna são formados através do OU lógico dos privilégios em cada um dos quatro níveis de privilégios. Por exemplo, se a tabela mysql.user especifica que um usuário tem um privilégio global select, isto não pode ser negado por uma entrada no nível de banco de dados, tabela ou coluna.

Os privilégios para uma coluna podem ser calculados da seguinte forma:

privilégios globais OR (privilégios de banco de dados AND privilégios de máquina)
OR privilégios de tabela OR privilégios de coluna

Na maioria dos casos, os direitos a um usuário são atribuídos em apenas um dos níveis de privilégios, portanto a vida normalmente não é tão complicada como mostrado acima. Os detalhes do procedimento de verificação dos privilégios são apresentados em 'Detalhes Gerais de Segurança e o Sistema de Privilégio de Acesso do MariaDB'.

Se você concede privilégios para uma combinação de usuário e máquina que não existem na tabela mysql.user, um registro é adicionado e permanece lá até ser removido com um comando DELETE. Em outras palavras, GRANT pode criar registros na tabela user, mas REVOKE não as removerá; para removê-las você deve usar a instrução explícita DELETE.

Na Versão 3.22.12 ou posterior do MariaDB, se um novo usuário é criado ou se você possui privilégios de concessão globais, a senha do usuário será especificada utilizando a cláusula IDENTIFIED BY, se uma for dada. Se o usuário já possui uma senha, ela é trocada pela nova.

Se você não quiser enviar a senha em texto puro você pode usar a opção PASSWORD seguido de uma senha embaralhada da função SQL PASSWORD() ou da função da API C make_scrambled_password(char *to, const char *password).

CUIDADO: Se você criar um novo usuário mas não especificar uma cláusula IDENTIFIED BY, o usuário não possuirá uma senha. Isto não é seguro.

Senhas podem também ser configuradas com o comando SET PASSWORD. Leia 'Sintaxe de SET'.

Se você conceder privilégios para um banco de dados, uma entrada na tabela mysql.db é criada se necessário. Quando todos os privilégios para o banco de dados forem removidos com REVOKE, este registro é removido.

Se um usuário não tem privilégios em uma tabela, a tabela não é mostrada quando o usuário solicita uma lista de tabelas (com a instrução SHOW TABLES por exemplo). O mesmo é verdade para SHOW DATABASES

A cláusula WITH GRANT OPTION dá ao usuário habilidade de fornecer à outros usuários quaisquer privilégios que ele tenha em um nível específico de privilégio. Você deve ter cuidado ao fornecer o privilégio grant, pois dois usuários podem se unir para unir privilégios!

MAX_QUERIES_PER_HOUR #, MAX_UPDATES_PER_HOUR # e MAX_CONNECTIONS_PER_HOUR # sãp novos no MariaDB versão 4.0.2. Estas opções limitam o número de consultas/atualizações e logins que o usuários pode fazer durente uma hora. Se # é 0 (padrão), então isto significa que não há limites para aquele usuário. Leia 'Limitando os Recursos dos Usuários'. Nota: para especificar qualquer destas opções para um usuário existente sem adicionar outros privilégios adicionais, use GRANT USAGE ON *.* ... WITH MAX_....

Você não pode conceder a outro usuário um privilégio que não possua; o privilégio GRANT possibilita fornecer somente os privilégios que possuir.

Esteja ciente que quando conceder a um usuário o privilégio GRANT em um nível particular de privilégios, qualquer privilégio que o usuário já possua (ou seja fornecido no futuro!) nesse nível também pode ser concedido por este usuário. Suponha que você conceda a um usuário o privilégio INSERT em um banco de dados. Se você conceder o privilégio SELECT no banco de dados e especificar WITH GRANT OPTION, o usuário além de poder repassar o privilégio SELECT poderá também repassar o insert. Se você concede o privilégio UPDATE para o usuário no banco de dados, o usuário poderá conceder os privilégios INSERT, SELECT e UPDATE.

Você não deve conceder privilégios ALTER a um usuário comum. Se você fizer isto, o usuário pode tentar enganar o sistema de privilégios renomeando tabelas!

Perceba que se você estiver utilizando privilégios de tabelas ou colunas, mesmo que para apenas um usuário, o servidor examina os privilégios de tabelas e colunas para todos os usuários e isto irá deixar o MariaDB um pouco mais lento.

Quando o mysqld inicia, todos os privilégios são lidos na memória. Privilégios de bancos de dados, tabelas e colunas são iniciados um vez, e privilégios ao nível de usuário fazem efeito na próxima vez que o usuário conectar. Modificações nas tabelas de permissões que você realiza utilizando GRANT ou REVOKE são percebidas pelo servidor imediatamente. Se você modificar as tabelas de permissões manualmente (utilizando INSERT, UPDATE, etc), você deve executar uma instrução FLUSH PRIVILEGES ou executar mysqladmin flush-privileges para dizer ao servidor para recarregar as tabelas de permissões. Leia 'Quando as Alterações nos Privilégios tem Efeito'.

As maiores diferenças entre o padrão SQL e versões MariaDB de GRANT são:

Para uma descrição do uso de REQUIRE, veja 'Usando Conexões Seguras'.

Nomes de Usuários e Senhas do MariaDB

Existem várias diferenças entre a forma que nomes de usuários e senhas são usados pelo MariaDB e a forma que são usados pelo Unix ou Windows:

Usuários MariaDB e seus privilégios são criados normalmente com o comando GRANT, Leia 'A Sintaxe de GRANT e REVOKE'.

Quando você se conecta a um servidor MariaDB com um cliente de linha de comando você pode especificar a senha com --password=sua-senha. Leia 'Conectando ao Servidor MySQL'.

mysql --user=monty --password=guess nome_do_banco

Se você deseja que o cliente lhe solicite a senha, deve ser especificado o parâmetro --password sem nenhum argumento

mysql --user=monty --password nome_do_banco

ou no formato curto:

mysql -u monty -p nome_do_banco

Perceba que no último exemplo a senha não é 'nome_do_banco'.

Se você deseja usar a opção -p para fornecer uma senha você deve fazer assim:

mysql -u monty -pguess database_name

Em alguns sistemas, a chamada da biblioteca que é utilizada pelo MariaDB para solicitar por uma senha corta automaticamente a senha para 8 caracteres. Internamente o MariaDB não limita o tamanho limite da senha.

Quando as Alterações nos Privilégios tem Efeito

Quando o mysqld inicia, todas o conteúdo das tabelas de permissões são lidos em memória e tem efeito neste momento.

As modificações das tabelas de permissões que você realiza utilizando GRANT, REVOKE ou SET PASSWORD são imediatamente reconhecidas pelo servidor.

Se você alterar as tabelas de permissões manualmente (utilizando INSERT, UPDATE, etc), você deve executar a instrução FLUSH PRIVILEGES ou executar mysqladmin flush-privileges ou mysqladmin reload para dizer ao servidor para recarregar as tabelas de permissões. De outra forma suas alterações não terão efeito até que o servidor seja reiniciado. Se você alterar as tabelas de permissões manualmente mas se esquecer de recarregar os privilégios, suas alteração vão parecer não ter feito nenhuma diferença!

Quando o servidor reconhecer que as tabelas de permissões foram alteradas, conexões existentes são afetadas da seguinte forma:

Configurando os Privilégios Iniciais do MariaDB

Depois de instalar o MySQL, você configura os privilégios iniciais dos acessos executando scripts/mysql_install_db. Leia 'Visão geral da instalação rápida'. O script mysql_install_db inicia o servidor mysqld, depois inicializa as tabelas de permissões com a seguinte configuração dos privilégios:

NOTA: Os privilégios padrões são diferentes no Windows. Leia 'Executando o MariaDB no Windows'.

Como sua instação inicialmente é parcialmente aberta, uma das primeiras coisas que você deve fazer é especificar uma senha para o usuário root do MariaDB. Você pode fazer isto como a seguir (perceba que a senha foi especificada utilizando a função PASSWORD()):

shell> mysql -u root mysql
mysql> SET PASSWORD FOR root@localhost=PASSWORD('nova_senha');

Substitua 'nova_senha' pela senha que você deseja usar.

Se você souber o que esta fazendo, você também pode manipular diretamente a tabela privilégios:

shell> mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD('nova_senha')
 -> WHERE user='root';
mysql> FLUSH PRIVILEGES;

Outra forma de configurar a senha é utilizando o comando mysqladmin:

shell> mysqladmin -u root password nova_senha

Somente usuários com acesso de escrita/atualização ao banco de dados MariaDB podem alterar a senha de outros usuários. Todos os usuários comuns (não os anônimos) podem alterar somente a própria senha com um dos comandos acima ou com SET PASSWORD=PASSWORD('nova_senha').

Perceba que se você atualizar a senha na tabela user diretamente utilizando UPDATE, você deve dizer ao servidor para reler as tabelas de permissões (com FLUSH PRIVILEGES), de outra forma a alteração não seria notificada.

Uma vez que a senha de root foi configurada, você deve informar a senha quando se conectar ao servidor MariaDB como root.

Você pode desejar deixar a senha de root em branco para que você não precise especificá-la quando realizar configurações adicionais ou testes. Entretanto, tenha certeza de configurá-la antes de utilizar sua instalação para qualquer ambiente de produção.

Veja o script scripts/mysql_install_db para ver como são configurados os privilégios padrões. Você pode usar isto como uma base para ver como adicionar outros usuários.

Se você deseja que os privilégios iniciais sejam diferentes do descrito acima, é possível modificar o script mysql_install_db antes de executá-lo.

Para recriar as tabelas de permissões completamente, remova todos os arquivos .frm .MYI e .MYD no diretório contendo o banco de dados MariaDB. (Este é o diretório chamado MariaDB sob o diretório do banco de dados, que é listado quando você executa mysqld --help.) Depois execute o script mysql_install_db, possivelmente depois de editá-lo para criar os privilégios desejáveis.

NOTA: Para versões do MariaDB mais antigas que a versão 3.22.10, você não deve apagar os arquivos .frm. Se você fizer isso acidentalmente, você deve voltá-los a partir de sua distribuição MariaDB antes de executar mysql_install_db.

Adicionando Novos Usuários ao MariaDB

Existem duas maneiras de adicionar usuários: utilizando instruções GRANT ou manipulando as tabelas de permissões do MariaDB diretamente. O método preferido é utilizar instruções GRANT, porque elas são mais concisas e menos propensas a erros. Leia 'A Sintaxe de GRANT e REVOKE'.

Existem vários programas de colaboradores (como o phpMyAdmin) que podem ser utilizados para criar e administrar usuários. Leia Apêndice B, Contribuição de Programas.

Os exemplos abaixo mostram como usar o cliente MariaDB para configurar novos usuários. Estes exemplos assumem que privilégios são configurados de acordo com os padrões descritos na seção anterior. Isto significa que para fazer alterações, você deve se conectar na mesma máquina em que o mysqld está executando, você deve se conectar com o usuário root, e o usuário root deve ter os privilégios inster ao banco de dados MariaDB e o administrativo reload. Também, se você alterou a senha do usuário root, você deve especificá-la para os comandos MariaDB abaixo.

Primeiro, use o programa MariaDB para se conectar ao servidor como o usuário root do MariaDB:

shell> mysql --user=root mysql

Você pode adicionar novos usuários utilizando instruções GRANT:

mysql> GRANT ALL PRIVILEGES ON *.* TO monty@localhost
 IDENTIFIED BY 'alguma_senha' WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON *.* TO monty@'%'
 IDENTIFIED BY 'alguma_senha' WITH GRANT OPTION;
mysql> GRANT RELOAD,PROCESS ON *.* TO admin@localhost;
mysql> GRANT USAGE ON *.* TO dummy@localhost;

Estas instruções GRANT configuram três novos usuários:

Também é possível adicionar a mesma informação de acesso do usuário diretamente, utilizando instruções INSERT e depois dizendo ao servidor para recarregar as tabelas de permissões:

shell> mysql --user=root mysql
mysql> INSERT INTO user VALUES('localhost','monty',PASSWORD('alguma_senha'),
 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO user VALUES('%','monty',PASSWORD('alguma_senha'),
 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO user SET Host='localhost',User='admin',
 Reload_priv='Y', Process_priv='Y';
mysql> INSERT INTO user (Host,User,Password)
 VALUES('localhost','dummy','');
mysql> FLUSH PRIVILEGES;

Dependendo da sua versão do MariaDB, você pode precisar utilizar um número diferente de valores 'Y' acima. (Versões anteriores à versão 3.22.11 tem menos campos de privilégios, e posteriores a 4.02 têm mais). Para o usuário admin, a maior sintaxe legível de INSERT usando SET que está disponível a partir da versão 3.22.11 é a utilizada.

Note que para configurar um superusuário, você só precisar criar uma entrada na tabela user com os campos de privilégios configurados para 'Y'. Não é necessário gerar entradas nas tabelas db ou host.

Na última instrução INSERT (para o usuário dummy), apenas as colunas Host, User e Password nos registros da tabela user tem valores atribuídos. Nenhuma das colunas de privilégios são definidas explicitamente, assim o MariaDB atribui a todas o valor padrão de 'N'. Isto é a mesma coisa que o GRANT USAGE faz.

O seguinte exemplo adiciona um usuário custom que pode acessar o banco de dados bankaccout apenas do localhost, o banco de dados expenses somente de whitehouse.gov e o banco de dados customer de todas de server.domain. Ele deseja utilizar a senha obscure das três máquinas.

Para configurar os privilégios deste usuário utilizando instruções GRANT, execute estes comandos:

shell> mysql --user=root mysql
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
 -> ON bankaccount.*
 -> TO custom@localhost
 -> IDENTIFIED BY 'obscure';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
 -> ON expenses.*
 -> TO custom@'whitehouse.gov'
 -> IDENTIFIED BY 'obscure';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
 -> ON customer.*
 -> TO custom@'server.domain'
 -> IDENTIFIED BY 'obscure';

Para configurar os privilégios do usuário modificiando as tabelas de permissões diretamente, utilize estes comandos (perceba o FLUSH PRIVILEGES no final):

shell> mysql --user=root mysql
mysql> INSERT INTO user (Host,User,Password)
 -> VALUES('localhost','custom',PASSWORD('obscure'));
mysql> INSERT INTO user (Host,User,Password)
 -> VALUES('whitehouse.gov','custom',PASSWORD('obscure'));
mysql> INSERT INTO user (Host,User,Password)
 -> VALUES('server.domain','custom',PASSWORD('obscure'));
mysql> INSERT INTO db
 -> (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
 -> Create_priv,Drop_priv)
 -> VALUES
 -> ('localhost','bankaccount','custom','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO db
 -> (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
 -> Create_priv,Drop_priv)
 -> VALUES
 -> ('whitehouse.gov','expenses','custom','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO db
 -> (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
 -> Create_priv,Drop_priv)
 -> VALUES('server.domain','customer','custom','Y','Y','Y','Y','Y','Y');

Como no exemplo anterior que usaram as instruções INSERT, você pode precisar de usar um número diferentes de valores 'Y', dependendo de sua versão do MariaDB.

As primeiras três instruções INSERT adicionam entradas na tabela user que permite ao usuário custom conectar a partir de várias máquinas com a senha determinada, mas não concede permissões ao mesmo (todos os privilégios são configurados com o valor padrão de 'N'). As próximas três instruções INSERT adicionam entradas na tabela db que concedem privilégios à custom para os bancos de dados bankaccount, expenses e customer, mas só quando acessados à partir das máquinas apropriadas. Normalmente, depois de modificar as tabelas de permissões diretamente, você deve dizer ao servidor para recarregá-las (com FLUSH PRIVILEGES) para que as alterações nos privilégios tenham efeito.

Se você deseja fornecer a um usuário específico acesso de qualquer máquina em um determinado domínio (por exemplo, meudomínio.com), você pode utilizar uma instrução GRANT como a seguir:

mysql> GRANT ...
 -> ON *.*
 -> TO myusername@'%.mydomain.com'
 -> IDENTIFIED BY 'mypassword';

Para realizar a mesma coisa modificando diretamente as tabelas de permissões, faça isto:

mysql> INSERT INTO user VALUES ('%.meudominio, 'meunomedeusuario'
 PASSWORD('minhasenha'),...);
mysql> FLUSH PRIVILEGES;

Deletando Usuários do MariaDB

DROP USER nome_usuario

Este comando foi adicionado ao MariaDB.

Ele apaga um usuário que não possua nenhum privilágio.

Para deletar um usuário do MariaDB você usar o seguinte procedimento, realizando os passos na ordem mostrada.

  1. Verifique quais privilégios o usuário tem com SHOW PRIVILEGES. Leia 'SHOW PRIVILEGES'.
  2. Delete todos os privilégios do usuário com REVOKE. Leia 'A Sintaxe de GRANT e REVOKE'.
  3. Delete o usuário com DROP USER.

Se você estiver usando uma versão mais antiga do MariaDB você deve primeiro revogar os privilégios e então deletar o usuário com:

DELETE FROM mysql.user WHERE user='username' and host='hostname';
FLUSH PRIVILEGES;

Limitando os Recursos dos Usuários

A partir do MariaDB 4.0.2 pode se limitar certos recursos por usuários.

Até então, o único método disponível de limitação de uso do servidor MariaDB era canfigurar a variável de inicialização max_user_connections para um valor diferente de zero. Mas este método é estritamente global e não permite o gerenciamento de usuários individuais, o que pode ser de interresse particular do Provedor de Serviços Internet.

Consequentemente, o gerenciamento de três recursos é introduzido no nível de usuário individual:

Um usuário no contexto mencionado acima é uma única entrada na tabela user, que é identificada unicamente por suas colunas user e host.

Todos os usuários não são limitados por padrão no uso dos recursos acima, a menos que os limites sejam garantidos a eles. Estes limites podem ser concedidos apenas através do GRANT (*.*) global, usando esta sintaxe:

GRANT ... WITH MAX_QUERIES_PER_HOUR N1
 MAX_UPDATES_PER_HOUR N2
 MAX_CONNECTIONS_PER_HOUR N3;

Pode-se especificar qualquer combinação dos recursos acima. N1, N2 e N3 são inteiros e significam contagem/hora.

Se os usuários alcançam o limite de conexões dentro de uma hora, não será aceita mais nenhuma conexão até o fim desta hora. De forma parecida se o usuário alcança o limite do número de consultas ou atualizações, consultas ou atualizações adicionais serão rejeitadas até que a hora acabe. Em todos os casos, uma mensagem de erro apropriada é enviada.

Os valores atualmente usados por um usuário em particular pode ser descarregados (zerados) enviando uma instrução GRANT com qualquer das cláusulas acima, incluíndo uma instrução GRANT com os valores atuais.

Os valores atuais para todos os usuários para todos os usuários serão descarregados se os privilégios forem recarregados (no servidor ou usando mysqladmin reload) ou se o comando FLUSH USER_RESOURCES é executado.

O resurso está habilitado assim que e concedido a um único usuário qualquer das cláusulas GRANT de limitação.

Como um prerequisito para a habilitação deste recurso, a tabela user no banco de dados MariaDB deve conter as colunas adicionais, como definido no script de criação de tabelas mysql_install_db e mysql_install_db.sh no subdiretório scripts.

Configurando Senhas

Na maioria dos casos você deve utilizar GRANT para configurar seus usuários e senhas, portanto, as informações exibidas a seguir são aplicadas somentes para usuários avançados. Leia 'A Sintaxe de GRANT e REVOKE'.

Os exemplos nas seções precedentes ilustram um princípio importante: quando você armazena uma senha não-vazia utilizando INSERT ou UPDATE você deve utilizar a função PASSWORD() para criptografá-la. Isto é porque a tabela user armazena senhas na forma criptografada, e não como texto puro. Se você esquecer deste fato, é provável que você possa tentar configurar senhas desta forma:

shell> mysql -u root mysql
mysql> INSERT INTO user (Host,User,Password)
 VALUES('%','jeffrey','biscuit');
mysql> FLUSH PRIVILEGES;

O resultado é que o valor 'biscuit' é armazenado como a senha na tabela user. Quando o usuário jeffrey tentar se conectar ao servidor utilizando esta senha, o cliente MariaDB a criptografa utilizando a função PASSWORD(), gerando um vetor de autenticação baseado em uma senha criptografada e um número randômico, obtido do servidor, e envia o resultado ao servidor. O servidor usa o valor do campo password na tabela user (que é o valor 'biscuit' não criptografado ) para realizar os mesmos cálculos e comparar os resultados. A comparação falha e o servidor rejeita a conexão:

shell> mysql -u jeffrey -pbiscuit test
Access denied

As senhas devem ser criptografadas quando elas são inseridas na tabela user, portanto a instrução INSERT deveria ter sido informada no seguinte formato:

mysql> INSERT INTO user (Host,User,Password)
 VALUES('%','jeffrey',PASSWORD('biscuit'));

Você deve também utilizar a função PASSWORD() quando utilizar instruções SET PASSWORD:

mysql> SET PASSWORD FOR jeffrey@'%' = PASSWORD('biscuit');

Se você configurar senhas utilizando a instrução GRANT ... IDENTIFIED BY ou o comando mysqladmin password, a função PASSWORD() é desnecessária. Ambos tomam o cuidado de criptografar a senha para você, então você deve especificar a senha 'biscuit' desta forma:

mysql> GRANT USAGE ON *.* TO jeffrey@'%' IDENTIFIED BY 'biscuit';

ou

shell> mysqladmin -u jeffrey password biscuit

NOTA: PASSWORD() é diferente da senha criptografada do Unix.

Mantendo Sua Senha Segura

Não é aconselhável especificar uma senha de uma forma que a exponha e possa ser descoberta por outros usuários. Os métodos que você pode usar para especificar sua senha quando executar programas clientes são listados abaixo, juntamente com as determinações de riscos de cada método:

Em resumo, os métodos mais seguros seriam que o programa cliente solicitasse a senha ou especificar a senha em um arquivo .my.cnf corretamente protegido.

Usando Conexões Seguras

Conceitos Basicos
Exigências
Configurando Certificados SSL para o MySQL
Opções SSL do GRANT
Opções SSL de Linha de Comando

Conceitos Basicos

A partir da versão 4.0.0, o MariaDB tem suporte a conexões cri[ptografadas com SSL. Para entender como o MariaDB usa SSL, é necessário explicar alguns conceits básicos de SSL e X509. A pessoal que já estão familiarizada com eles podem saltar esta parte.

Por padrão o MariaDB não usa conexões criptografadas entre o cliente e o servidor. Isto significa que qualquer um pode observar todo o tráfico e ver os dados enviados e recebidos. Podiase até mesmo alterar os dados enquanto eles estavam em transito entre o cliente e o servidor. Algumas vezes você precisao mover informações sobre redes públicas de um modo seguro; em tais casos, usar uma conexão sem criptografia é inaceitável.

SSL é um protocolo que utiliza diferentes algorítimos de criptografia para assegurar que os dados recebidos por uma rede pública são confiáveis. Ele tem um mecanismo para detectar qualquer alteração, perda ou reenvio de dados. SSL também incorpora algoritmos para reconhecer e fornecer identidades de verificação usando o padrão X509.

Criptografia é o modo de tornar qualquer tipo de dado ilegível. De fato, as práticas de hoje precisam de muitos elementos de segurança adicionais para algoritmos de criptografia. Eles devem resistir a muitos tipos de atques conhecidos como apenas alterando a ordem da mensagem criptografada ou emviando o dado duas vezes.

X509 é um padrão que torna possível identificar alguém na Internet. Ele é mais comumente usado em aplicações e-commerce. Em termos básicos, deve haver algumas empresas (chamadas Autoridades de Certificação) que atribuem certificados eletrônicos para qualquer um que precise deles. Os certificados se baseiam em algorítmos de criptografia assimétricos que possuem duas chaves de criptografia (uma chave pública e uma chave secreta). Um proprietário de certificado pode provar a sua identidade mostrnado este certificado para outra parte. Um certificado consiste das chaves públicas do proprietário. Qualquer dados criptografado com esta chave pública pode ser descriptografada apenas usando a chave secreta correspondente, que é guardada pelo dono do certificado.

O MariaDB não utiliza conexões criptografadas por padrão, porque fazendo isto tornaria o protocolo cliente/servidor muito lento. Qualquer tipo de funcionalidade adiocional exige que o conputador faça um trabalho adicional e a criptografia de dados é uma operação intensiva da CPU que exige tempo e pode atrasar o MariaDB nas tarefas principais. Por padrão o MariaDB é ajustado para ser o mais rápido possível.

Se você precisa de mais informações sobre SSL, X509 ou criptografia, você deve usar se mecanismo de busca favorita na Internet para procurar sobre o assunto que está interessado.

Exigências

Para conseguir conexões seguras para trabalhar com o MariaDB você deve fazer o seguinte:

  1. Insatale o biblioteca OpenSSL. Testamos o MariaDB com OpenSSL 0.9.6. http://www.openssl.org/.
  2. Configure o MariaDB com --with-vio --with-openssl.
  3. Se você estiver usando um instalação antiga do MariaDB, você tem que atualizar a sua tabela mysql.user com algumas novas colunas relacionadas a SSL. Isto é necessário se suas tabelas de permissões são de uma versão anterior ao MariaDB 4.0.0. O procedimento está descrito em 'Atualizando a Tabela de Permissões'.
  4. Você pode verificar se um servidor mysqld em execução suporta OpenSSL examinando se SHOW VARIABLES LIKE 'have_openssl' retorna YES.

Configurando Certificados SSL para o MariaDB

Aqui está um exemplo para configurar certificados SSL para o MySQL:

DIR=`pwd`/openssl PRIV=$DIR/private mkdir $DIR $PRIV $DIR/newcerts cp /usr/share/ssl/openssl.cnf $DIR replace ./demoCA $DIR -- $DIR/openssl.cnf
# Crie os aarquivos necessário: $database, $serial e o diretório
$new_certs_dir (opcional)
touch $DIR/index.txt echo '01' > $DIR/serial
#
# Geração do Certificate Authority(CA)
#
openssl req -new -x509 -keyout $PRIV/cakey.pem -out $DIR/cacert.pem \
 -config $DIR/openssl.cnf
# Saída exemplo:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# ................++++++
# .........++++++
# writing new private key to '/home/monty/openssl/private/cakey.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be incorporated
# into your certificate request.
# What you are about to enter is what is called a Distinguished Name or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MariaDB Foundation
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL admin
# Email Address []:
#
# Create server request and key
#
openssl req -new -keyout $DIR/server-key.pem -out \
 $DIR/server-req.pem -days 3600 -config $DIR/openssl.cnf
# Saída exemplo:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# ..++++++
# ..........++++++
# writing new private key to '/home/monty/openssl/server-key.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be incorporated
# into your certificate request.
# What you are about to enter is what is called a Distinguished Name or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MariaDB Foundation
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL server
# Email Address []:
#
# Please enter the following 'extra' attributes
# to be sent with your certificate request
# A challenge password []:
# An optional company name []:
#
# Remove the passphrase from the key (optional)
#
openssl rsa -in $DIR/server-key.pem -out $DIR/server-key.pem
#
# Assina o certificado do servidor
#
openssl ca -policy policy_anything -out $DIR/server-cert.pem \
 -config $DIR/openssl.cnf -infiles $DIR/server-req.pem
# Saída exemplo:
# Using configuration from /home/monty/openssl/openssl.cnf
# Enter PEM pass phrase:
# Check that the request matches the signature
# Signature ok
# The Subjects Distinguished Name is as follows
# countryName :PRINTABLE:'FI'
# organizationName :PRINTABLE:'MariaDB Foundation'
# commonName :PRINTABLE:'MySQL admin'
# Certificate is to be certified until Sep 13 14:22:46 2003 GMT (365 days)
# Sign the certificate? [y/n]:y
#
#
# 1 out of 1 certificate requests certified, commit? [y/n]y
# Write out database with 1 new entries
# Data Base Updated
#
# Create client request and key
#
openssl req -new -keyout $DIR/client-key.pem -out \
 $DIR/client-req.pem -days 3600 -config $DIR/openssl.cnf
# Saída exemplo:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# .....................................++++++
# .............................................++++++
# writing new private key to '/home/monty/openssl/client-key.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# You are about to be asked to enter information that will be incorporated
# into your certificate request.
# What you are about to enter is what is called a Distinguished Name or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MariaDB Foundation
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL user
# Email Address []:
#
# Please enter the following 'extra' attributes
# to be sent with your certificate request
# A challenge password []:
# An optional company name []:
#
# Remove a passphrase from the key (optional)
#
openssl rsa -in $DIR/client-key.pem -out $DIR/client-key.pem
#
# Sign client cert
#
openssl ca -policy policy_anything -out $DIR/client-cert.pem \
 -config $DIR/openssl.cnf -infiles $DIR/client-req.pem
# Saída exemplo:
# Using configuration from /home/monty/openssl/openssl.cnf
# Enter PEM pass phrase:
# Check that the request matches the signature
# Signature ok
# The Subjects Distinguished Name is as follows
# countryName :PRINTABLE:'FI'
# organizationName :PRINTABLE:'MariaDB Foundation'
# commonName :PRINTABLE:'MySQL user'
# Certificate is to be certified until Sep 13 16:45:17 2003 GMT (365 days)
# Sign the certificate? [y/n]:y
#
#
# 1 out of 1 certificate requests certified, commit? [y/n]y
# Write out database with 1 new entries
# Data Base Updated
#
# Create a my.cnf file that you can use to test the certificates
#
cnf=''
cnf='$cnf [client]'
cnf='$cnf ssl-ca=$DIR/cacert.pem'
cnf='$cnf ssl-cert=$DIR/client-cert.pem'
cnf='$cnf ssl-key=$DIR/client-key.pem'
cnf='$cnf [mysqld]'
cnf='$cnf ssl-ca=$DIR/cacert.pem'
cnf='$cnf ssl-cert=$DIR/server-cert.pem'
cnf='$cnf ssl-key=$DIR/server-key.pem'
echo $cnf | replace ' ' '
' > $DIR/my.cnf
#
# To test MariaDB mysqld --defaults-file=$DIR/my.cnf &
mysql --defaults-file=$DIR/my.cnf

Você também pode testar sua configuração modificando o arquivo my.cnf acima para fazer referência aos certificados de demonstração no diretório mysql-dist-fonte/SSL.

Opções SSL do GRANT

O MariaDB pode verificar atributos do certificado X509 em adição ao esquema normal de usuário/senha. Todas as opções comuns ainda são exigidas (usuário, senha, máscara do endereço IP, noome tabela/banco de dados).

Existem diferentes possibilidades para limitarmos as conexões:

Opções SSL de Linha de Comando

A seguinte tabela lista opções que são usadas para especificar o uso de SSL, arquivos de certificado e arquivos de chaves. Estas opções estão disponíveis a partir do MariaDB 4.0. Elas podem ser dadas na linha de comando ou no arquivo de opção.

Prevenção de Disastres e Recuperação

Backups dos Bancos de Dados
Sintaxe de BACKUP TABLE
Sintaxe de RESTORE TABLE
Sintaxe de CHECK TABLE
Sintaxe do REPAIR TABLE
Utilizando myisamchk para Manutenção de Tabelas e Recuperação em Caso de Falhas
Configurando um Regime de Manutenção das Tabelas
Obtendo Informações sobre as Tabelas

Backups dos Bancos de Dados

Como as tabelas do MariaDB são armazenadas como arquivos, é mais fácil realizar um backup. Para obter um backup consistente, faça um LOCK TABLES nas tabelas relevantes seguido por FLUSH TABLES para as tabelas. Leia 'Sintaxe LOCK TABLES e UNLOCK TABLES'. Leia 'Sintaxe de FLUSH'. Você só precisa de um bloqueio de leitura; isto possibilita outras threads a continuarem a pesquisar nas tabelas enquanto você copia os arquivos no diretório do banco de dados. O FLUSH TABLE é necessário para garantir que todas as páginas ativas de índices serão escritas em disco antes de iniciar o backup.

A partir das versões 3.23.56 e 4.0.12 BACKUP TABLE não permitirá que você sobrescreva arquivos exixtentes já que isso colocaria em risco a segurança.

Se você desejar realizar um backup ao nível da linguagem SQL de um tabela, você pode utilizar SELECT INTO OUTFILE ou BACKUP TABLE. Leia 'Sintaxe SELECT'.See 'Sintaxe de BACKUP TABLE'.

Outra maneira de efetuar um backup de um banco de dados é utilizar o programa mysqldump ou o script mysqlhotcopy. Leia 'mysqldump, Descarregando a Estrutura de Tabelas e Dados'. Leia 'mysqlhotcopy, Copiando Bancos de Dados e Tabelas do MariaDB'.

  1. Fazer um backup completo do seu banco de dados: 

    shell> mysqldump --tab=/path/to/some/dir --opt db_name
ou shell> mysqlhotcopy db_name /path/to/some/dir

    Você também pode simplesmente copiar os arquivos das tabelas (*.frm, *.MYD) e os arquivos *.MYI) quando o servidor não estiver atualizando nada. O script mysqlhotcopy utiliza este método. (Mas nopte que estes métodos não funcionarão se seu banco de dados contém tabelas InnoDB. InnoDB não armazena o conteúdo das tabelas em diretórios de banco de dados, e o mysqlhotcopy funciona apenas para tabelas MyISAM e ISAM.)

  2. Interrompa o mysqld caso ele esteja em execução, depois inicie-o com a opção --log-bin[=nome_arquivo]. Leia 'O Log Binário'. Os arquivos de log binário fornecem a informação necessária para replicar alterações ao banco de dados que forem feitas depois do ponto em que você executou mysqldump.

Se o seu servidor MariaDB é um slave, seja qual for o método de backup que você escolha, quando você faz backup dos dados do slave, você deve também fazer backup dos arquivos master.info e relay-log.info que são necessários para continuar a replicação depois que você restaurar os dados do slave. Se seu slave está sujeito a replicação de comandos LOAD DATA INFILE, você também deve fazer backup dos arquivos SQL_LOAD-* que podem existir no diretório especificado pela opção slave-load-tmpdir. (A localização padrão desta opção é o valor da variável tmpdirse não especificado.) O slave precisará destes arquivos para continuar a replicação de qualquer LOAD DATA INFILE interrompido.

Se você necessita restaurar alguma coisa, tente primeiro recuperar suas tabelas utilizando REPAIR TABLE ou myisamchk -r. Isto deve funcionar em 99.9% de todos os caso, Se o myisamchk falhar, tente o seguinte procedimento: (Isto só irá funcionar se você iniciou o MariaDB com --log-update, veja 'O Log Binário',):

  1. Restaure o backup original feito com o mysqldump ou backup binário.
  2. Execute o seguinte comando para re-executar as atualizações armazenadas no log binário: 

    shell> mysqlbinlog hostname-bin.[0-9]* | mysql

    Em seu caso você pode querer re-executar apenas alguns log binários, a partir de certas posiçõs (normalmente você quer re-executar todos os log binários a partir da data de restauração do backup, co exceção de algumas consultas erradas). Veja 'mysqlbinlog, Executando as Consultas a Partir de um Log Binário' fpara mais informações sobre o utilitário mysqlbinlog e como usá-lo.

    Se você estiver utilizando o log atualizado, você pode executar o conteúdo do log de atualização desta forma:

    shell> ls -1 -t -r hostname.[0-9]* | xargs cat | mysql

O comando ls é usado para obter todos os arquivos de log na ordem correta.

Você pode também fazer backups seletivos com SELECT * INTO OUTFILE 'nome_arquivo' FROM nome_tabela e restaurar com LOAD DATA INFILE 'nome_arquivo' REPLACE.... Para evitar registros duplicados, você precisará de um chave PRIMARY KEY ou uma UNIQUE na tabela. A palavra chave REPLACE substitui os antigos registros com os novos quando um novo registro duplica um antigo registro em uma chave de valores únicos.

Se você tiver problemas de performance realizando backups no seu sistema, você pode resolver isto configurando uma replicação e fazendo os backups na máquina slave no lugar da master. Leia 'Introdução'.

Se você estiver utilizando um sistema de arquivos Veritas, você pode fazer:

  1. Executar em um cliente (perl ?) FLUSH TABLES WITH READ LOCK
  2. Bifurcar uma shell ou executar em outro cliente mount vfxs snapshot.
  3. Executar no primeiro cliente UNLOCK TABLES
  4. Copiar arquivos do snapshot
  5. Desmontar snapshot

Sintaxe de BACKUP TABLE

BACKUP TABLE nome_tabela[,nome_tabela...] TO '/caminho/para/diretório/backup'

Faz uma cópia de todos os arquivos de tabela para o diretório de backup que é o mínimo necessário para restaurá-lo. Atualmente só funciona para tabelas MyISAM. Para tabela MyISAM, copia os arquivos .frm (definições) e .MYD (dados). O arquivo de índice pode ser reconstruído a partir destes dois.

Antes de utilizar este comando, por favor veja Leia 'Backups dos Bancos de Dados'.

Durante o backup, o bloqueio de leitura (read lock) será usado para cada tabela, uma de cada vez, à medida que o backup é realizado. Se você deseja fazer backup de diversas tabelas como um snapshot, você deve primeiro usar LOCK TABLES obtendo um bloqueio de leitura para cada tabela no grupo.

O comando retorna uma tabela com as seguintes colunas:

Coluna Valor
Table Nome da Tabela
Op Sempre backup
Msg_type Um dos seguintes: status, error, info ou warning.
Msg_text A mensagem

Note que o comando BACKUP TABLE está disponível somente no MariaDB versão 3.23.25 e posterior.

Sintaxe de RESTORE TABLE

RESTORE TABLE nome_tabela[,nome_tabela...] FROM '/caminho/para/diretório/backup'

Restaura a tabela ou tabelas utilizando o backup feito com BACKUP TABLE. Tabelas existentes não serão reescritas - se você tentar restaurar sobre uma tabela existente, obterá um erro. A restauração demora mais tempo do que o backup pois é necessário reconstruir o índice. Quanto mais chaves tiver, mais demorado será. Como no comando BACKUP TABLE, atualmente só funciona com tabelas MyISAM.

O comando retorna uma tabela com as seguintes colunas:

Coluna Valor
Table Nome da Tabela
Op Sempre restore
Msg_type Um dos seguintes: status, error, info ou warning
Msg_text A mensagem

Sintaxe de CHECK TABLE

CHECK TABLE nome_tabela[,nome_tabela...] [opção [opção...]]
opção = QUICK | FAST | MEDIUM | EXTENDED | CHANGED

CHECK TABLE funciona somente em tabelas MyISAM. Em tabelas MyISAM é a mesma coisa que executar myisamchk --medium-check nome_tabela na tabela.

Se você não especificar nenhuma opção, MEDIUM é usado.

Verifica se existem erros na(s) tabela(s). Para as tabelas MyISAM as estatísticas das chaves são atualizadas. O comando retorna uma tabela com as seguintes colunas:

Coluna Valor
Table Nome da Tabela.
Op Sempre check
Msg_type Um dos seguintes: status, error, info, or warning
Msg_text A mensagem

Note que a instrução pode produzir várias linhas de informações para cada tabela conferida. A última linha irá ser do tipo Msg_type status e normalmente deve estar OK. Se você não obteve OK ou Not checked, deve ser executado, normalmente, um reparo da tabela. Leia 'Utilizando myisamchk para Manutenção de Tabelas e Recuperação em Caso de Falhas'. Table is already up to date significa que o gerenciador de armazenamento para a tabela indica que não há necessidade de verificar a tabela.

Os diferentes tipos de consistências são as seguintes:

Tipo Significado
QUICK Não busca os registros verificando ligações incorretas.
FAST Só confere tabelas que não foram fechadas corretamente.
CHANGED Só verifica as tabelas que foram alteradas desde a última conferência ou que não foram fechadas corretamente.
MEDIUM Busca os registros para verificanado que ligações removidas estão ok. Isto também calcula uma chave de conferência para os registros e verifica isto com um checksum calculado para as chaves.
EXTENDED Faz uma busca completa nas chaves para todas as chaves em cada registro. Isto assegura que a tabela está 100% consistente, mas pode demorar muito tempo para executar!

Para tabelas MyISAM de tamanho dinâmico, uma verificação iniciada sempre fará uma verificação MEDIUM. Para registros de tamanho estático nós saltamos a busca de registros para QUICK e FAST já que os registros estão raramente corrompidos.

Você pode combinar opções de consistência como no exemplo a seguir que faz uma verificação rápida na tabela para ve se ela foi fechada corretamente:

CHECK TABLE test_table FAST QUICK;

NOTA: em alguns casos CHECK TABLE irá alterar a tabela! Isto acontece se a tabela estiver marcada como 'corrupted' (corrompida) ou 'not closed properly' (não foi fechada corretamente) mas o CHECK TABLE não encontrar não encontrar nenhum problema na tabela. Neste caso, CHECK TABLE irá marcar a tabela como ok.

Se uma tabela estiver corrompida, é preferível que seja um problema nos índices e não na parte de dados. Todos os tipos de consistência acima sempre confere os índices e deve então encontrar a maioria dos erros.

Se você só quiser conferir uma tabela que acredita estar ok, você não deve utilizar nenhuma opção para o comando check ou utilizar a opção QUICK. O último deve ser utilizado quando você estiver com pressa e o rísco do QUICK não encontrar um erro no arquivo de dados for mínimo (Na maioria dos casos o MariaDB pode encontrar, sob utilização normal, qualquer erro no arquivo de dados. Se isto ocorrer, então a tabela será marcada como 'corrupted', neste caso a tabela não poderá ser utilizada até ser reparada).

FAST e CHANGED são normalmente chamados a partir de um script (um exemplo é ser executado a partir do cron) Se você desejar conferir suas tabelas de tempos em tempos. Na maioria dos casos, o FAT é uma opção melhor que CHANGED. (O único caso em que isto não acontece é quando você suspeita que encontrou um bug no código do MyISAM.).

EXTENDED deve ser utilizado somente depois de ter executado um check normalmente, mas continuar obtendo erros de uma tabela quando o MariaDB tenta atualizar um registro ou encontrar um registro pela chave (isto seria muito difícil ocorrer caso uma conferência normal tenha executado corretamente!).

Alguns problemas relatados por CHECK TABLE, não podem ser corrigidas automaticamente:

Sintaxe do REPAIR TABLE

REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...] [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE funciona somente em tabelas MyISAM e é a mesma coisa que executar myisamchk -r nome_tabela na tabela.

Normalmente você nunca deve executar este comando, mas se um disastre ocorrer você vai precisar recuperar seus dados de uma tabela MyISAM utilizando REPAIR TABLE. Se as suas tabelas estiverem muito corrompidas, você deve encontrar a razão, para eleiminar a necessidade de se usar REPAIR TABLE! Leia Seção A.4.1, 'O Que Fazer Se o MariaDB Continua Falhando'. Leia 'Problemas com Tabelas MyISAM'.

REPAIR TABLE repara uma tabela possivelmente corrompida. O comando retorna uma tabela com as seguintes colunas:

Coluna Valor
Table Nome da Tabela
Op Sempre repair
Msg_type Um dos seguintes: status, error, info ou warning
Msg_text A mensagem

Note que a instrução pode produzir várias linhas de informações para cada tabela recuperada. A ultima linha será de Msg_type status e normalmente deve exibir OK. Se o retorno não for OK, você pode tentar reparar a tabela com myisamchk -o, já que REPAIR TABLE ainda não implementa todas as opções de myisamchk. Futuramente iremos torná-lo mais flexível.

Se o parâmetro QUICK for especificado, REPAIR tenta reparar somente a árvore de índices.

Se você utilizar EXTENTED, o MariaDB criará o índice, registro a registro em vez de criar um índice de uma vez com ordenação; Isto pode ser melhor que a ordenação em chaves de tamanho fixo se você tiver grandes chaves do tipo char() que compactam muito bem.

No MariaDB 4.0.2, existe um modo USE_FRM para REPAIR. Use-o se o arquivo .MYI estiver faltando ou o seu cabeçalho estiver corrompido. Neste modo o MariaDB recriará a tabela, usando a informação do arquivo .frm. Este tipo de reparo não pode ser feito com myisamchk.

Aviso: Se o mysqld morre durante um REPAIR TABLE, é essencial que você faça imediatamente outro REPAIR na tabela antes de executar qualquer outro comando nela. (Claro que é sempre bom inciar com um backup). No pior caso você pode ter um novo arquivo de índice limpo sem informação sobre o arquivo de dados e quando você executar o próximo comando o arquivo de dados pode ser sobreescrito. Isto não é um cenário desejável, mas possível.

Antes do MariaDB, o comando REPAIR não era gravado no log binário. Desde o MariaDB. eles são escritos no log binário a menos que a palavra chave opcional NO_WRITE_TO_BINLOG (ou seu alias LOCAL) seja usada.

Utilizando myisamchk para Manutenção de Tabelas e Recuperação em Caso de Falhas

Sintaxe do myisamchk
Opções Gerais do myisamchk
Opções de Verificação do myisamchk
Opções de Reparos do myisamchk
Outras Opções do myisamchk
Uso de Memória do myisamchk
Uso do myisamchk para Recuperação em Caso de Falhas
Como Verificar Erros em Tabelas
Como Reparar Tabelas
Otimização de Tabelas

A partir do MariaDB versão 3.23.13 você pode mandar verificar as tabelas MyISAM com o comando CHECK TABLE. Leia 'Sintaxe de CHECK TABLE'. Pode-se reparar tabelas com o comando REPAIR TABLE. Leia 'Sintaxe do REPAIR TABLE'.

Para verificar/reparar tabelas MyISAM (.MYI e .MYD) você deve utilizar o utilitário myisamchk. Para consistir/reparar tabelas ISAM (.ISM e .ISD) você deve usar o utilitário isamchk. Leia Tipos de Tabela do MariaDB.

No texto a seguir iremos comentar sobre o myisamchk, mas tudo também se aplica ao antigo isamchk.

Você pode utilizar o utilitário myisamchk para obter informações sobre suas tabelas de bancos de dados, verficá-las, repará-las ou otimizá-las. As seguintes seções descrevem como executar myisamchk (incluindo uma descrição de suas opções), como montar um calendário de manutenção, e como utilizar o myisamchk para executar suas várias funções.

Você pode, na maioria dos casos, utilizar o comando OPTIMIZE TABLES para otimizar e reparar tabelas, mas não é tão rápido e confiável (no caso real de erros fatais) como o mysisamchk. Por outro lado, OPTIMIZE TABLE é mais fácil de usar e você não tem que se preocupar com a recarrega das tabelas. Leia 'Sintaxe de OPTIMIZE TABLE'.

Embora os reparos realizados pelo myisamchk sejam bastante seguros, porém é sempre uma boa idéia fazer um backup dos dados ANTES de realizar um reparo (ou qualquer coisa que fará grandes alterações em alguma tabela)

Sintaxe do myisamchk

myisamchk é chamado desta forma:

shell> myisamchk [opções] nome_tabela

As opções especificam o que você deseja que o myisamchk faça. Elas são descritas abaixo. (Você também pode obter a lista das opções com myisamchk --help.) Sem opções, o myisamchk simplesmente checa sua tabela. Para obter maiores informações ou dizer ao myisamchk para tomar ações corretivas, especifique as opções descritas abaixo e nas seções seguintes.

nome_tabela é o nome da tabela do banco de dados que você deseja verificar/reparar. Se você executar o myisamchk em algum lugar diferente do diretório do banco de dados, você deve especificar o caminho para o arquivo, porque myisamchk não faz idéia de onde seu banco de dados se encontra. Na verdade, myisamchk não se importa se os arquivos estão localizados em um diretório de banco de dado; você pode copiar os arquivos que correspondem a uma tabela de banco de dados em outra localização e realizar neste outro lugar as operações corretivas.

Você pode nomear várias tabelas na linha de comando do myisamchk se você desejar. Você também pode especificar um nome como um arquivo de índice (com o sufixo .MYI), que lhe permite especificar todas tabelas em um diretório utilizando o padrão *.MYI. Por exemplo, se você está em um diretório de banco de dados, você pode checar todas as tabelas no diretório desta forma:

shell> myisamchk *.MYI

Se você não estiver no diretório do banco de dados, você pode verificar todas as tabelas existentes especificando o caminho para o diretório:

shell> myisamchk /caminho/para/banco_de_dados/*.MYI

Você pode verificar todas as tabelas em todos os bancos de dados especificando um meta caracter com o caminho para o diretório de banco de dados do MariaDB:

shell> myisamchk /caminho/para/diretório_dados/*/*.MYI

A maneira recomendada para conferir todas as tabelas rapidamente é:

myisamchk --silent --fast /caminho/para/diretório_dados/*/*.MYI isamchk --silent /caminho/para/diretório_dados/*/*.ISM

Se você quiser conferir todas as tabelas e reparar todas que estiverem corrompidas, pode utilizar linha a seguir:

myisamchk --silent --force --fast --update-state -O key_buffer=64M \
 -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M \
 /caminho/para/diretório_dados/*/*.MYI isamchk --silent --force -O key_buffer=64M -O sort_buffer=64M \
 -O read_buffer=1M -O write_buffer=1M /caminho/para/diretório_dados/*/*.ISM

A linha acima assume que você tem mais de 64 MB de memória livre.

Perceba que se você obter um erro do tipo:

myisamchk: warning: 1 clients is using or hasn't closed the table properly

Isto significa que você está tentando verificar uma tabela que está sendo atualizada por outro programa (como o servidor mysqld) que ainda não fechou o arquivo ou que finalizou sem fechar o arquivo corretamente.

Se o mysqld está em execução, você deve forçar o sincronimo e fechamento de todas tabelas com FLUSH TABLES e assegurar que ninguém mais esteja utilizando as tabelas quando for executar o myisamchk. No MariaDB versão 3.23 a forma mais simples de evitar este problema é utilizar CHECK TABLE no lugar de myisamchk para verificar as tabelas.

Opções Gerais do myisamchk

myisamchk suporta as seguintes opções.

Opções de Verificação do myisamchk

Opções de Reparos do myisamchk

As seguintes opções são usadas se você iniciar o myisamchk com -r ou -o:

Outras Opções do myisamchk

Outras ações que o myisamchk pode fazer, alem de reparar e verificar tabelas:

Uso de Memória do myisamchk

Alocação de memória é importante quando você executa o myisamchk. myisamchk não utiliza mais memória do que você especifica com a opção -O. Se você irá utilizar o myisamchk em grandes arquivos, você deve decidir primeiro quanta memória deseja usar. O valor padrão é utilizar somente 3MB para correções. Utilizando valores maiores, o myisamchk pode operar mais rapidamente. Por exemplo, se você tiver mais que 32M de memória RAM, você pode utilizar opções tais como esta (em adição às várias outras que podem ser especificadas):

shell> myisamchk -O sort=16M -O key=16M -O read=1M -O write=1M ...

Utilizando -O sort=16M provavelmente é suficiente para a maioria dos casos.

Certiffique-se que o myisamchk utiliza arquivos temporários em TMPDIR. Se TMPDIR aponta para um sistema de arquivos em memória, você pode facilmente obter erros de memória. Se isto acontecer, configure TMPDIR para apontar para algum diretório com mais espaço e reinicie o myisamchk.

Quando reparando, o myisamchk também precisará de bastante espaço em disco:

Se você tiver um problema com espaço em disco durante o reparo, pode-se tentar usar --safe-recover em vez de --recover.

Uso do myisamchk para Recuperação em Caso de Falhas

Se você executa o mysqld com a opção --skip-external-locking (que é o padrão em alguns sistemas, como o Linux), você não pode utilizar com segurança o myisamchk para conferir uma tabela se o mysqld estiver utilizando a mesma tabela. Se você pode ter certeza que ninguém está acessando as tabelas através do mysqld enquanto você executa o myisamchk, você só tem que executar o mysqladmin flush-tables antes de iniciar a verificação das tabelas. Se você não tem certeza, então você deve desligar o mysqld enquanto verifica as tabelas. Se você executa o myisamchk enquanto o mysqld estiver atualizando as tabelas, você pode obter um altera que a tabela está corrompida mesmo se não estiver.

Se você não estiver utilizando --skip-external-locking, pode usar o myisamchk para conferir as tabelas a qualquer hora. Enquanto você faz isto, todos os clientes que tentarem atualizar a tabela irão esperar até que o myisamchk esteja pronto, antes de continuar.

Se você utilizar o myisamchk para reparar ou otimizar tabelas, você DEVE sempre assegurar que o servidor mysqld não esteja utilizando a tabela (Isto também aplica se você utiliza --skip-external-locking). Se você não desligar o MariaDB, você deve, pelo menos, fazer um mysqladmin flush-tables antes de executar o myisamchk. Suas tabelas podem estar corrompidos se o servidor e o myisamchk acessarem a tabela simultaneamente.

Este descreve como checar e lidar com dados corrompidos nos bancos de dados MySQL. Se suas tabelas corromperem com frequência deve ser encontrada a razão para isto! Leia Seção A.4.1, 'O Que Fazer Se o MariaDB Continua Falhando'.

A seção de tabelas MyISAM contêm motivos do porque uma tabela pode estar corrompida. Leia 'Problemas com Tabelas MyISAM'.

Quando se realizar recuperação devido a falhas, é importante entender que cada tabela nome_tabela em um banco de dados corresponde a tres arquivos no diretório do banco de dados:

Arquivo Propósito
nome_tabela.frm Arquivo com definições da tabela (form)
nome_tabela.MYD Arquivo de dados
nome_tabela.MYI Arquivo de índices

Cada um destes três tipos de arquivos está sujeito a corrupção de várias formas, mas problemas ocorrem mais frequentemente em arquivos de dados e índices.

O myisamchk trabalha criando uma cópia do arquivo de dados .MYD linha a linha. Ele termina o estágio de reparos removendo o antigo arquivo .MYD e renomeando o novo arquivo com nome original. Se for utilizada a opção --quick, myisamchk não cria um arquivo .MYD temporário, mas assume que o arquivo .MYD está correto e somente gera um novo arquivo índice sem mexer no arquivo de dados. Isto é seguro, pois o myisamchk detecta automaticamente se o arquivo .MYD está corrompido e aborda o reparo neste caso. Você pode também fornecer duas opções --quick para o myisamchk. Neste caso, o myisamchk não aborta em alguns erros (como chaves duplicadas) mas tenta resolvê-los modificando o arquivo .MYD. Normalmente o uso de duas opções --quick é útil somente se você tiver muito pouco espaço em disco para realizer um reparo normal. Neste caso você deve pelo menos fazer um backup antes de executar o myisamchk.

Como Verificar Erros em Tabelas

Para conferir uma tabela MyISAM, utilize os seguintes comandos:

Como Reparar Tabelas

Na seção seguinte nós só falaremos do uso do myiasmchk em tabelas MyISAM (extensões .MYI e .MYD). Se você estiver usando tabelas ISAM (extensões .ISM e .ISD), você deve usar a ferramenta isamchk.

A partir do MariaDB versão 3.23.14, você pode reparar tabelas MyISAM com o comando REPAIR TABLE. Leia 'Sintaxe do REPAIR TABLE'.

Os sintomas de uma tabela corrompida incluem pesquisas que abortam inesperadamente e erros como estes:

Em outros casos, você deve reparar suas tabelas. myisamchk pode normalmente detectar a maioria dos problemas que ocorrem.

O processo de reparo involve até quatro estágios, descritos abaixo. Antes de começar, você deve mudar para o diretório do banco de dados e conferir as permissões dos arquivos de tabelas. Tenha certeza que eles possam ser lidos pelo usuário do Unix com o qual mysqld é executado (e para você, porque você precisa acessar os arquivos que está conferindo). Se não estiverem, você precisa alterar os arquivos, eles também devem ter a permissão de escrita para você.

Se você estiver utilizando o MariaDB versão 3.23.16 e superior, você pode (e deve) usar os comandos CHECK e REPAIR para conferir e corrigir tabelas MyISAM. See 'Sintaxe de CHECK TABLE'. Leia 'Sintaxe do REPAIR TABLE'.

A seção do manual sobre manutenção de tabelas inclui as opções para isamchk/myisamchk. Leia 'Utilizando myisamchk para Manutenção de Tabelas e Recuperação em Caso de Falhas'.

A seguinte seção são para os casos onde o comando acima falhar ou se você desejar usar os recursos extendidos que o isamchk e myisamchk fornecem.

Se você for reparar uma tabela da linha de comandos, deve primeiro desligar o servidor mysqld. Perceba que quando você executa mysqladmin shutdown em um servidor remoto, o servidor mysqld irá continuar funcionando por um tempo depois do mysqladmin retornar, até que todas as queries parem e todas as chaves sejam descarregadas no disco.

Estágio 1: Verificando suas tabelas

Execute myisamchk *.MYI ou myisamchk -e *.MYI se você tiver tempo disponível. Utilize a opção -s (silencioso) para suprimir informações desnecessárias.

Se o servidor mysqld parar, deve ser utilizada a opção --update para dizer ao myisamchk marcar a tabela como 'checada'.

Você deve reparar somente as tabelas em que o myisamchk indicar um erro. Para tais tabelas, vá para o estágio 2.

Se você obter erros estranhos na verficação (como nos erros out of memory), ou se o myisamchk quebrar, vá para o estágio 3.

Estágio 2: Reparo simples e seguro

NOTA: Se você deseja que os reparos sejam mais rápidos, devem ser usadas as opções: -O sorf_buffer=# -O key_buffer=# (onde # seria 1/4 da memória disponível) para todos comandos isamchk/myisamchk.

Primeiro, tente usar myisamchk -r -q nome_tabela (-r -q significa modo de recuperação rápida). Ele tentará reparar o arquivo de índice sem mexer no arquivo de dados. Se o arquivo de dados estiver normal e os links apagados apontam nas localizações corretas dentro do arquivo de dados, isto deve funcionar e a tabela será corrigida. Inicie o reparo da próxima tabela. Outra maneira seria utilizar os seguintes procedimentos:

  1. Faça um backup do arquivo de dados antes de continuar.
  2. Utilize myisamchk -r nome_tabela (-r significa modo de recuperação). Isto removerá registros incorretos e deletados do arquivo de dados e reconstroi o arquivo de índices.
  3. Se o passo anterior falhar, utilize myisamchk --safe-recover nome_tabela. O modo de recuperação segura utiliza um metódo de recuperação antiga que trata de alguns casos que o modo de recuperação comum não consegue (porém é mais lento).

Se você obter erros estranhos no reparo (como em erros out of memory), ou se o myisamchk falhar, vá para o estágio 3.

Estágio 3: Reparo difícil

Você só deve atingir este estágio se o primeiro bloco de 16K do arquivo de índice estiver destruído ou conter informações incorretas, ou se o arquivo de índice não existir. Neste caso, é necessário criar um novo arquivo de índice. Faça como a seguir:

  1. Mova o arquivo de dados para algum lugar seguro.
  2. Use o arquivo de descrição de tabelas para criar novos arquivos (vazios) de dados e índices: 

    shell> mysql nome_bd
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE nome_tabela;
mysql> quit

    Se sua versão do MariaDB não possuir TRUNCATE TABLE, utilize DELETE FROM nome_tabela.

  3. Copie o antigo arquivo de dados de volta para o novo arquivo de dados criado. (Não só mova o antigo arquivo de volta para o novo arquivo; você deve uma cópia no caso de algo der errado.)

Volte ao estágio 2. myisamchk -r -q deve funcionar agora. (Isto não deve ser um loop eterno.)

No MariaDB 4.0.2 você também pode utilizar REPAIR ... USE_FRM o qual realiza todo o procedimento automaticamente.

Estágio 4: Reparo muito difícil

Você deve atingir este estágio somente se o arquivo de descrição também falhar. Isto nunca deve acontecer, porque o arquivo de descrição não é alterado depois da tabela ser criada:

  1. Restaure o arquivo de descrição de um backup e volte ao estágio 3. Você pode também restaurar o arquivo de índice e voltar ao estágio 2. No último caso, você deve iniciar com myisamchk -r.
  2. Se você não tem um backup mas sabe exatamente como a tabela foi criada, crie uma cópia da tabela em outro banco de dados. Remova o novo arquivo de dados, e então mova a descrição e arquivos de índice do outro banco de dados para o banco de dados com problemas. Isto lhe fornece um novo arquivos índice e descrição, mas mantêm o arquivo de dados da mesma forma. Volte ao estágio 2 e tente reconstruir o arquivo de índices.

Otimização de Tabelas

Para agrupar registros fragmentados e eliminar perda de espaço resultante de remoções ou atualizações de registros, execute myisamchk no modo de recuperação:

shell> myisamchk -r nome_tabela

Você pode otimizar uma tabela da mesma forma utilizando a instrução SQL OPTIMIZE TABLE. OPTIMIZE TABLE faz o reparo de tabelas, analisa chaves e também ordena a árvore de índices para fazer pesquisas por chave mais rápidas. Também não existem possibilidade de interação não desejável entre o utilitário e o servidor, porque o servidor faz todo o trabalho quando você utiliza OPTIMIZE TABLE. Leia 'Sintaxe de OPTIMIZE TABLE'.

myisamchk também tem um número de outras opção que podem ser usadas para melhorar a performance de uma tabela:

Para uma descrição completa da opção. Leia 'Sintaxe do myisamchk'.

Configurando um Regime de Manutenção das Tabelas

Desde o MariaDB v3.23.13, você pode conferir tabelas MyISAM com o comando CHECK TABLE. Leia 'Sintaxe de CHECK TABLE'. Você pode reparar tabelas com o comando REPAIR TABLE. Leia 'Sintaxe do REPAIR TABLE'.

É uma boa idéia verificar as tabelas regularmente em vez de esperar que ocorram problemas. Para propósitos de manutenção você pode utilizar o myisamchk -s para verificar as tabelas. A opção -s (abreviação de --silent) faz com que o myisamchk execute em modo silencioso, exibindo mensagens somente quando ocorrem erros.

É também uma boa idéia verificar as tabelas quando o servidor inicia. Por exemplo, sempre que a máquina reinicia no meio de uma atualização, você normalmente precisará conferir todas as tabelas que podem ter sido afetadas. (Isto é umatabela com falhas esperadas.) Você pode adicionar um teste ao mysqld_safe que executa myisamchk para conferir todas tabelas que foram modificadas durante as últimas 24 horas se existir um arquivo .pid (process ID) antigo depois do último reboot. (O arquivo .pid é criado pelo mysqld quando ele inicia e removido quando ele termina normalmente. A presença de um arquivo .pid durante a inicialização do sistema indica que o mysqld terminou de forma anormal.)

Um teste ainda melhor seria verificar qualquer tabela cuja a data da última modificação é mais recente que a do arquivo .pid.

Você também deve verificar suas tabelas regularmente durante a operação normal do sistema. Na MariaDB Foundation, nós executamos uma tarefa agendada cron para conferir todas nossas tabelas importantes uma vez por semana utilizando uma linha com esta no arquivo crontab:

35 0 * * 0 /diretório/do/myisamchk --fast --silent /diretório/de/dados/*/*.MYI

Isto exibe informações sobre tabelas com falhas para que possamos examiná-las e repará-las quando necessário.

Como nós não estamos tendo tabelas com falhas inesperadas (tabelas corrompidas por razões diferentes de problemas de hardware) por vários anos (isto realmente é verdade), uma vez por semana é mais que suficiente para nós.

Nós recomendamos que para iniciar, você execute myisamchk -s a cada noite em todas as tabelas que foram atualizadas durantes as últimas 24 horas, até que você confie no MariaDB como nós confiamos.

Normalmente você não precisará de tanta manutenção em suas tabelas MySQL. Se você estiver alterando tabelas com registros de tamanho dinâmico (tabelas com colunas VARCHAR, BLOB ou TEXT) ou tem tabelas com vários registros apagados você pode desejar de tempos em tempos (uma vez ao mês?) desfragmentar/recuperar espaço das tabelas.

Você pode fazer isto utilizando OPTIMIZE TABLE nas tabelas em questão ou se você puder desligar o servidor mysqld por um tempo faça:

isamchk -r --silent --sort-index -O sort_buffer_size=16M */*.ISM myisamchk -r --silent --sort-index -O sort_buffer_size=16M */*.MYI

Obtendo Informações sobre as Tabelas

Para obter uma descrição de uma tabela ou estatísticas sobre ela, utilize os comandos mostrados abaixo, nós explicaremos algumas das informações em mais detalhes posteriormente:

Exemplo da saída de myisamchk -d

MyISAM file: company.MYI Record format: Fixed length Data records: 1403698 Deleted blocks: 0
Recordlength: 226
table description:
Key Start Len Index Type
1 2 8 unique double
2 15 10 multip. text packed stripped
3 219 8 multip. double
4 63 10 multip. text packed stripped
5 167 2 multip. unsigned short
6 177 4 multip. unsigned long
7 155 4 multip. text
8 138 4 multip. unsigned long
9 177 4 multip. unsigned long
 193 1 text

Exemplo da saída de myisamchk -d -v :

MyISAM file: company Record format: Fixed length File-version: 1
Creation time: 1999-10-30 12:12:51
Recover time: 1999-10-31 19:13:01
Status: checked Data records: 1403698 Deleted blocks: 0
Datafile parts: 1403698 Deleted data: 0
Datafilepointer (bytes): 3 Keyfile pointer (bytes): 3
Max datafile length: 3791650815 Max keyfile length: 4294967294
Recordlength: 226
table description:
Key Start Len Index Type Rec/key Root Blocksize
1 2 8 unique double 1 15845376 1024
2 15 10 multip. text packed stripped 2 25062400 1024
3 219 8 multip. double 73 40907776 1024
4 63 10 multip. text packed stripped 5 48097280 1024
5 167 2 multip. unsigned short 4840 55200768 1024
6 177 4 multip. unsigned long 1346 65145856 1024
7 155 4 multip. text 4995 75090944 1024
8 138 4 multip. unsigned long 87 85036032 1024
9 177 4 multip. unsigned long 178 96481280 1024
 193 1 text

Exemplo da saída de myisamchk -eis:

Checking MyISAM file: company Key: 1: Keyblocks used: 97% Packed: 0% Max levels: 4
Key: 2: Keyblocks used: 98% Packed: 50% Max levels: 4
Key: 3: Keyblocks used: 97% Packed: 0% Max levels: 4
Key: 4: Keyblocks used: 99% Packed: 60% Max levels: 3
Key: 5: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 6: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 7: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 8: Keyblocks used: 99% Packed: 0% Max levels: 3
Key: 9: Keyblocks used: 98% Packed: 0% Max levels: 4
Total: Keyblocks used: 98% Packed: 17%
Records: 1403698 M.recordlength: 226
Packed: 0%
Recordspace used: 100% Empty space: 0%
Blocks/Record: 1.00
Record blocks: 1403698 Delete blocks: 0
Recorddata: 317235748 Deleted data: 0
Lost space: 0 Linkdata: 0
User time 1626.51, System time 232.36
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 627, Swaps 0
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 639, Involuntary context switches 28966

Exemplo da saída de myisamchk -eiv:

Checking MyISAM file: company Data records: 1403698 Deleted blocks: 0
- check file-size
- check delete-chain block_size 1024:
index 1:
index 2:
index 3:
index 4:
index 5:
index 6:
index 7:
index 8:
index 9:
No recordlinks
- check index reference
- check data record references index: 1
Key: 1: Keyblocks used: 97% Packed: 0% Max levels: 4
- check data record references index: 2
Key: 2: Keyblocks used: 98% Packed: 50% Max levels: 4
- check data record references index: 3
Key: 3: Keyblocks used: 97% Packed: 0% Max levels: 4
- check data record references index: 4
Key: 4: Keyblocks used: 99% Packed: 60% Max levels: 3
- check data record references index: 5
Key: 5: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 6
Key: 6: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 7
Key: 7: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 8
Key: 8: Keyblocks used: 99% Packed: 0% Max levels: 3
- check data record references index: 9
Key: 9: Keyblocks used: 98% Packed: 0% Max levels: 4
Total: Keyblocks used: 9% Packed: 17%
- check records and index references
[LOTS OF ROW NUMBERS DELETED]
Records: 1403698 M.recordlength: 226 Packed: 0%
Recordspace used: 100% Empty space: 0% Blocks/Record: 1.00
Record blocks: 1403698 Delete blocks: 0
Recorddata: 317235748 Deleted data: 0
Lost space: 0 Linkdata: 0
User time 1639.63, System time 251.61
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 10580, Swaps 0
Blocks in 4 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 10604, Involuntary context switches 122798

Aqui estão os tamanhos dos arquivos de dados e índices para a tabela utilizada nos exemplos anteriores:

-rw-rw-r-- 1 monty tcx 317235748 Jan 12 17:30 company.MYD
-rw-rw-r-- 1 davida tcx 96482304 Jan 12 18:35 company.MYM

Explicações para os tipos de informações que o myisamchk produz são fornecidas abaixo. O keyfile é o arquivo de índices. Registro e linha são sinônimos:

Se uma tabela foi compactada com myisampack, mysiamchk -d exibe informações adicionais sobre cada coluna da tabela. Veja 'myisampack, O Gerador de Tabelas Compactadas de Somente Leitura do MariaDB', para um exemplo desta informação e uma descrição do que ela significa.

Adiministração do Banco de Dados e Referência de Linguagem

Sintaxe de OPTIMIZE TABLE
Sintaxe de ANALYZE TABLE
Sintaxe de CHECKSUM TABLE
Sintaxe de FLUSH
Sintaxe de RESET
Sintaxe de PURGE MASTER LOGS
Sintaxe de KILL
Sintaxe de SHOW

Sintaxe de OPTIMIZE TABLE

OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name]...

OPTIMIZE TABLE deve ser usado se você apagou uma grande parte de uma tabela ou se você fez várias alterações à uma tabela com registros de tamanho variável (tabelas que tenham campos do tipo VARCHAR, BLOB ou TEXT). Registros apagados são mantidos em uma lista de ligações e operações INSERT subsequentes reutilizam posições de registros antigos. Você pode utilizar OPTIMIZE TABLE para reclamar o espaço inutilizado e para desfragmentar o arquivo de dados.

Na maioria da configurações você não tem que executar OPTIMIZE TABLE. Mesmo se você fizer diversas atualizações para registros de tamanhos variáveis não é desejável que você precise fazer isto mais que uma vez por mês/semana e apenas em determinadas tabelas.

No momento OPTIMIZE TABLE só funciona em tabelas MyISAM e BDB. Para tabelas BDB, OPTIMIZE TABLE é atualmente mapeado para ANALIZE TABLE. Leia 'Sintaxe de ANALYZE TABLE'.

Você pode ter a otimização de tabelas trabalhando em outros tipos de tabelas iniciando o mysqld com --skip-new ou --safe-mode, mas neste caso, OPTIMIZE TABLE é mapeado apenas para ALTER TABLE.

OPTIMIZE TABLE funciona da seguinte forma:

Perceba que a tabela estará bloqueada durante o tempo em que OPTIMIZE TABLE estiver executando.

Antes do MariaDB, o OPTIMIZE comnado não gravava no log binário. Desde o MariaDB eles são escritos no log binário a menos que a palavra chave opcional NO_WRITE_TO_BINLOG (ou se alias LOCAL) seja usada.

Sintaxe de ANALYZE TABLE

ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...]

Analisa e armazena a distribuição de chaves para a tabela. Durante a análise a tabela é bloqueada com uma trava de leitura. Isto funciona em tabelas MyISAM e BDB.

Isto seria equivalente a executar myisamchk -a na tabela.

O MariaDB utiliza a distribuição de chaves armazenadas para decidir em que ordem tabelas devem ser unidas quando alguém faz um join em alguma coisa diferente de uma constante.

O comando retorna uma tabela com as seguintes colunas:

Coluna Valor
Table Nome da Tabela
Op Sempre analyze
Msg_type Um dos seguintes: status, error, info ou warning
Msg_text A mensagem

Você pode verificar a distribuição de chaves armazenadas com o comando SHOW INDEX. Leia 'Recuperando Informações sobre Bancos de Dados, Tabelas, Colunas e Índices'.

Se a tabela não foi alterada deste o último comando ANALYZE TABLE, a tabela não será analisada novamente.

Antes do MariaDB, o ANALYZE comnado não gravava no log binário. Desde o MariaDB eles são escritos no log binário a menos que a palavra chave opcional NO_WRITE_TO_BINLOG (ou se alias LOCAL) seja usada.

Sintaxe de CHECKSUM TABLE

CHECKSUM TABLE tbl_name[,tbl_name ...] [ QUICK | EXTENDED ]

Reports a table checksum. If QUICK is specified, live table checksum is reported, or NULL if the table does not support live checksum. This is very fast. In EXTENDED mode the whole table is read row by row and the checksum is calculated. This can be very slow for large tables. By default - with neither QUICK nor EXTENDED - MariaDB returns live checksum if the table support it and scans the table otherwise.

Este comando está implementado no MariaDB.

Sintaxe de FLUSH

FLUSH [LOCAL | NO_WRITE_TO_BINLOG] flush_option [,flush_option] ...

Você deve utilizar o comando FLUSH se desejar limpar algum dos caches internos que o MariaDB usa. Para executar FLUSH, você deve ter o privilégio RELOAD.

opções podem ser qualquer uma das seguintes:

Option Description
HOSTS Esvazia as tabelas de cache de nomes de máquinas. Você deve descarregar as tabelas de nomes de máquinas se alguma de suas máquinas receber um número IP diferente ou se você obter a mensagem de erro Host ... is blocked. Quando mais de max_connect_erros erros occorrer em um registro para uma determinada máquina enquanto se conecta ao servidor MySQL, o MariaDB assume que algo está errado e bloqueia futuras requisições desta máquina. A descarga na tabela de nomes de máquinas permite à máquina se conectar novamente. Leia Seção A.2.5, 'Erro: Host '...' is blocked'.) Você pode iniciar o mysqld com -O max_connection_errors=999999999 para evitar esta mensagem de erro.
DES_KEY_FILE Recarrega a chave DES do arquivo que foi especificado com a opção --des-key-file durante inicialização do servidor.
LOGS Fecha e reabre todos os arquivos de log. Se você tiver especificado o arquivo de logs de atualizações ou um arquivo de log binário sem uma extensão, o número de extensão do arquivo log será sempre incrementado de um em relação ao arquivo anterior. Se você usou uma extensão no nome do arquivo, o MariaDB irá fechar e reabrir o arquivo de log de atualizações. Leia 'O Log de Atualizações'. Isto é a mesma coisa que enviar o sinal SIGHUP para o servidor mysqld.
PRIVILEGES Recarrega os privilégios das tabelas de permissões no banco de dados MariaDB.
QUERY CACHE Defragmenta a cache de consulta par utilizar melhor a sua memória. Este comando não remove qualquer consulta da cache, ao contrário de RESET QUERY CACHE.
TABLES Fecha todas as tabelas abertas e força o fechamento de todas as tabelas em uso
[TABLE | TABLES] nome_tabela [,nome_tabela...] Descarga somente das tabelas fornecidas.
TABLES WITH READ LOCK Fecha todas tabelas abertas e bloqueia todas tabelas para todos os bancos de dados com leitura até que alguém execute UNLOCK TABLES. Isto é uma maneira muito conveniente para fazer backups se você possui um sistema de arquivos, como Veritas, que pode fazer uma imagem instantânea (snapshot) de um certo momento.
STATUS Reinicia a maioria das variáveis de status para zero. Isto é algo que deve ser usado somente para depurar uma consulta.
USER_RESOURCES Zera todos os recirsos dos usuários. Isto permitirá que usuários bloqueados façam login novamente. Leia 'Limitando os Recursos dos Usuários'.

Antes do MariaDB, o FLUSH comnado não gravava no log binário. Desde o MariaDB eles são escritos no log binário a menos que a palavra chave opcional NO_WRITE_TO_BINLOG (ou se alias LOCAL) seja usada, ou que o comando contenha um dos argumentos: LOGS, MASTER, SLAVE, TABLES WITH READ LOCK, pois qualquer um desses argumwentos podem causar problemas se replicados para um slave.

Você pode também acessar cada um dos comandos vistos acima com o utilitário mysqladmin, utilizando os comandos flush-hosts, flush-logs, reload ou flush-tables.

Também de uma olhada no comando RESET usado com a replicação. Leia 'Sintaxe de RESET'.

Sintaxe de RESET

RESET reset_option [,reset_option] ...

O comando RESET é usado para limpar coisas. Ele também atua como uma versão mais forte do comando FLUSH. Leia 'Sintaxe de FLUSH'.

Para executar RESET, você deve ter o privilégio RELOAD.

Opção Descrição
MASTER Deleta todos os logs binários listados no arquivo índice, esvaziando o arquivo de índice do log binário. Anteriormente chamado FLUSH MASTER. Leia 'Instruções SQL para Controle do Servidor Master'.
SLAVE Faz o slave esquecer a sua posição de replicação no log binário do master. Anteriormente chamado FLUSH SLAVE. Leia 'Instruções SQL para Controle do Servidor Slave'.
QUERY CACHE Remove todos os resulatdos de consultas da cache de consultas.

Sintaxe de PURGE MASTER LOGS

PURGE {MASTER|BINARY} LOGS TO nome_binlog PURGE {MASTER|BINARY} LOGS BEFORE data

Este comando é usado para deletar todos os logs binários estritamente anteriores ao binlog ou data especificada. Leia 'Instruções SQL para Controle do Servidor Master'.

PURGE BINARY LOGS está disponível como um sinônimo para PURGE MASTER LOGS a partir do MariaDB.

Sintaxe de KILL

KILL thread_id

Cada conexão ao mysqld executa em uma thread separada. Você pode ver quais threas estão em execução com o comando SHOW PROCESSLIST e matar uma thread com o comando KILL thread_id.

Se você tiver o privilégio PROCESS, você pode ver todas as threads. Se você tiver o privilégio SUPER, você pode matar todas as threads. Caso contrário, você pode ver e matar somente suas próprias threads.

Você também pode usar os comandos mysqladmin processlist e mysqladmin kill para examinar e matar threads.

Nota: Atualmente você não pode utilizar KILL com a biblioteca do servidor MariaDB embutido, porque o servidor embutido apenas roda dentro das threads da aplicação, ela não cria threads de conexões por si própria.

Quando você utiliza um KILL, um sinal (flag) kill especifico é configurado para a thread.

Na maioria dos casos pode levar algum tempo para a thread morrer pois o sinal kill só é checado em intervalos específicos.

Sintaxe de SHOW

Recuperando Informações sobre Bancos de Dados, Tabelas, Colunas e Índices
SHOW TABLE STATUS
SHOW STATUS
SHOW VARIABLES
SHOW [BDB] LOGS
SHOW PROCESSLIST
SHOW GRANTS
SHOW CREATE TABLE
SHOW WARNINGS | ERRORS
SHOW TABLE TYPES
SHOW PRIVILEGES
 SHOW DATABASES [LIKE wild]
ou SHOW [OPEN] TABLES [FROM nome_bd] [LIKE wild]
ou SHOW [FULL] COLUMNS FROM nome_tbl [FROM nome_bd] [LIKE wild]
ou SHOW INDEX FROM nome_tbl [FROM nome_bd]
ou SHOW TABLE STATUS [FROM nome_bd] [LIKE wild]
ou SHOW STATUS [LIKE wild]
ou SHOW VARIABLES [LIKE wild]
ou SHOW [BDB] LOGS ou SHOW [FULL] PROCESSLIST ou SHOW GRANTS FOR user ou SHOW CREATE TABLE nome_tbl ou SHOW MASTER STATUS ou SHOW MASTER LOGS ou SHOW SLAVE STATUS ou SHOW WARNINGS [LIMIT row_count]
ou SHOW ERRORS [LIMIT row_count]
ou SHOW TABLE TYPES

SHOW fornece informações sobre bancos de dados, tabelas, colunas ou informações do estado do servidor. Se a parte LIKE wild é usada, a string wild pode ser uma string que usa os meta caracteres '%' e '_' do SQL.

Recuperando Informações sobre Bancos de Dados, Tabelas, Colunas e Índices

Você pode usar nome_bd.nome_tabela como uma alternativa para a sintaxe nome_tabela FROM nome_bd. Estas duas declarações são equivalentes:

mysql> SHOW INDEX FROM minhatabela FROM meudb;
mysql> SHOW INDEX FROM meubd.minhatabela;

SHOW DATABASES lista os bancos de dados no servidor MySQL. Você também pode obter esta lista utilizando o comando mysqlshow. Na versão 4.0.2 você verá apenas aqeules banco de dados para os quais você tem algum tipo de privilégio, se você não tiver o privilégio global SHOW DATABASES.

SHOW TABLES lista as tabelas em um banco de dados específico. Esta lista também pode ser obtida utilizando o comando mysqlshow nome_db.

NOTA: Se um usuário não possui nenhum privilégio para uma tabela, a tabela não será mostrada na saída de SHOW TABLES ou mysqlshow nome_db

SHOW OPEN TABLES lista as tabelas que estão abertas no cache de tabelas. Leia 'Como o MariaDB Abre e Fecha as Tabelas'. O campo Comment diz quantas vezes a tabela está em cached e in_use.

SHOW COLUMNS lista as colunas em uma determinada tabela. Se você especificar a opção FULL, também irá obter os privilégios que você possui para cada coluna. Se os tipos de colunas forem diferentes do que você esperava baseando na declaração CREATE TABLE, perceba que o MariaDB algumas vezes altera os tipos das colunas. Leia 'Alteração de Especificações de Colunas'. A partir do MariaDB, a palavra chave FULL também faz com que qualquer comentário por coluna seja mostrado.

A instrução DESCRIBE fornece informação similar à SHOW COLUMNS. Leia 'Sintaxe DESCRIBE (Obtem Informações Sobre Colunas)'.

SHOW FIELDS é um sinônimo para SHOW COLUMNS e SHOW KEYS um sinônimo para SHOW INDEX. Você também pode listar as colunas ou índices de uma tabela com mysqlshow nome_db nome_tabela ou mysqlshow -k nome_bd nome_tabela.

SHOW INDEX retorna a informação de índice em um formato que lembra bem a chamada SQLStatistics do ODBC. As seguintes colunas são retornadas:

Coluna Significado
Table Nome da tabela.
Non_unique 0 se o índice não puder conter duplicidades, 1 se puder
Key_name Nome do índice.
Seq_in_index Número da sequência da coluna no índice, à partir de 1.
Column_name Nome da coluna.
Collation Como a coluna é ordenada no índice. No MySQL, pode ter valores 'A' (Ascendente) ou NULL (Not sorted).
Cardinality Número de valores únicos no índice. Isto é atualizado executando isamchk -a.
Sub_part Número de caracteres indexados se a coluna só é a indexada parcialmente. NULL se a chave inteira for indexada.
Null Contém 'YES' se a coluna puder conter NULL.
Index_type Método de índice utilizado.
Comment Vários comentários. No momento, ele diz no MariaDB < 4.0.2 se o índice é FULLTEXT ou não.

Perceba que como o Cardinality é contado baseado nas estatísticas armazenadas como inteiros, ele pode não ser exato para tabelas pequenas.

As colunas Null e Index_type foram adicionadas no MariaDB 4.0.2.

SHOW TABLE STATUS

SHOW TABLE STATUS [FROM nome_bd] [LIKE wild]

SHOW TABLE STATUS (introduzido na versão 3.23) funciona como o SHOW STATUS, mas fornece muitas informações sobre cada tabela. Você também pode obter esta lista utilizando o comando mysqlshow --status nome_bd. As seguintes colunas são retornadas:

Coluna Significado
Name Nome da tabela.
Type Tipo da tabela. Leia Tipos de Tabela do MariaDB.
Row_format O formato de armazenamento do registro (Fixed (Fixo), Dynamic(dinâmico), ou Compressed (Compactado)).
Rows Número de registros.
Avg_row_length Tamanho médio do registro.
Data_length Tamanho do arquivo de dados.
Max_data_length Tamanho máximo do arquivo de dados. Para formatos de registro fixo, este é o número maimo de registros na tabela. Para formatos de registro dinâmicos, este é o número total de bytes de dados que pode ser armazenados na tabela, dado o tamanho do ponteiro de dados utilizado.
Index_length Tamanho do arquivo de índice.
Data_free Número de bytes alocados mas não utilizados.
Auto_increment Próximo valor do auto incremento.
Create_time Quando a tabela foi criada.
Update_time A última vez que arquivo de dados foi atualizado.
Collation Conjunto de caracter e collation da tabela. (novo no 4.1.1)
Checksum Valor do checksum (se existir). (novo no 4.1.1)
Check_time A última vez que a tabela foi verificada.
Create_options Opções extras usadas com CREATE TABLE.
Comment O Comentário utilizado quando a tabela é criada (ou alguma informação do porquê do MariaDB não poder acessar a informação da tabela).

Tabelas InnoDB irão relatar o espaço livre no tablespace no comentário da tabela.

SHOW STATUS

SHOW STATUS fornece informações de status do servidor (como mysqladmin extended-status). A saída é parecida com o que está exibido abaixo, apesar dos números e formatos provavelmente serem diferentes:

+--------------------------+------------+
| Variable_name | Value |
+--------------------------+------------+
| Aborted_clients | 0 |
| Aborted_connects | 0 |
| Bytes_received | 155372598 |
| Bytes_sent | 1176560426 |
| Connections | 30023 |
| Created_tmp_disk_tables | 0 |
| Created_tmp_tables | 8340 |
| Created_tmp_files | 60 |
| Delayed_insert_threads | 0 |
| Delayed_writes | 0 |
| Delayed_errors | 0 |
| Flush_commands | 1 |
| Handler_delete | 462604 |
| Handler_read_first | 105881 |
| Handler_read_key | 27820558 |
| Handler_read_next | 390681754 |
| Handler_read_prev | 6022500 |
| Handler_read_rnd | 30546748 |
| Handler_read_rnd_next | 246216530 |
| Handler_update | 16945404 |
| Handler_write | 60356676 |
| Key_blocks_used | 14955 |
| Key_read_requests | 96854827 |
| Key_reads | 162040 |
| Key_write_requests | 7589728 |
| Key_writes | 3813196 |
| Max_used_connections | 0 |
| Not_flushed_key_blocks | 0 |
| Not_flushed_delayed_rows | 0 |
| Open_tables | 1 |
| Open_files | 2 |
| Open_streams | 0 |
| Opened_tables | 44600 |
| Questions | 2026873 |
| Select_full_join | 0 |
| Select_full_range_join | 0 |
| Select_range | 99646 |
| Select_range_check | 0 |
| Select_scan | 30802 |
| Slave_running | OFF |
| Slave_open_temp_tables | 0 |
| Slow_launch_threads | 0 |
| Slow_queries | 0 |
| Sort_merge_passes | 30 |
| Sort_range | 500 |
| Sort_rows | 30296250 |
| Sort_scan | 4650 |
| Table_locks_immediate | 1920382 |
| Table_locks_waited | 0 |
| Threads_cached | 0 |
| Threads_created | 30022 |
| Threads_connected | 1 |
| Threads_running | 1 |
| Uptime | 80380 |
+--------------------------+------------+

As variáveis de estado listadas acima tem o seguinte significado:

Variável Signficado
Aborted_clients Número de conexões abortadas porque o cliente morreu sem fechar a conexão corretamente. Leia Seção A.2.10, 'Erros de Comunicação / Comunicação Abortada'.
Aborted_connects Número de tentativas que falharam ao tentar a conexão ao servidor MySQL. Leia Seção A.2.10, 'Erros de Comunicação / Comunicação Abortada'.
Bytes_received Número de bytes recebidos por todos os clientes.
Bytes_sent Número de bytes enviados para todos os clientes..
Com_xxxx Número de vezes que os comandos xxx foram executados.
Connections Número de tentativas de conexão ao servidor MySQL.
Created_tmp_disk_tables Número de tabelas temporárias implicitas em disco criadas durante a execução de instruções.
Created_tmp_tables Número de tabelas temporárias implicitas na memória criadas durante execuções de instruções.
Created_tmp_files Quantos arquivos temporários o mysqld criou.
Delayed_insert_threads Número de threads para tratamento de insertdelayed que estão em uso.
Delayed_writes Número de registros escritos com INSERT DELAYED.
Delayed_errors Número de registros escritos com INSERT DELAYED onde algum erro ocorreu (provavelmente duplicate key).
Flush_commands Número de comandos FLUSH executados.
Handler_delete Número de vezes que um registro foi apagado da tabela.
Handler_read_first Número de vezes que a primeira entrada foi lida de um índice. Se este valor for alto, sugere que o servidor está fazendo várias leituras de índices, por exemplo, SELECT col1 FROM foo, assumindo que col1 é indexado.
Handler_read_key Número de requisições para ler um registro baseado em uma chave. Se este valor for alto, é uma boa indicação que suas pesquisas e tabelas estão indexadas corretamente.
Handler_read_next Número de requisições para ler o próximo registro na ordem da chave. Este valor será aumentado se você consultar uma coluna de índice com uma faixa restrita. Ele também aumentará se forem feitas busca nos índices.
Handler_read_prev Némro de requisições ao registros anterior na ordem da chave. Ele é principalmente usado para otimizar ORDER BY ... DESC.
Handler_read_rnd Número de requisições para ler um registro baseado em uma posição fixa. O valor será alto se você estiver executando várias pesquisas que exigem ordenação do resultado.
Handler_read_rnd_next Número de requisões para ler o próximo registro no arquivo de dados. Será alto se você estiver fazendo várias buscas na tabela. Geralmente sugere que suas tabelas não estão corretamente indexadas ou que suas pesquisas não foram escritas para tirar vantagem dos índices existentes.
Handler_rollback Números de comandos ROLLBACK internos.
Handler_update Número de requisições para atualizar um registro em uma tabela.
Handler_write Número de requisições para inserir um registro em uma tabela.
Key_blocks_used O número de blocos utilizados no cache das chaves.
Key_read_requests O número de requisições para ler um bloco de chaves do cache.
Key_reads O número de leituras físicas de blocos de chaves do disco.
Key_write_requests O número de requisições para gravar um bloco de chaves no cache.
Key_writes O número de escritas físicas de um bloco de chaves para o disco.
Max_used_connections O número máximo de conexões simultâneas que foram usadas.
Not_flushed_key_blocks Blocos de chaves no cache de chaves que foi alterado mas ainda não foi descarregado para o disco.
Not_flushed_delayed_rows Número de registros esperando para serem escritos em filas INSERT DELAY.
Open_tables Número de tabelas abertas.
Open_files Número de arquivos abertos.
Open_streams Número de fluxos abertos (usado principalmente para logs).
Opened_tables Número de tabelas que foram abertas.
Rpl_status Status de replicação segura. (Ainda não está em uso).
Select_full_join Número de joins sem chaves (Se for 0, você deve conferir com cuidado o índice de suas tabelas).
Select_full_range_join Número de joins onde foram usadas pesquisas segmentadas na tabela de referencia.
Select_range Número de joins onde foram usadas faixas da primeira tabela. (Normalmente não é crítica mesmo se o valor estiver alto.)
Select_scan Número de joins onde fizemos uma busca completa na primeira tabela.
Select_range_check Número de joins sem chaves onde o uso de chave foi conferido após cada registro (Se for 0, o índice de suas tabelas deve ser conferido com cuidado)
Questions Número de consultas enviadas para o servidor.
Slave_open_temp_tables Número de tabelas temporárias atualmente abertas pela thread slave.
Slave_running É ON se este slave está conectado a um master.
Slow_launch_threads Número de threads que levaram mais tempo do que slow_lauch_time para serem criadas.
Slow_queries Número de consultas que levaram mais tempo que long_query_time segundos. Leia 'O Log para Consultas Lentas'.
Sort_merge_passes Número de ifusões feitas pelo algorítmo de ordenação. Se este valor for alto você deve considerar o aumento de sort_buffer.
Sort_range Número de ordenações que foram feitas com limites.
Sort_rows Número de registros ordenados.
Sort_scan Número de ordenações que foram feitas lendo a tabela.
ssl_xxx Variáveis usadas por SSL; Ainda não implementado.
Table_locks_immediate Número de vezes que um travamento de tabela foi obtido de maneira automática.
Table_locks_waited Número de vezes que um bloqueio de tabela não pôde ser obtido imediatamente e foi preciso esperar. Se o valor for alto, e você tiver problemas de performance, suas consultas devem ser otimizadas e depois dividir sua tabela ou tabelas ou usar replicação. Disponível à partir da versão 3.23.33
Threads_cached Número de threads no cache de threads.
Threads_connected Número de conexões atuais abertas.
Threads_created Número de threads criadas para lidar com conexões.
Threads_running Número de threads que não estão dormindo.
Uptime Quantos segundos o servidor está funcionando.

Alguns comentários sobre a tabela acima:

SHOW VARIABLES

SHOW [GLOBAL | SESSION] VARIABLES [LIKE wild]

SHOW VARIABLES exibe os valores de algumas variáveis de sistema do MariaDB.

As opções GLOBAL e SESSION são novas no MariaDB 4.0.3. Com GLOBAL você obterá as variáveis que serão utilizadas para novas conexões ao MariaDB. Com SESSION você obterá os valores que estão em efeito para a conexão atual. Se você não estiver usando nenhuma opção, SESSION será usada.

Se os valores padrões não lhe servirem, você pode configurar a maioria destas variáveis usando as opções de linha de comando na inicialização do mysqld. Leia 'Opções de Linha de Comando do mysqld'. Você pode alterar a maioria das variáveis com o comando SET. Leia 'Sintaxe de SET'.

A saída de SHOW VARIABLES se parece com o exibido abaixo, embora o formato e os números possam divergir. Você também pode conseguir esta informação usando o comando mysqladmin variables.

+---------------------------------+------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------|
| back_log | 50 |
| basedir | /usr/local/mysql |
| bdb_cache_size | 8388572 |
| bdb_log_buffer_size | 32768 |
| bdb_home | /usr/local/mysql |
| bdb_max_lock | 10000 |
| bdb_logdir | |
| bdb_shared_data | OFF |
| bdb_tmpdir | /tmp/ |
| bdb_version | Sleepycat Software: ... |
| binlog_cache_size | 32768 |
| bulk_insert_buffer_size | 8388608 |
| character_set | latin1 |
| character_sets | latin1 big5 czech euc_kr |
| concurrent_insert | ON |
| connect_timeout | 5 |
| convert_character_set | |
| datadir | /usr/local/mysql/data/ |
| delay_key_write | ON |
| delayed_insert_limit | 100 |
| delayed_insert_timeout | 300 |
| delayed_queue_size | 1000 |
| flush | OFF |
| flush_time | 0 |
| ft_boolean_syntax | + -><()~*:''&| |
| ft_min_word_len | 4 |
| ft_max_word_len | 84 |
| ft_query_expansion_limit | 20 |
| ft_stopword_file | (built-in) |
| have_bdb | YES |
| have_innodb | YES |
| have_isam | YES |
| have_raid | NO |
| have_symlink | DISABLED |
| have_openssl | YES |
| have_query_cache | YES |
| init_file | |
| innodb_additional_mem_pool_size | 1048576 |
| innodb_buffer_pool_size | 8388608 |
| innodb_data_file_path | ibdata1:10M:autoextend |
| innodb_data_home_dir | |
| innodb_file_io_threads | 4 |
| innodb_force_recovery | 0 |
| innodb_thread_concurrency | 8 |
| innodb_flush_log_at_trx_commit | 1 |
| innodb_fast_shutdown | ON |
| innodb_flush_method | |
| innodb_lock_wait_timeout | 50 |
| innodb_log_arch_dir | |
| innodb_log_archive | OFF |
| innodb_log_buffer_size | 1048576 |
| innodb_log_file_size | 5242880 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_mirrored_log_groups | 1 |
| interactive_timeout | 28800 |
| join_buffer_size | 131072 |
| key_buffer_size | 16773120 |
| language | /usr/local/mysql/share/... |
| large_files_support | ON |
| local_infile | ON |
| locked_in_memory | OFF |
| log | OFF |
| log_update | OFF |
| log_bin | OFF |
| log_slave_updates | OFF |
| log_slow_queries | OFF |
| log_warnings | OFF |
| long_query_time | 10 |
| low_priority_updates | OFF |
| lower_case_table_names | OFF |
| max_allowed_packet | 1047552 |
| max_binlog_cache_size | 4294967295 |
| max_binlog_size | 1073741824 |
| max_connections | 100 |
| max_connect_errors | 10 |
| max_delayed_threads | 20 |
| max_heap_table_size | 16777216 |
| max_join_size | 4294967295 |
| max_relay_log_size | 0 |
| max_sort_length | 1024 |
| max_user_connections | 0 |
| max_tmp_tables | 32 |
| max_write_lock_count | 4294967295 |
| myisam_max_extra_sort_file_size | 268435456 |
| myisam_repair_threads | 1 |
| myisam_max_sort_file_size | 2147483647 |
| myisam_recover_options | force |
| myisam_sort_buffer_size | 8388608 |
| net_buffer_length | 16384 |
| net_read_timeout | 30 |
| net_retry_count | 10 |
| net_write_timeout | 60 |
| open_files_limit | 1024 |
| pid_file | /usr/local/mysql/name.pid |
| port | 3306 |
| protocol_version | 10 |
| query_cache_limit | 1048576 |
| query_cache_size | 0 |
| query_cache_type | ON |
| read_buffer_size | 131072 |
| read_rnd_buffer_size | 262144 |
| rpl_recovery_rank | 0 |
| safe_show_database | OFF |
| server_id | 0 |
| slave_net_timeout | 3600 |
| skip_external_locking | ON |
| skip_networking | OFF |
| skip_show_database | OFF |
| slow_launch_time | 2 |
| socket | /tmp/mysql.sock |
| sort_buffer_size | 2097116 |
| sql_mode | |
| table_cache | 64 |
| table_type | MYISAM |
| thread_cache_size | 3 |
| thread_stack | 131072 |
| tx_isolation | READ-COMMITTED |
| timezone | EEST |
| tmp_table_size | 33554432 |
| tmpdir | /tmp/:/mnt/hd2/tmp/ |
| version | 4.0.4-beta |
| wait_timeout | 28800 |
+---------------------------------+------------------------------+

Cada opção é descrita abaixo. Valores para tamanhos de buffer, comprimento e tamanho de pilha são fornecidos em bytes. Você pode especificar valores com sufixos 'K' ou M para indicar o valor em kilobytes ou megabytes. Por exemplo, 16M indica 16 Megabytes. Não importa se os sufixos estão em letras maiúsuculas ou minúsculas; 16M e 16m são equivalentes:

A seção do manual que descreve o ajuste do MariaDB contém algumas informações de como sintonizar as variáveis acima. Leia 'Parâmetros de Sintonia do Servidor'.

SHOW [BDB] LOGS

SHOW LOGS exibe estatísticas sobre os arquivos log existentes. Atualmente ele só exibe informações sobre arquivos de log Berkeley DB, assim um alias para ele (disponível a partir do MariaDB) é SHOW BDB LOGS.

SHOW PROCESSLIST

SHOW [FULL] PROCESSLIST exibe quais threads estão em execução. Esta informação também pode ser obtida com o comando mysqladmin processlist. Se você possuir o privilégio SUPER, poderá ver todas as threads. Senão só é possível ver as próprias threads. Leia 'Sintaxe de KILL'. Se você não utiliza a opção FULL, então somente os primeiros 100 caracteres de cada query serião exibidos.

A partir da versão 4.0.12, o MariaDB informa o nome de maquina para conexões TCP/IP no formato nome_maquina:client_port para tornar mais fácil de se encontrar qual cliente está fazendo o que.

Este comando é muito útil caso você obtenha a mensagem de erro 'too many connections' e deseja saber o que está ocorrendo. O MariaDB reserva uma conexão extra por cliente com o privilégio SUPER para garantir que você sempre consiga logar e conferir o sistema (assumindo que este privilégio não foi concedido para todos os usuários).

Alguns estados normalmente vistos em mysqladmin processlist

A maioria dos estados são operações muito rápidas. Se a thread permanecer em qualquer destes estados por muitos segundos, pode haver um problema que precisa ser investigado.

Existem outros estados que não são mencionados anteriormente, mas a maioia deles só são úteis para encontrar erros no mysqld.

SHOW GRANTS

SHOW GRANTS FOR usuário lista os comandos concedidos que devem ser usados para duplicar os direitos de um usuário.

mysql> SHOW GRANTS FOR root@localhost;
+---------------------------------------------------------------------+
| Grants for root@localhost |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+

Para listar as permissões da sessão atual pode-se usar a função CURRENT_USER() (nova na versão 4.0.6) para descobrir com qual usuário a sessão foi autenticada. Leia 'Funções Diversas'.

SHOW CREATE TABLE

Exibe uma instrução CREATE TABLE que irá criar a seguinte tabela:

mysql> SHOW CREATE TABLE t\G
*************************** 1. row ***************************
 Table: t Create Table: CREATE TABLE t (
 id INT(11) default NULL auto_increment,
 s char(60) default NULL,
 PRIMARY KEY (id)
) TYPE=MyISAM

SHOW CREATE TABLE cita os nomes de colunas e tabelas de acordo com o valor da opção SQL_QUOTE_SHOW_CREATE. Seção 5.5.6, 'Sintaxe de SET'.

SHOW WARNINGS | ERRORS

SHOW WARNINGS [LIMIT row_count]
SHOW ERRORS [LIMIT row_count]

Este comando é implementado no MariaDB 4.1.0.

Ele mostra os erros,a visos e notas recebidos para o último comando. Os erros/avisos são reiniciados para cada comando que utiliza uma tabela.

O servidor MariaDB envia de volta o número total de avisos e erros que você recebe para o último comando; Isto pode ser retornado chamando mysql_warning_count().

Até as mensagens max_error_count são armazenadas (variáveis global e específicas da thread).

Você pode recuperar o número de erros de @error_count e avisos de @warning_count.

SHOW WARNINGS mostra todos os erros, avisos e notas que você recebeu para o último comando enquanto SHOW ERRORS lhe mostra apenas o erro.

mysql> DROP TABLE IF EXISTS no_such_table;
mysql> SHOW WARNINGS;
+-------+------+-------------------------------+
| Level | Code | Message |
+-------+------+-------------------------------+
| Note | 1051 | Unknown table 'no_such_table' |
+-------+------+-------------------------------+

Note que no MariaDB 4.1.0 apenas adicionamos a estrutura para avisos e poucos comandos MariaDB ainda geraram avisos. A versão 4.1.1 suporta todos os tipos de avisos para LOAD DATA INFILE e instruções DML tais como os comandos INSERT, UPDATE e ALTER.

Por exemplo, aqui está um caso simple que produz avisos de conversão para instruções de inserção.

mysql> create table t1(a tinyint NOT NULL, b char(4));
Query OK, 0 rows affected (0.00 sec)
mysql> insert into t1 values(10,'mysql'),(NULL,'test'),(300,'open source');
Query OK, 3 rows affected, 4 warnings (0.15 sec)
Records: 3 Duplicates: 0 Warnings: 4
mysql> show warnings;
+---------+------+---------------------------------------------------------------+
| Level | Code | Message |
+---------+------+---------------------------------------------------------------+
| Warning | 1263 | Data truncated for column 'b' at row 1 |
| Warning | 1261 | Data truncated, NULL supplied to NOT NULL column 'a' at row 2 |
| Warning | 1262 | Data truncated, out of range for column 'a' at row 3 |
| Warning | 1263 | Data truncated for column 'b' at row 3 |
+---------+------+---------------------------------------------------------------+
4 rows in set (0.00 sec)

O número máximo de avisos pode ser específicado usando a variável do servidor 'max_error_count', SET max_error_count=[count]; Por padrão é 64. No caso de avisos desabilitados, simplesmente zere esta variável. No caso de max_error_count ser 0, então o contador de avisos ainda representa quantos avisos ocorreram, mas nenhuma das mensagens são armazenadas.

Por exemplo, considere o seguinte instrução de tabela ALTER para o exemplo acima, o qual retorna apenas um mensagem de aviso embora o total de avisos seja 3, ao definir max_error_count=1.

mysql> show variables like 'max_error_count';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_error_count | 64 |
+-----------------+-------+
1 row in set (0.00 sec)
mysql> set max_error_count=1;
Query OK, 0 rows affected (0.00 sec)
mysql> alter table t1 modify b char;
Query OK, 3 rows affected, 3 warnings (0.00 sec)
Records: 3 Duplicates: 0 Warnings: 3
mysql> show warnings;
+---------+------+----------------------------------------+
| Level | Code | Message |
+---------+------+----------------------------------------+
| Warning | 1263 | Data truncated for column 'b' at row 1 |
+---------+------+----------------------------------------+
1 row in set (0.00 sec)
mysql>

SHOW TABLE TYPES

SHOW TABLE TYPES

Este comando é implementado no MariaDB 4.1.0.

SHOW TABLE TYPES lhe mostra a informação de status sobre o tipo de tabela. Isto é particulamente útil para verificar se um tipo de tabela é suportado; ou para ver qual é o tipo de tabela padrão.

mysql> SHOW TABLE TYPES;
+--------+---------+-----------------------------------------------------------+
| Type | Support | Comment |
+--------+---------+-----------------------------------------------------------+
| MyISAM | DEFAULT | Default type from 3.23 with great performance |
| HEAP | YES | Hash based, stored in memory, useful for temporary tables |
| MERGE | YES | Collection of identical MyISAM tables |
| ISAM | YES | Obsolete table type; Is replaced by MyISAM |
| InnoDB | YES | Supports transactions, row-level locking and foreign keys |
| BDB | NO | Supports transactions and page-level locking |
+--------+---------+-----------------------------------------------------------+
6 rows in set (0.00 sec)

A opção 'Support' DEFAULT indica se um tipo de tabela particular é é suportado, e qual é o tipo padrão. Se o servidor é iniciado com --default-table-type=InnoDB, então o campo 'Support' do InnoDB terá o valor DEFAULT.

SHOW PRIVILEGES

SHOW PRIVILEGES

Este comando é implementado no MariaDB 4.1.0.

SHOW PRIVILEGES mostra a lista de privilégios de sistema o servidor MariaDB suporta.

mysql> show privileges;
+------------+--------------------------+-------------------------------------------------------+
| Privilege | Context | Comment |
+------------+--------------------------+-------------------------------------------------------+
| Select | Tables | To retrieve rows from table |
| Insert | Tables | To insert data into tables |
| Update | Tables | To update existing rows |
| Delete | Tables | To delete existing rows |
| Index | Tables | To create or drop indexes |
| Alter | Tables | To alter the table |
| Create | Databases,Tables,Indexes | To create new databases and tables |
| Drop | Databases,Tables | To drop databases and tables |
| Grant | Databases,Tables | To give to other users those privileges you possess |
| References | Databases,Tables | To have references on tables |
| Reload | Server Admin | To reload or refresh tables, logs and privileges |
| Shutdown | Server Admin | To shutdown the server |
| Process | Server Admin | To view the plain text of currently executing queries |
| File | File access on server | To read and write files on the server |
+------------+--------------------------+-------------------------------------------------------+
14 rows in set (0.00 sec)

Localização do MariaDB e Utilização Internacional

O Conjunto de Caracteres Utilizado para Dados e Ordenação
Mensagens de Erros em Outras Línguas
Adicionando um Novo Conjunto de Caracteres
Os Vetores de Definições de Caracteres
Suporte à Ordenação de Strings
Suporte à Caracteres Multi-byte
Problemas com Conjuntos de Caracteres

O Conjunto de Caracteres Utilizado para Dados e Ordenação

German character set

Por padrão, o MariaDB utiliza o conjunto de caracteres ISO-8859-1 (Latin1) com ordenação de acordo com o sueco/finlandês. Este também é o conjunto de caracteres aplicável nos EUA e oeste da Europa.

Todos os binários padrões do MariaDB são compilados com --with-extra-charsets=complex. Isto adicionará código a todos os programas padrões para estarem aptos a lidar com o conjuntos de caracteres latin1 e todos os multi-byte no binário. Outros conjuntos de caracteres serão carregados de um arquivo de definições de conjuntos de caracteres quando necessários.

O conjunto de caracteres determina quais são os caracteres permitidos em nomes e qual a forma de ordenação por cláusulas ORDER BY e GROUP BY da instrução SELECT.

Você pode alterar o conjunto de caracteres com a opção --default-character-set na inicialização do servidor. Os conjuntos de caracteres disponíveis dependem dos parâmetros --with-charset=charset e --with-extra-charset= list-of-charset | complex | all | none e os arquivos de configurações de conjuntos de caracteres listados em SHAREDIR/charsets/ Index. Leia 'Opções típicas do configure'.

Se o conjunto de caracteres for alterado durante a execução do MariaDB (que também pode alterar a ordenação), deve-se executar o 0myisamchk -r -q --set-character-set=charset em todas as tabelas. De outra forma seus índices podem não ser ordenados corretamente.

Quando um cliente conecta a um servidor MySQL, o servidor envia o conjunto de caracteres padrão em uso ao cliente. O cliente irá alternar para o uso deste conjunto de caracteres nesta conexão.

Deve ser utilizado mysql_real_escape_string() quando desejar ignorar seguências de caracteres em uma consulta SQL. mysql_real_escape_string() é identico à antiga função mysql_espace_string(), exceto pelo fato de usar a manipulador de conexão MariaDB como o primeiro parâmetro.

Se o cliente for compilado com o caminho diferente daquele onde o servidor está instalado e o usuário que configurou o MariaDB não incluiu todos os conjuntos de caracteres no binários do MariaDB, deve ser especificado para o cliente onde ele pode encontrar os conjuntos de caracteres adcicionais que serão necessários se o servidor executar com um conjunto de caracteres diferente do cliente.

Isto pode ser especificado colocando em um arquivo de opções do MariaDB:

[client]
character-sets-dir=/usr/local/mysql/share/mysql/charsets

onde o caminho aponta para onde os conjuntos de caracteres dinâmicos do MariaDB são armazenados.

Pode-se forçar o cliente a usar conjuntos de caracteres específicos especificando:

[client]
default-character-set=nome-conjunto-caracteres

mas normalmente isto nunca será necessário.

German character set

Para se fazer ordenação em Alemão, você deve iniciar o mysqld com --default-character-set=latin1_de. Isto lhe dará as seguintes caracteristicas.

Ao ordenar e comparar strings, o seguinte mapeamento é feito na string antes de fazer a comparação:

ä -> ae
ö -> oe
ü -> ue
ß -> ss

Todos os caracteres acentuados, são convertidos para suas contra partes sem acentos e em letras maiúsculas. Todas as letras são convertidas para maiúsculas.

Ao compara strings com LIKE o mapeamento de caracteres de um -> dois não é feito. Todas as letras são convertidas para maiúsculas. Acentos são removidos para todas as letras exceto: Ü, ü, Ö, ö, Ä e ä.

Mensagens de Erros em Outras Línguas

mysqld pode exibir mensagens de erros nas seguintes línguas: Tcheco, Dinamarquês, Holandês, Inglês (padrão), Estonian, Francês, Alemão, Grego, Húngaro, Italiano, Japonês, Koreano, Norueguês, Norueguês-ny, Polonês, Português, Romeno, Russo, Eslovaco, Espanhol e Sueco.

Para iniciar o mysqld com uma língua particular, use uma das opções: --language=língua ou -L língua . Por exemplo:

shell> mysqld --language=swedish

ou:

shell> mysqld --language=/usr/local/share/swedish

Perceba que todos as línguas são especificados em minúsculas.

Os arquivos de linguagens estão localizados (por padrão) em mysql_base_dir/share/LANGUAGE/.

Para atualizar o arquivo com mensagens de erros, deve-se editar o arquivo errmsg.txt e executar o seguinte comando para gerar o arquivo errmsg.sys:

shell> comp_err errmsg.txt errmsg.sys

Se você atualizar o MariaDB para uma versão mais nova, lembre-se de repetir as alterações no novo arquivo errmsg.txt.

Adicionando um Novo Conjunto de Caracteres

Para adicionar outro conjunto de caracteres ao MySQL, utilize o seguinte procedimento.

Decida se o conjunto é simples ou complexo. Se o conjunto de caracteres não necessitar do uso de rotinas especiais de classificação de strings para ordenação e também não necessitar de suporte à caracteres multi-byte, será simples. Se ele necessitar de alguns destes recursos, será complexo.

Por exemplo, latin1 e danish são conjuntos simples de caracteres enquanto big5 ou czech são conjuntos de caracteres complexos.

Na seguinte seção, assumimos que você nomeou seu conjunto de caracteres como MYSET.

Para um conjunto de caracteres simples use o seguinte:

  1. Adicione MYSET para o final do arquivo sql/share/charsets/Index Associe um número único ao mesmo.
  2. Crie o arquivo sql/share/charsets/MYSET.conf. (O arquivo sql/share/charsets/latin1.conf pode ser utilizado como base para isto).

    A sintaxe para o arquivo é muito simples:

    • Comentários iniciam com um caractere '#' e continuam até o fim da linha.
    • Palavras são separadas por quantidades arbitrárias de espaços em brancos.
    • Ao definir o conjunto de caracteres, cada palavra deve ser um número no formato hexadecimal
    • O vetor ctype obtêm as primeiras 257 palavras. Os vetores to_lower, to_upper e sort_order obtêm, cada um, as 256 palavras seguintes.

    See 'Os Vetores de Definições de Caracteres'.

  3. Adicione o nome do conjunto de caracteres às listas CHARSETS_AVAILABLE e COMPILED_CHARSETS no configure.in.
  4. Reconfigure, recompile e teste.

Para um conjunto de caracteres complexo faça o seguinte:

  1. Crie o arquivo strings/ctype-MYSET.c na distribuição fonte do MYSQL.
  2. Adicione MYSET ao final do arquivo sql/share/charsets/Index. Associe um número único a ele.
  3. Procure por um dos arquivos ctype-*.c existentes para ver o que precisa ser definido, por exemplo strings/ctype-big5.c. Perceba que os vetores no seu arquivo deve ter nomes como ctype_MYSET, to_lower_MYSET e etc. Isto corresponde aos arrays no conjunto simples de caracteres - 'Os Vetores de Definições de Caracteres' - para um conjunto de caracteres complexo.
  4. Próximo ao topo do arquivo, coloque um comentário especial como este: 

    /*
 * This comment is parsed by configure to create ctype.c,
 * so don't change it unless you know what you are doing.
 *
 * .configure. number_MYSET=MYNUMBER
 * .configure. strxfrm_multiply_MYSET=N
 * .configure. mbmaxlen_MYSET=N
 */

    O programa configure utiliza este comentário para incluir o conjunto de caracteres na biblioteca MariaDB automaticamente.

    As linhas strxfrm_multiply e mbmaxlen serão explicadas nas próximas seções. Só as inclua se você precisar de funções de ordenação de strings ou das funções de conjuntos de caracteres multi-byte, respectivamente.

  5. Você deve então criar algumas das seguintes funções:

    • my_strncoll_MYSET()
    • my_strcoll_MYSET()
    • my_strxfrm_MYSET()
    • my_like_range_MYSET()

    See 'Suporte à Ordenação de Strings'.

  6. Adicione o nome do conjunto de caracteres às listas CHARSETS_AVAILABLE e COMPILED_CHARSETS no configure.in.
  7. Reconfigure, recompile e teste.

O arquivo sql/share/charsets/README fornece algumas instruções a mais.

Se você desejar ter o seu conjunto de caracteres incluído na distribuição MySQL, envie um email com um patch para a lista de email internals do MariaDB. Leia 'As Listas de Discussão do MariaDB'.

Os Vetores de Definições de Caracteres

to_lower[] e to_upper[] são vetores simples que definemm os caracteres minúsculos e maísculos correspondentes a cada membro do conjunto de caracteres. Por exemplo:

to_lower['A'] deve conter 'a'
to_upper['a'] deve conter 'A'

sort_order[] é um mapa indicando como os caracteres devem ser ordenados para propósitos de comparação e ordenação. Para vários conjuntos de caracteres, isto é o mesmo que to_upper[] (que significa ordenar em caso insensitivo). O MariaDB ordenará caracteres baseado no valor de sort_order[caractere]. Para regras mais complicadas de ordenação, veja a discussão sobre ordenação de string abaixo. Leia 'Suporte à Ordenação de Strings'.

ctype[] é um vetor com valores binários, com um elemento para cada caracter. (Note que to_lower[], to_upper[] e sort_order[] são indexados pelo valor do caracter, mas o ctype[] é indexado pelo valor do caracter + 1. Este é um antigo legado para tratamento de EOF.)

Pode-se encontrar as seguintes máscaras binárias de definições em m_ctype.h:

#define _U 01 /* Maísculo */
#define _L 02 /* Minúsculo */
#define _N 04 /* Numeral (digito) */
#define _S 010 /* Caractere de espaço */
#define _P 020 /* Pontuação */
#define _C 040 /* Caractere de controle */
#define _B 0100 /* Branco */
#define _X 0200 /* Digito heXadecimal */

A entrada ctype[] para cada caracter deve ser a união dos valores da máscara binária que descrevem o caracter. Por exemplo, 'A' é um caracter maiúsculo (_U) bem como um dígito hexadecimal (_X), portanto ctype['A'+1] deve conter o valor:

_U + _X = 01 + 0200 = 0201

Suporte à Ordenação de Strings

Se as regras de ordenação para a sua linguagem forem muito complexas para serem tratadas com uma simples tabela sort_order[], será necessário o uso das funções de ordenação de strings.

No momento, a melhor documentação sobre isto são os conjuntos de caracteres que já estão implementados. Confira os conjuntos de caracteres big5, czech, gbk, sjis e tis160 para exemplos.

Você deve especificar o valor strxfrm_multiply_MYSET=N no comentário especial no topo do arquivo. N deve ser configurado para a razão máxima que as strings podem crescer durante my_strxfrm_MYSET (ele deve ser um inteiro positivo).

Suporte à Caracteres Multi-byte

Se você deseja adicionar suporte para novos conjuntos de caracteres que incluem caracteres multi-byte, você precisa usar as funções para caracteres multi-byte.

No momento, a melhor documentação sobre isto são os conjuntos de caracteres que já estão implementados. Confira os conjuntos de caracteres euc_kr, gb2312, gbk, sjis e ujis para exemplos. Eles são implementados no arquivo ctype-'conj_caracter'.c no diretório strings

Você deve especificar o valor mbmaxlen_MYSET=N no comentário especial no topo do arquivo. N deve ser configurado como o tamanho em bytes do maior caracter no conjunto.

Problemas com Conjuntos de Caracteres

Se você tentar usar um conjunto de caractere que não foi compilado dentro do se binário, você pode encontrar aluguns problemas:

Para tabelas MyISAM, você pode vericifcar o nome e número do conjunto de caracteres para uma tabela com myisamchk -dvv nome_tabela.

Utilitários e Scripts do Lado do Servidor MariaDB

Visão Geral dos Scripts e Utilitários do Lado Servidor
mysqld-safe, o wrapper do mysqld
mysqld_multi, programa para gerenciar múltiplos servidores MySQL
myisampack, O Gerador de Tabelas Compactadas de Somente Leitura do MariaDB
mysqld-max, om servidor mysqld extendido

Visão Geral dos Scripts e Utilitários do Lado Servidor

Todos os programas MariaDB possuem várias opções diferentes, entretanto, todo programa MariaDB fornece uma opção --help que pode ser usada para obter uma descrição completa das diferentes opções do programa. Por exemplo, experimente mysql --help.

Você pode sobrepor ignorar as opções padrões para todos os programas clientes com um arquivo de opções. 'Arquivo de Opções my.cnf'.

A lista abaixo descreve brevemente os programas MySQL.

mysqld-safe, o wrapper do mysqld

mysqld_safe é a maneira recomendada para iniciar um daemon mysqld no Unix. mysqld_safe adiciona alguns recursos de segurança tais como reiniciar o servidor quando um erro ocorrer e log de informações de tempo de execução a um arquivo log.

Note: Antes do MariaDB 4.0, mysqld_safe é chamado safe_mysqld. Para preservar a compatibilidade com versões anteriores, a distribuição binária do MariaDB para algumas vezes incluirá safe_mysqld como um link simbólico para mysqld_safe.

Se você não utilizar --mysqld=# ou --mysql-version=# o mysqld_safe irá utilizar um executável chamado mysqld-max se ele existir. Se não, mysqld_safe irá iniciar o mysqld. Isto torna muito fácil utilizar o mysql-max no lugar do mysqld; basta copiar mysqld-max no mesmo diretório do mysqld e ele será utillizado.

Normalmente o script mysqld_safe nunca deve ser editado, em vez disto, coloque as opções para o mysqld_safe na seção [mysqld_safe] no arquivo my.cnf. O mysqld_safe irá ler todas as opções das seções [mysqld], [server] e [mysqld_safe] dos arquivos de opções. (Para compatibilidade com versões anteriores, ele também lê as seções [safe_mysqld].) Leia 'Arquivo de Opções my.cnf'.

Note que todas as opções na linha de comando para o mysqld_safe são passadas para o mysqld. Se você deseja usar algumas opções no mysqld_safe que o mysqld não suporte, você deve especificá-las no arquivo de opções.

A maioria das opções para mysqld_safe são as mesmas que as do mysqld. Leia Seção 4.1.1, 'Opções de Linha de Comando do mysqld'.

mysqld_safe suporta as seguintes opções:

O script mysqld_safe é gravável, portanto ele deve estar apto para iniciar um servidor que foi instalado de uma fonte ou uma versão binária do MariaDB, mesmo se o servidor estiver instalado em localizações um pouco diferentes. mysqld_safe espera uma destas condições ser verdadeira:

Como o mysqld_safe tentará encontrar o servidor e o banco de dados relativo a seu diretório de trabalho, você pode instalar uma distribuição binária do MariaDB em qualquer lugar, desde de que o mysqld_safe seja iniciado a partir do diretório da instalação:

shell> cd diretório_instalação_mysql
shell> bin/mysqld_safe &

Se o mysqld_safe falhar, mesmo se invocado a partir do diretório de instalação do MariaDB, você pode modificá-lo para usar o caminho para o mysqld e as opções de caminho que seriam corretas para seu sistema. Perceba que se você atualizar o MariaDB no futuro, sua versão modificada de mysqld_safe será sobrescrita, portanto, você deve fazer uma cópia de sua versão editada para que você a possa reinstalar.

mysqld_multi, programa para gerenciar múltiplos servidores MariaDB

mysqld_multi gerencia vários processos mysqld executando em diferentes sockets UNIX e portas TCP/IP.

O programa irá pesquisar pelos grupos chamados [mysqld#] no my.cnf (ou no arquivo fornecido no parâmetro --config-file=...), onde # pode ser qualquer número positivo a partir de 1. Este número é referenciado a seguir como número do grupo de opções ou GNR. Números de grupos distinguem grupos de opções para um outro e são usados como argumentos para mysqld_multi para especificar quais servidores você deseja iniciar, parar ou obter status. Opções listadas nestes grupos devem ser a mesma que você usaria para iniciar o mysqld. (see 'Inicializando e parando o MariaDB automaticamente.'). No entanto, para o mysqld_multi, esteja certo que cada grupo inclui opções de valores tais como a porta, socket, etc., para ser usado para cada processo mysqld individual.

Uso: mysqld_multi [OPÇÕES] {start|stop|report} [GNR,GNR,GNR...]
ou mysqld_multi [OPÇÕES] {start|stop|report} [GNR-GNR,GNR,GNR-GNR,...]

O GNR acima significa o número do grupo. Você pode iniciar, parar ou relacionar qualquer GNR ou vários deles ao mesmo tempo. (Veja --example). A lista dos GNR podem ser separadas por vírgulas, ou pelo sinal sinal de menos (-), sendo que o ultimo significa que todos os GNRS entre GNR1-GNR2 serão afetados. Sem o argumento GNR todos os grupos encontrados serão iniciados, parados ou listados. Perceba que você não deve ter nenhum espaço em branco na lista GNR. Qualquer coisa depois de um espaço em branco é ignorado.

mysqld_multi suporta as seguintes opções:

Algumas notas sobre mysqld_multi:

See 'Executando Múltiplos MariaDB Servers na Mesma Máquina'.

Este é um exemplo do arquivo de configuração para o funcionamento do mysqld_multi.

# Este arquivo provavelmente deve estar em seu diretório home (~/.my.cnf) ou /etc/my.cnf
# Version 2.1 by Jani Tolonen
[mysqld_multi]
mysqld = /usr/local/bin/mysqld_safe mysqladmin = /usr/local/bin/mysqladmin user = multi_admin password = multipass
[mysqld2]
socket = /tmp/mysql.sock2
port = 3307
pid-file = /usr/local/mysql/var2/hostname.pid2
datadir = /usr/local/mysql/var2
language = /usr/local/share/mysql/english user = john
[mysqld3]
socket = /tmp/mysql.sock3
port = 3308
pid-file = /usr/local/mysql/var3/hostname.pid3
datadir = /usr/local/mysql/var3
language = /usr/local/share/mysql/swedish user = monty
[mysqld4]
socket = /tmp/mysql.sock4
port = 3309
pid-file = /usr/local/mysql/var4/hostname.pid4
datadir = /usr/local/mysql/var4
language = /usr/local/share/mysql/estonia user = tonu
[mysqld6]
socket = /tmp/mysql.sock6
port = 3311
pid-file = /usr/local/mysql/var6/hostname.pid6
datadir = /usr/local/mysql/var6
language = /usr/local/share/mysql/japanese user = jani

See 'Arquivo de Opções my.cnf'.

myisampack, O Gerador de Tabelas Compactadas de Somente Leitura do MariaDB

myisampack é usado para compactar tabelas MyISAM, e pack_isam é usado para compactar tabelas ISAM. Como as tabelas ISAM estão ultrapassadas, nós iremos discutir aqui somente sobre o myisampack, mas tudo dito sobre myisampack também pode ser verdadeiro para o pack_isam.

myisampack trabalha compactando cada coluna na tabela separadamente. A informação necessária para descompactar colunas é lida em memória quando a tabela é aberta. Isto resulta em uma performance muito melhor quando estiver acessando registros individuais, porque você precisará descompactar somente um registro, não um bloco muito maior do disco como faz o Stacker no MS-DOS. Normalmente, myisampack compacta o arquivo de dados 40%-70%.

O MariaDB utiliza mapeamento de memória (nmap()) em tabelas compactadas e retorna ao uso normal de leitura e escrita se nmap() não funcionar.

Por favor, note o seguinte:

myisampack é chamado desta forma:

shell> myisampack [opções] nome_arquivo ...

Cada nome_arquivo deve ter o nome de um arquivo de índice (.MYI). Se você não se encontra em um diretório de bancos de dados, você deve especificar o caminho completo para o arquivo. Pode-se omitir a extensão .MYI.

myisampack suporta as seguintes opções:

A seqüência de comandos mostrados abaixo ilustra uma típica seção de compactação de tabelas:

shell> ls -l station.*
-rw-rw-r-- 1 monty my 994128 Apr 17 19:00 station.MYD
-rw-rw-r-- 1 monty my 53248 Apr 17 19:00 station.MYI
-rw-rw-r-- 1 monty my 5767 Apr 17 19:00 station.frm shell> myisamchk -dvv station
MyISAM file: station Isam-version: 2
Creation time: 1996-03-13 10:08:58
Recover time: 1997-02-02 3:06:43
Data records: 1192 Deleted blocks: 0
Datafile: Parts: 1192 Deleted data: 0
Datafile pointer (bytes): 2 Keyfile pointer (bytes): 2
Max datafile length: 54657023 Max keyfile length: 33554431
Recordlength: 834
Record format: Fixed length table description:
Key Start Len Index Type Root Blocksize Rec/key
1 2 4 unique unsigned long 1024 1024 1
2 32 30 multip. text 10240 1024 1
Field Start Length Type
1 1 1
2 2 4
3 6 4
4 10 1
5 11 20
6 31 1
7 32 30
8 62 35
9 97 35
10 132 35
11 167 4
12 171 16
13 187 35
14 222 4
15 226 16
16 242 20
17 262 20
18 282 20
19 302 30
20 332 4
21 336 4
22 340 1
23 341 8
24 349 8
25 357 8
26 365 2
27 367 2
28 369 4
29 373 4
30 377 1
31 378 2
32 380 8
33 388 4
34 392 4
35 396 4
36 400 4
37 404 1
38 405 4
39 409 4
40 413 4
41 417 4
42 421 4
43 425 4
44 429 20
45 449 30
46 479 1
47 480 1
48 481 79
49 560 79
50 639 79
51 718 79
52 797 8
53 805 1
54 806 1
55 807 20
56 827 4
57 831 4
shell> myisampack station.MYI
Compressing station.MYI: (1192 records)
- Calculating statistics normal: 20 empty-space: 16 empty-zero: 12 empty-fill: 11
pre-space: 0 end-space: 12 table-lookups: 5 zero: 7
Original trees: 57 After join: 17
- Compressing file
87.14%
shell> ls -l station.*
-rw-rw-r-- 1 monty my 127874 Apr 17 19:00 station.MYD
-rw-rw-r-- 1 monty my 55296 Apr 17 19:04 station.MYI
-rw-rw-r-- 1 monty my 5767 Apr 17 19:00 station.frm shell> myisamchk -dvv station
MyISAM file: station Isam-version: 2
Creation time: 1996-03-13 10:08:58
Recover time: 1997-04-17 19:04:26
Data records: 1192 Deleted blocks: 0
Datafile: Parts: 1192 Deleted data: 0
Datafilepointer (bytes): 3 Keyfile pointer (bytes): 1
Max datafile length: 16777215 Max keyfile length: 131071
Recordlength: 834
Record format: Compressed table description:
Key Start Len Index Type Root Blocksize Rec/key
1 2 4 unique unsigned long 10240 1024 1
2 32 30 multip. text 54272 1024 1
Field Start Length Type Huff tree Bits
1 1 1 constant 1 0
2 2 4 zerofill(1) 2 9
3 6 4 no zeros, zerofill(1) 2 9
4 10 1 3 9
5 11 20 table-lookup 4 0
6 31 1 3 9
7 32 30 no endspace, not_always 5 9
8 62 35 no endspace, not_always, no empty 6 9
9 97 35 no empty 7 9
10 132 35 no endspace, not_always, no empty 6 9
11 167 4 zerofill(1) 2 9
12 171 16 no endspace, not_always, no empty 5 9
13 187 35 no endspace, not_always, no empty 6 9
14 222 4 zerofill(1) 2 9
15 226 16 no endspace, not_always, no empty 5 9
16 242 20 no endspace, not_always 8 9
17 262 20 no endspace, no empty 8 9
18 282 20 no endspace, no empty 5 9
19 302 30 no endspace, no empty 6 9
20 332 4 always zero 2 9
21 336 4 always zero 2 9
22 340 1 3 9
23 341 8 table-lookup 9 0
24 349 8 table-lookup 10 0
25 357 8 always zero 2 9
26 365 2 2 9
27 367 2 no zeros, zerofill(1) 2 9
28 369 4 no zeros, zerofill(1) 2 9
29 373 4 table-lookup 11 0
30 377 1 3 9
31 378 2 no zeros, zerofill(1) 2 9
32 380 8 no zeros 2 9
33 388 4 always zero 2 9
34 392 4 table-lookup 12 0
35 396 4 no zeros, zerofill(1) 13 9
36 400 4 no zeros, zerofill(1) 2 9
37 404 1 2 9
38 405 4 no zeros 2 9
39 409 4 always zero 2 9
40 413 4 no zeros 2 9
41 417 4 always zero 2 9
42 421 4 no zeros 2 9
43 425 4 always zero 2 9
44 429 20 no empty 3 9
45 449 30 no empty 3 9
46 479 1 14 4
47 480 1 14 4
48 481 79 no endspace, no empty 15 9
49 560 79 no empty 2 9
50 639 79 no empty 2 9
51 718 79 no endspace 16 9
52 797 8 no empty 2 9
53 805 1 17 1
54 806 1 3 9
55 807 20 no empty 3 9
56 827 4 no zeros, zerofill(2) 2 9
57 831 4 no zeros, zerofill(1) 2 9

A informação exibida pelo myisampack é descrita abaixo:

Depois que uma tabela foi compactada, myisamchk -dvv exibe informações adicionais sobre cada campo:

Depois de ter executado pack_isam/myisampack você deve executar o isamchk/myisamchk para recriar o índice. Neste momento você pode também ordenar os blocos de índices para criar estatísticas necessárias para o otimizador do MariaDB trabalhar de maneira mais eficiente.

myisamchk -rq --analyze --sort-index nome_tabela.MYI isamchk -rq --analyze --sort-index nome_tabela.ISM

Depois de instalar a tabela compactada no diretório de banco de dados MariaDB você deve fazer mysqladmin flush-tables para forçar o mysqld a iniciar usando a nova tabela.

Se você desejar descompactar uma tabela compactada, você pode fazer isto com a opção --unpack para o isamchk ou myisamchk.

mysqld-max, om servidor mysqld extendido

mysqld-max é o servidor MariaDB (mysqld) configurado com as seguintes opções de configuração:

Opção Comentário
--with-server-suffix=-max Adiciona um sufixo à string de versão mysqld
--with-innodb Suporte a tabelas InnoDB
--with-bdb Suporte para tabelas Berkeley DB (BDB)
CFLAGS=-DUSE_SYMDIR Suporte a links simbólicos para Windows

A opção para habilitar o suporte ao InnoDB é necessário apenas no MariaDB 3.23. No MariaDB 4 e acima, o InnoDB já é incluído por padrão.

Você pode encontrar os binários do MariaDB-max em http://www.mysql.com/downloads/mysql-max-4.0.html.

A distribuição binária Windows MariaDB 3.23 inclui tanto o binário mysqld.exe padrão e o binário mysqld-max.exe. http://www.mysql.com/downloads/mysql-4.0.html. Leia 'Instalando o MariaDB no Windows'.

Note que como o Berkeley DB (BDB) não está disponível para todas plataformas, alguns dos binários Max podem não ter suporte para ela. Você pode conferir quais tipos de tabelas são suportadas executando a seguinte consulta:

mysql> SHOW VARIABLES LIKE 'have_%';
+------------------+----------+
| Variable_name | Value |
+------------------+----------+
| have_bdb | NO |
| have_crypt | YES |
| have_innodb | YES |
| have_isam | YES |
| have_raid | NO |
| have_symlink | DISABLED |
| have_openssl | NO |
| have_query_cache | YES |
+------------------+----------+

O significado dos valores na segunda coluna são:

Valor Significado.
YES A opção está ativa e é utilizada.
NO O MariaDB não está compilado com suporte a esta opção.
DISABLED A opção xxx está desabilitada porque o mysqld foi iniciado com --skip-xxxx ou porque não foi iniciado com todas as opções necessárias para habilitar esta opção. Neste caso o arquivo hostname.err deve conter uma razão indicando o porque da opção estar desabilitada.

NOTA: Para conseguir criar tabelas InnoDB você DEVE editar suas opções de inicialização para incluir ao menos a opção innodb_data_file_path. Leia 'InnoDB no MariaDB Versão 3.23'.

Para obter melhor performance para tabelas BDB, você deve adicionar algumas opções de configuração para elas também .See 'Opções de Inicialização do BDB'.

mysqld_safe tenta iniciar automaticamente qualquer binário mysqld com o prefixo -max. Isto faz com que seja fácil testar um outro binário mysqld em uma instalação existente. Apenas execute o configure com as opções deseejadas e, então, instale o novo binário mysqld como mysqld-max no mesmo diretório onde seu antigo binário mysqld está. Leia 'mysqld-safe, o wrapper do mysqld'.

No Linux, o RPM mysqld-max utiliza o recurso mysqld_safe já mencionado. (Ele apenas instala o executável mysqld-max e o mysqld_safe usará automaticamente este executável quando o mysqld_safe for reiniciado).

A tabela a seguir mostra quais tipos de tabelas nossos binários MySQL-Max incluem:

Sistema BDB InnoDB
Windows/NT S S
AIX 4.3 N S
HP-UX 11.0 N S
Linux-Alpha N S
Linux-Intel S S
Linux-IA-64 N S
Solaris-Intel N S
Solaris-SPARC S S
SCO OSR5 S S
UnixWare S S
Mac OS X N S

Note que a partir do MariaDB 4, você não precisa de um servidos MariaDB Max para o InnoDB porque ele é incluído por padrão.

Utilitários e Scripts do Lado do Cliente MariaDB

Visão Geral dos Utilitários e Scripts do Lado do Cliente
MariaDB, A Ferramenta de Linha de Comando
mysqlcc, The MariaDB Control Center
mysqladmin, Administrando um Servidor MySQL
mysqlbinlog, Executando as Consultas a Partir de um Log Binário
Usando mysqlcheck para Manutenção de Tabelas e Recuperação em Caso de Falhas
mysqldump, Descarregando a Estrutura de Tabelas e Dados
mysqlhotcopy, Copiando Bancos de Dados e Tabelas do MariaDB
mysqlimport, Importando Dados de Arquivos Texto
mysqlshow, Exibindo Bancos de Dados, Tabelas e Colunas
mysql_config, Opções para compilação do cliente MySQL
perror, Explicando Códigos de Erros
Como Executar Comandos SQL a Partir de um Arquivo Texto

Visão Geral dos Utilitários e Scripts do Lado do Cliente

Todos clientes MariaDB que comunicam com o servidor utilizando a biblioteca mysqlclient utilizam as seguintes variáveis de ambiente:

Nome Descrição
MYSQL_UNIX_PORT O socket padrão, utilizado para conexões ao localhost
MYSQL_TCP_PORT A porta TCP/IP padrão
MYSQL_PWD A senha padrão
MYSQL_DEBUG Opções de depuração-ratreamento durante depuração
TMPDIR O diretório onde tabelas e arquivos temporários são criados

A utilização de MYSQL_PWD é insegura. Leia 'Conectando ao Servidor MySQL'.

No Unix, o cliente MariaDB utiliza o arquivo nomeado na variável de ambiente MYSQL_HISTFILE para salvar o histórico da linha de comando. O valor padrão para o arquivo de histórico é $HOME/.mysql_history, onde $HOME é o valor da variável de ambiente HOME. Leia Apêndice F, Variáveis de Ambientes do MariaDB.

Se você não quiser manter um arquivo que contenh um registro de suas consultas, primeiro remova .mysql_history se ele existir, então use uma das seguintes técnicas:

Todos os programas MariaDB podem receber várias opções diferentes. Entretanto, todo programa MariaDB fornece a opção --help que você pode utilizar para obter uma descrição completa das diferentes opções do programa. Por exemplo, experimente mysql --help

Você pode sobrepor todas as opções padrões para programas cliente padrões com um arquivo de opções. 'Arquivo de Opções my.cnf'

A lista abaixo descreve resumidamente os programas MySQL:

MariaDB, A Ferramenta de Linha de Comando

O MariaDB é uma shell SQL simples (com capacidades GNU readline). Ele suporta usos interativos e não interativos. Quando usado interativamente, os resultados das consultas são apresentadas no formato de tabela ASCII. Quando não usado interativamente (como um filtro por exemplo), o resultado é apresentado em um formato separado por tabulações. (O formato de saída pode ser alterado utilizando opções da linha de comando.) Você pode executar scripts desta forma:

shell> mysql database < script.sql > saida.tab

Se você tiver problemas devido a memória insuficiente no cliente, utilize a opção --quick! Isto força o MariaDB a utilizar mysql_use_result() no lugar de mysql_store_result() para recuperar o conjunto de resultados.

Utilizar o MariaDB é muito fáci. Inicie-o como mostrado a seguir: mysql banco_de_dados ou mysql --user=nome_usuário --password=sua_senha banco_de_dados. Digite uma instrução SQL, termine-a com ';', '\g', ou '\G' e pressione RETURN/ENTER.

O MariaDB Suporta as seguintes opções:

Você também pode configurar as seguntes variáveis com -O ou --set-variable. Por favor, note que as sintaxes --set-variable=nome=valor e -O name=value estão obsoletas desde o MariaDB 4.0, use --var=option:

Nome Variável Padrão Descrição
connect_timeout 0 Número de seguntos antes de esgotar o tempo da conexão
local-infile 0 Disabilita (0) ou habilita (1) capacidade LOCAL para LOAD DATA INFILE
max_allowed_packet 16777216 Tamanho máximo do pacote para enviar/receber do servidor
net_buffer_length 16384 Tamanho do buffer para comunicação TCP/IP e socket
select_limit 1000 Limite automático para SELECT quando utilizar --safe-updtaes
max_join_size 1000000 Limite automático para registros em uma join quando utilizar --safe-updtaes.

Se o cliente MariaDB perder a conexào com o servidor enquanto envia uma consulta, ele tentará se reconectar imediatamente e automaticamente uma vez e enviar a consulta novamente. Note que mesmo se ele obter sucesso na reconexão, como sua primeira conexão foi finalizada, todas seus objetos da sessão anteriores foram perdidos: tabelas temporárias, e variáveis de sessão e de usuário. Desta forma, o comportamento acima pode ser perigoso para você, como neste exemplo onde o servidor foi desligado e reiniciado sem você saber:

mysql> set @a=1;
Query OK, 0 rows affected (0.05 sec)
mysql> insert into t values(@a);
ERROR 2006: MariaDB server has gone away No connection. Trying to reconnect...
Connection id: 1
Current database: test Query OK, 1 row affected (1.30 sec)
mysql> select * from t;
+------+
| a |
+------+
| NULL |
+------+
1 row in set (0.05 sec)

A variável de usuário @a foi perdida com a conexão e depois da reconexão ela é indefinida. Para se proteger deste risco, você pode iniciar o cliente MariaDB com a opção --disable-reconnect.

Se você digitar 'help' na linha de comando, MariaDB irá exibir os comandos que ele suporta:

mysql> help
MySQL commands:
help (\h) Display this text.
? (\h) Synonym for `help'.
clear (\c) Clear command.
connect (\r) Reconnect to the server.
 Optional arguments are db and host.
delimiter (\d) Set query delimiter.
edit (\e) Edit command with $EDITOR.
ego (\G) Send command to mysql server,
 display result vertically.
exit (\q) Exit mysql. Same as quit.
go (\g) Send command to mysql server.
nopager (\n) Disable pager, print to stdout.
notee (\t) Don't write into outfile.
pager (\P) Set PAGER [to_pager].
 Print the query results via PAGER.
print (\p) Print current command.
prompt (\R) Change your mysql prompt.
quit (\q) Quit mysql.
rehash (\#) Rebuild completion hash.
source (\.) Execute an SQL script file.
 Takes a file name as an argument.
status (\s) Get status information from the server.
system (\!) Execute a system shell command.
tee (\T) Set outfile [to_outfile].
 Append everything into given outfile.
use (\u) Use another database.
 Takes database name as argument.

Os comandos edit, nopager, pager, e system funcionam apenas no Unix.

O comando status lhe fornece algumas informações sobre a conexão e o servidor que está utilizando. Se você estiver executando no modo --safe-updates, status irá também imprimir os valores para as variáveis MariaDB que afetam suas consultas.

Uma opção útil para iniciantes (introduzido no MariaDB versão 3.23.11) é o --safe-updates (ou --i-am-a-dummy para usuários que uma vez possam ter feito um DELETE FROM nome_tabela mas esqueceram da cláusula WHERE). Quando utilizar esta opção, o MariaDB envia o seguinte comando ao servidor MariaDB quando abrir a conexão.

SET SQL_SAFE_UPDATES=1,SQL_SELECT_LIMIT=#select_limit#,
 SQL_MAX_JOIN_SIZE=#max_join_size#'

onde #select_limit# e #max_join size# são variáveis que podem ser configuradas da linha de comando MariaDB. Leia 'Sintaxe de SET'.

O efeito da opção acima é:

Algumas dicas úteis sobre o cliente MariaDB:

Alguns dados são muito mais legíveis quando exibido verticalmente, em vez da saída do tipo caixa horizontal comum. Por exemplo: Textos longos, que incluem várias linhas, são muito mais fáceis de serem lidos com saída vertical.

mysql> SELECT * FROM mails WHERE LENGTH(txt) < 300 lIMIT 300,1\G
*************************** 1. row ***************************
 msg_nro: 3068
 date: 2000-03-01 23:29:50
time_zone: +0200
mail_from: Monty
 reply: monty@no.spam.com
 mail_to: 'Thimble Smith' <tim@no.spam.com>
 sbj: UTF-8
 txt: >>>>> 'Thimble' == Thimble Smith writes:
Thimble> Hi. I think this is a good idea. Is anyone familiar with UTF-8
Thimble> or Unicode? Otherwise, I'll put this on my TODO list and see what Thimble> happens.
Yes, please do that.
Regards,
Monty
 file: inbox-jani-1
 hash: 190402944
1 row in set (0.09 sec)

Para o log, você pode utilizar a opção tee. O tee pode ser iniciado com a opção --tee=..., ou pela linha de comando de maneira interativa com o comando tee. Todos os dados exibidos na tela serão anexados no arquivo fornecido. Isto também pode ser muito útil para propósitos de depuração. O tee pode ser desabilitado da linha de comando com o comando notee. Executando tee novamente o log é reiniciado. Sem um parâmetro o arquivo anterior será usado. Perceba que tee irá atualizar os resultados dentro do arquivo depois de cada comando, pouco antes da linha de comando reaparecer esperando pelo próximo comando.

Navegar ou pesquisar os resultados no modo interativo em algum programa do UNIX como o less, more ou outro similar, é agora possível com a opção --pager[=...]. Sem argumento, o cliente MariaDB irá procurar pela variável de ambiente PAGER e configurar pager para este valor. pager pode ser iniciado a partir da linha de comando interativa com o comando pager e desabilitado com o comando nopager. O comando recebe um argumento opcional e e o pager será configurado com ele. O comando pager pode ser chamado com um argumento, mas isto requer que a opção --pager seja usada, ou o pager será usado com a saída padrão. pager funciona somente no UNIX, uma vez que é utilizado a função popen(), que não existe no Windows. No Windows a opção tee pode ser utilizada, entretanto ela pode não ser cômoda como pager pode ser em algumas situações.

Algumas dicas sobre pager:

Você também pode combinar as duas funções acima; tenha o tee habilitado, o pager configurado para 'less' e você estará apto a navegar nos resultados no less do Unix e ainda ter tudo anexado em um arquivo ao mesmo tempo. A diferença entre UNIX tee usado com o pager e o tee embutido no cliente MariaDB é que o tee embutido funciona mesmo se você não tiver o comando UNIX tee disponível. O tee embutido também loga tudo que é exibido na tela, e o UNIX tee usado com pager não loga completamente. Por último o tee interativo é mais cômodo para trocar entre os modos on e off, quando você desejar logar alguma coisa em um arquivo, mas deseja estar apto para desligar o recurso quando necessário.

A partir da versão 4.0.2 é possível alterar o prompt no cliente de linha de comando MariaDB.

Você pode usar as seguintes opções do prompt:

Opção Descrição
\v versão mysqld
\d banco de dados em uso
\h máquina na qual está conectado
\p porta na qual está conectado
\u nome do usuário
\U nome_usuário@maquina
\\ '\'
\n nova quebra de linha
\t tab
\ espaço
\_ espaço
\R hora no formato 24h (0-23)
\r hora no formato 12h (1-12)
\m minutos
\y ano com dois digitos
\Y ano com quatro digitos
\D formato completo da data
\s segundos
\w dia da semana no formato com 3 letras (Mon, Tue, ...)
\P am/pm
\o mês no formato de número
\O mês no formato com 3 letras (Jan, Feb, ...)
\c contador que cresce a cada comando

'\' seguido por qualquer outra letra apenas retorna aquela letra.

Você pode definir o prompt nos seguintes lugares:

mysqlcc, The MariaDB Control Center

mysqlcc, o Centro de Controle do MariaDB, é um cliente independente de plataforma que fornece um interface gráfica ao usuário (GUI) para o servidor de Banco de Dados MariaDB. Ela suporta uso interativo, incluindo destaque de sintaxe e complementação com tab. Ele fornece gerenciamento de banco de dados e tabelas e permite a administração do servidor.

Atualmente, o mysqlcc executa em plataformas Windows e Linux.

mysqlcc não está incluído com a distribuição MySQL, mas pode ser feito o download separadamente em http://www.mysql.com/downloads/.

mysqlcc suporta as seguintes opções:

Você também pode configurar as seguntes variáveis com -O ou --set-variable. Por favor, note que as sintaxes --set-variable=nome=valor e -O name=value estão obsoletas desde o MariaDB 4.0, use --var=option:

Variable Name Default Description
connect_timeout 0 Number of seconds before connection timeout.
local-infile 0 Disable (0) or enable (1) LOCAL capability for LOAD DATA INFILE
max_allowed_packet 16777216 Max packet length to send to/receive from server
net_buffer_length 16384 Buffer for TCP/IP and socket communication
select_limit 1000 Automatic limit for SELECT when using --safe-updtaes
max_join_size 1000000 Automatic limit for rows in a join when using --safe-updates

mysqladmin, Administrando um Servidor MariaDB

Um utilitário para realizar operações administrativas. A sintaxe é:

shell> mysqladmin [OPÇÕES] comando [opção_do_comando] comando...

Você pode obter uma lista das opção que sua versão do mysqladmin suporta executando mysqladmin --help.

O mysqladmin atual suporta os seguintes comandos:

Todos comandos podem ser reduzidos para seu prefixo único. Por exemplo:

shell> mysqladmin proc stat
+----+-------+-----------+----+-------------+------+-------+------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-------+-----------+----+-------------+------+-------+------+
| 6 | monty | localhost | | Processlist | 0 | | |
+----+-------+-----------+----+-------------+------+-------+------+
Uptime: 10077 Threads: 1 Questions: 9 Slow queries: 0
Opens: 6 Flush tables: 1 Open tables: 2
Memory in use: 1092K Max memory used: 1116K

O resultado do comando mysqladmin status possui as seguintes colunas:

Uptime Número de segundos que o servidor MariaDB está funcionando.
Threads Número de threads ativas (clientes).
Questions Número de solicitações dos clientes desde que o mysqld foi iniciado.
Slow queries Consultas que demoram mais que long_query_time segundos. Leia 'O Log para Consultas Lentas'.
Opens Quantas tabelas foram abertas pelo mysqld.
Flush tables Número de comandos flush..., refresh e reload.
Open tables Número de tabelas abertas atualmente.
Memory in use Memória alocada diretamente pelo código do mysqld (disponível somente quando o MariaDB é compilado com --with-debug=full).
Max memory used Memória máxima alocada diretamente pelo código do mysqld (disponível somente quando o MariaDB é compilado com --with-debug=full).

Se você executa um mysqladmin shutdown em um socket (em outras palavras, em um computador onde o mysqld está executando), mysqladmin irá esperar até que o arquivo-pid do MariaDB seja removido para garantir que o servidor mysqld parou corretamente.

mysqlbinlog, Executando as Consultas a Partir de um Log Binário

Você pode examinad o arquivo de log binário (see 'O Log Binário') com o utilitário mysqlbinlog.

shell> mysqlbinlog hostname-bin.001

exibirá todas as consultas contidas no log binário hostname-bin.001, junto com outras informações (tempo da consulta, ID da thread que a executou, o timestamp de quando foi executada, etc).

Você pode colocar a saída do mysqlbinlog em um cliente MariaDB; isto é usado para recuperações de falhas quando você tem um backup antigo (see 'Backups dos Bancos de Dados'):

shell> mysqlbinlog hostname-bin.001 | mysql

ou

shell> mysqlbinlog hostname-bin.[0-9]* | mysql

Você também pode redirecionar a saída do mysqlbinlog para um arquivo texto, então modifique este arquivo texto (para excluir as consultas que você não quer executar por alguma razão), e então execute as consultas a partir do arquivo texto dentro do MariaDB.

mysqlbinlog possui a opção position=# que exibirá apenas as consultas cujo offset no log binário é maior ou igual a #.

Se você tiver mais que um log binário para executar no servidor MySQL, o método seguro é fazê-lo em uma única conexão MariaDB. Aqui está o que pode ser INseguro:

shell> mysqlbinlog hostname-bin.001 | mysql # DANGER!!
shell> mysqlbinlog hostname-bin.002 | mysql # DANGER!!

Isto causará problemas se o primeiro log binário conter um CREATE TEMPORARY TABLE e o segundo contém uma consulta que utiliza esta tabela temporária: quando o primeiro MariaDB termina, ele apara a tabela temporária, assim a o segundo MariaDB relatará um tabela desconhecida. Isto ocorre porque você deve executar todos os log binários que você deseja em uma única conexão, especialmente se você usa tabelas temporárias. Aqui estão dois modos possíveis:

shell> mysqlbinlog hostname-bin.001 hostname-bin.002 | mysql

shell> mysqlbinlog hostname-bin.001 > /tmp/queries.sql
shell> mysqlbinlog hostname-bin.002 >> /tmp/queries.sql
shell> mysql -e 'source /tmp/queries.sql'

A partir do MariaDB 4.0.14, mysqlbinlog pode preparar uma entrada para o MariaDB executar um LOAD DATA INFILE a partir de um log binário. Como o log binário contém os dados para carregar (isto é verdade para o MariaDB 4.0; o MariaDB 3.23 não grava o dado carregado em um log binário, assim o arquivo original era necessário quando se queria executar o conteúdo do log binário), mysqlbinlog copiará este data para um arquivo temporário e imprime um comando LOAD DATA INFILE para o MariaDB carregar este arquivo temporário. O local onde o arquivo temorário é criado é o diretório temporário por padrão; ele pode ser alterado com a opção local-load do mysqlbinlog.

Antes do MariaDB, mysqlbinlog não podia preaparar saída cabíveis para MariaDB quando o log binário continha consultas de diferentes threads usando tabelas temporárias de mesmo nome, se estas consultas eram entrelaçadas. Isto está resolvido no MariaDB 4.1.

Você também pode usar o mysqlbinlog --read-from-remote-server para ler o log binário diretamente de um servidor MariaDB remoto. No entanto, isto é algo que está obsoleto já que queremos tornar fácil de se aplicar os logs binários em servidores MariaDB em execução.

mysqlbinlog --help lhe dará mais informações

Usando mysqlcheck para Manutenção de Tabelas e Recuperação em Caso de Falhas

Desde o MariaDB versão 3.23.38 você estará apto a usar a nova ferramenta de reparos e verificação de tabelas MyISAM. A diferença para o myisamchk é que o mysqlcheck deve ser usado quando o servidor mysqld estiver em funcionamento, enquanto o myisamchk deve ser usado quando ele não estiver. O benefício é que você não precisará mais desligar o servidor mysqld para verificar ou reparar suas tabelas.

O mysqlcheck utiliza os comandos do servidor MariaDB CHECK, REPAIR, ANALYZE e OPTIMIZE de um modo conveniente para o usuário.

Existem três modos alternativos de chamar o mysqlcheck:

shell> mysqlcheck [OPÇÕES] database [tabelas]
shell> mysqlcheck [OPÇÕES] --databases DB1 [DB2 DB3...]
shell> mysqlcheck [OPÇÕES] --all-databases

Pode ser usado de uma maneira muito similar ao mysqldump quando o assunto for quais bancos de dados e tabelas devem ser escolhidas.

O mysqlcheck tem um recurso especial comparado comparado aos outros clientes; o comportamento padrão, verificando as tabelas (-c), pode ser alterado renomeando o binário. Se você deseja ter uma ferramenta que repare as tabelas como o procedimento padrão, você deve copiar o mysqlcheck para o disco com um outro nome, mysqlrepair, ou crie um link simbólico com o nome mysqlrepair. Se você chamar mysqlrepair agora, ele irá reparar as tabelas como seu procedimento padrão.

Os nomes que podem ser utilizados para alterar o comportamento padrão do mysqlcheck são:

mysqlrepair: A opção padrão será -r mysqlanalyze: A opção padrão será -a mysqloptimize: A opção padrão será -o

As opções disponíveis para o mysqlcheck estão listadas aqui, por favor verifique o que a sua versão suporta com o mysqlcheck --help.

mysqldump, Descarregando a Estrutura de Tabelas e Dados

Utilitário para descarregar um banco de dados ou uma coleção de bancos de dados para backup ou transferencia para outro servidor SQL (Não necessariamente um servidor MySQL). A descarga irá conter instruções SQL para cria a tabela e/ou popular a tabela.

Se a idéia é backup do servidor, deve ser considerada a utilização do mysqlhotcopy. Leia 'mysqlhotcopy, Copiando Bancos de Dados e Tabelas do MariaDB'.

shell> mysqldump [OPÇÕES] banco_de_dados [tabelas]
OR mysqldump [OPÇÕES] --databases [OPÇÕES] BD1 [BD2 BD3...]
OR mysqldump [OPÇÕES] --all-databases [OPÇÕES]

Se você não fornecer nenhuma tabela ou utilizar o --databases ou --all-databases, todo(s) o(s) banco(s) de dados será(ão) descarregado(s).

Você pode obter uma lista das opções que sua versão do mysqldump suporta executando mysqldump --help.

Perceba que se você executar o mysqldump sem a opção --quick ou --opt, o mysqldump irá carregar todo o conjunto do resultado na memória antes de descarregar o resultado. Isto provavelmente será um problema se você está descarregando um banco de dados grande.

Note que se você estiver utilizando uma cópia nova do programa mysqldump e se você for fazer uma descarga que será lida em um servidor MariaDB muito antigo, você não deve utilizar as opções --opt ou -e.

mysqldump suporta as seguintes opções:

O uso mais comum do mysqldump é provavelmente para fazer backups de bancos de dados inteiros. Leia 'Backups dos Bancos de Dados'.

mysqldump --opt banco_dados > arquivo-backup.sql

Você pode ler de volta no MariaDB com:

mysql banco_dados < arquivo-backup.sql

ou

mysql -e 'source /path-to-backup/backup-file.sql' database

Entretanto, é muito útil também popular outro servidor MariaDB com informações de um banco de dados:

mysqldump --opt banco_dados | mysql ---host=máquina-remota -C banco_dados

É possível descarregar vários bancos de dados com um comando:

mysqldump --databases banco_dados1 [banco_dados2 banco_dados3...] > meus_bancosdedados.sql

Se desejar descarregar todos os bancos de dados, pode-se utilizar:

mysqldump --all-databases > todos_bancos_dados.sql

mysqlhotcopy, Copiando Bancos de Dados e Tabelas do MariaDB

O mysqlhotcopy é um script perl que utiliza LOCK TABLES, FLUSH TABLES e cp ou scp para fazer um backup rápido de um banco de dados. É a maneira mais rápida para fazer um backup do banco de dados e de algumas tabelas mas ele só pode ser executado na mesma máquina onde os diretórios dos bancos de dados estão. O mysqlhotcopy só funciona no Unix e apenas para as tabelas MyISAM e ISAM.

mysqlhotcopy nome_bd [/caminho/para/novo_diretório]
mysqlhotcopy nome_bd_2 ... nome_bd_2 /caminho/para/novo_diretório mysqlhotcopy nome_bd./regex/

mysqlhotcopy suporta as seguintes opções:

Você pode utilizar perldoc mysqlhotcopy para obter uma documentação mais completa de mysqlhotcopy.

mysqlhotcopy lê os grupos [client] e [mysqlhotcopy] dos arquivos de opções.

Para poder executar mysqlhotcopy é necessário acesso de escrita ao diretório de backup, privilégio SELECT nas tabelas que desejar copiar e o privilégio Reload no MariaDB (para poder executar FLUSH TABLES).

mysqlimport, Importando Dados de Arquivos Texto

mysqlimport fornece uma interface de linha de comando para a instrução SQL LOAD DATA INFILE. A maioria das opções aceitas correspondem diretamente às opções de LOAD DATA INFILE. Leia 'Sintaxe LOAD DATA INFILE'.

mysqlimport é chamado desta maneira:

shell> mysqlimport [opções] banco_de_dados arquivo_texto1 [arquivo_texto2....]

Para cada arquivo texto passadoo na linha de comando, mysqlimport remove qualquer extensão do nome do arquivo e utiliza o resultado para determinar para qual tabela os dados do arquivo serão importados. Por exemplo, arquivos chamados patient.txt, patient.text e patient serão importados para uma tabela chamada patient.

mysqlimport suporta as seguintes opções:

Abaixo um exemblo da utilização de mysqlimport:

$ mysql --version mysql Ver 9.33 Distrib 3.22.25, for pc-linux-gnu (i686)
$ uname -a Linux xxx.com 2.2.5-15 #1 Mon Apr 19 22:21:09 EDT 1999 i586 unknown
$ mysql -e 'CREATE TABLE imptest(id INT, n VARCHAR(30))' test
$ ed a
100 Max Sydow
101 Count Dracula
.
w imptest.txt
32
q
$ od -c imptest.txt
0000000 1 0 0 \t M a x S y d o w \n 1 0
0000020 1 \t C o u n t D r a c u l a \n
0000040
$ mysqlimport --local test imptest.txt test.imptest: Records: 2 Deleted: 0 Skipped: 0 Warnings: 0
$ mysql -e 'SELECT * FROM imptest' test
+------+---------------+
| id | n |
+------+---------------+
| 100 | Max Sydow |
| 101 | Count Dracula |
+------+---------------+

mysqlshow, Exibindo Bancos de Dados, Tabelas e Colunas

mysqlshow pode ser usado para exibir rapidamente quais bancos de dados existem, suas tabelas, e o nome das colunas da tabela.

Como o programa MariaDB você pode obter as mesmas informações com comandos SHOW. Leia 'Sintaxe de SHOW'.

mysqlshow é chamado assim:

shell> mysqlshow [OPÇÕES] [banco_dados [tabela [coluna]]]

Note que em versões mais novas do MariaDB, você só visualiza as tabelas/bancos de dados/colunas para quais você tem algum privilégio.

Se o último argumento conter uma shell ou um meta-caracter do SQL, (*, ?, % ou _) somente o que coincidir com o meta-caracter é exibido. Se um banco de dados conter underscore (_), eles devem ser precedidos por uma barra invertida (algumas shells de Unix irão exigir duas), para se obter tabelas/colunas apropriadamente. '*' são convertidos em metacaracteres '%' do SQL e '?' em metacaracteres '_' do SQL. Isto pode causar alguma confusão quando alguém tentar exibir as colunas para uma tabela com um _, neste caso o mysqlshow exibe somente os nomes de tabelas que casarem com o padrão. Isto é facilmente corrigido adicionando um % extra na linha de comando (como um argumento separador).

mysql_config, Opções para compilação do cliente MariaDB

mysql_config lhe fornece informação útil sobre como compilar o seu cliente MariaDB e conectá-lo ao MariaDB.

mysql_config suporta as seguintes opções:

Se você executar mysql_config sem nenhuma opção ele exibirá todas as opções suportadas mais os valores de todas elas:

shell> mysql_config
Usage: /usr/local/mysql/bin/mysql_config [OPTIONS]
Options:
 --cflags [-I/usr/local/mysql/include/mysql -mcpu=pentiumpro]
 --include [-I/usr/local/mysql/include/mysql]
 --libs [-L/usr/local/mysql/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -L/usr/lib -lssl -lcrypto]
 --libs_r [-L/usr/local/mysql/lib/mysql -lmysqlclient_r -lpthread -lz -lcrypt -lnsl -lm -lpthread]
 --socket [/tmp/mysql.sock]
 --port [3306]
 --version [4.0.16]
 --libmysqld-libs [-L/usr/local/mysql/lib/mysql -lmysqld -lpthread -lz -lcrypt -lnsl -lm -lpthread -lrt]

Você pode usá-lo para compilar o cliente MariaDB como a seguir:

CFG=/usr/local/mysql/bin/mysql_config sh -c 'gcc -o progname `$CFG --cflags` progname.c `$CFG --libs`'

perror, Explicando Códigos de Erros

Para a maioria dos erros de sistema o MariaDB irá, em adição a uma mensagem de texto interna, imprimir também o código de erro do sistema em um dos seguintes estilos: message ... (errno: #) ou message ... (Errcode: #).

Você pode descobrir o que o código de erro significa exeminando a documentação para o seu sistema ou usar o utilitário perror.

perror exibe a descrição para um código de erro do sistema, ou um código de erro do mecanismo de armazenamento MyISAM/ISAM (handler de tabela).

perror é utilizado assim:

shell> perror [OPÇÕES] [CÓDIGO_ERRO [CÓDIGO_ERRO...]]
Exemplo:
shell> perror 13 64
Error code 13: Permission denied Error code 64: Machine is not on the network

Note que a mensagem de erro sã ona maioria dependente do sistema!

Como Executar Comandos SQL a Partir de um Arquivo Texto

O cliente MariaDB normalmente é usado de maneira interativa, desta forma:

shell> mysql banco_dados

Entretanto, também é possível colocar seus comandos SQL em um arquivo e dizer ao MariaDB para ler a entrada a partir deste arquivo. Para fazer isto, crie um arquivo texto arquivo_texto contendo os comandos que você deseja executar. Então execute o MariaDB como exibido abaixo:

shell> mysql banco_dados < arquivo_texto

Você também pode iniciar seu arquivo texto com uma instrução USER nome_bd. Neste caso, não é necessário especificar o nome do banco de dados na linha de comando:

shell> mysql < arquivo_texto

Se você já está executando o MariaDB, você pode executar um arquivo de script SQL usando o comando source:

mysql> source filename;

Para mais informações sobre o modo batch, 'Utilizando MariaDB em Modo Batch'.

Os Arquivos de Log do MariaDB

O Log de Erros
O Log de Consultas
O Log de Atualizações
O Log Binário
O Log para Consultas Lentas
Manutenção do Log de Arquivo

O MariaDB tem vários arquivos de log diferentes que podem ajudá-lo a descobrir o que está acontecendo dentro do mysqld:

Log file Description
O log de erros Problemas encontrados iniciando, executando ou parando o mysqld.
O log isam Documenta todas alterações a tabelas ISAM. Usado somente para depuração do código isam.
O log de consultas Conexões estabelecidas e consultas executadas.
O log de atualizações Desatulizado: Armazena todas as instruções que alteram dados.
O log binário Armazena todas as instruções que alteram qualquer coisa. Usada também para replicação.
O log para consultas lentas Armazena todas queries que levaram mais de long_query_time segundos para executar ou que não usaram índices.

Todos logs podem ser encontrados no diretório de dados do mysqld. Você pode forçar o mysqld a reabrir os arquivos de log (ou em alguns casos trocar para um novo log) executando FLUSH LOGS. Leia 'Sintaxe de FLUSH'.

O Log de Erros

A arquivo de log de erro contém informações indicando quando o mysqld foi iniciado e finalizado e também qualquer erro crítico encontrado na execução.

Se o mysqld finaliza inesperadamente e o mysqld_safe precisar reiniciar o mysqld, mysqld_safe gravará uma linha restarted mysqld neste arquivo. Este log também guarda um aviso se o mysqld notificar uma tabela que precisa ser automaticamente verificada ou reparada.

Em alguns sistemas operacionais, o log de erro irá conter registros de pilha de onde o mysqld finalizou. Isto pode ser usado para saber onde e como o mysqld morreu. Leia Seção E.1.4, 'Usando Stack Trace'.

A partir do MariaDB 4.0.10 você pode especificar onde o mysqld armazena o arquivo de log de erro com a opção --log-error[=filename]. Se nenhum nome de arquivo for dado, o mysqld usará mysql-data-dir/'maquina'.err no Unix e \mysql\data\mysql.err no Windows.i Se você executar flush logs o arquivo antigo terá o prefixo --old e o mysqld criará um novo arquivo de log vazio.

Em versões mais antigas do MariaDB o tratamento do log de erro era feito pelo mysqld_safe o qual redirecionava o arquivo de erro para 'maquina'.err. Pode se alterar este nome de arquivo com a opção --err-log=nome_arq.

Se você não especificar --log-error ou se você utilizar a opção --console, o erro será escrito em stderr (o terminal).

No Windows a saída é sempre feita no arquivo .err se --console não for utilizado.

O Log de Consultas

Se você deseja saber o que acontece com mysqld, você deve iniciá-lo com a opção --log[=arquivo]. Isto irá documentar todas conexões e consultas no arquivo log (por padrão nomeado 'nome_máquina'.log). Este log pode ser muito útil quando você suspeitar de um erro em um cliente e deseja saber exatamente o que o mysqld acha que o cliente enviou.

Older versions of the mysql.server script (from MariaDB 3.23.4 to 3.23.8) pass mysqld_safe a --log option (enable general query log). If you need better performance when you start using MariaDB in a production environment, you can remove the --log option from mysql.server or change it to --log-bin. Leia 'O Log Binário'.

Versões mais antigas do script mysql.server (MySQL 3.23.4 a 3.23.8) passam ao safe_mysql uma opção --log (habilita a log de consulta geral). Se você precisar melhorar a performance quando iniciar o uso do MariaDB em um ambiente de produção, pode remover a opção --log do mysql.server ou alterá-lo para --log-bin. Leia 'O Log Binário'.

As entradas neste log são escritas quando o mysqld recebe as questões. Pode estar diferente da ordem em que as instruções são executadas. Isto está em contraste com o log de atualizações e o log binário nos quais as consultas são escritas depois de serem executadas, mas que quaisquer travas sejam liberadas.

O Log de Atualizações

NOTA: O log de atualizações está obsoleto e foi substituído pelo log binário. Leia 'O Log Binário'. O log binário pode fazer qualquer coisa que poderia ser feito com o log de atualizações, e mais. O log de atualização será removido no MariaDB 5.0

Quando iniciado com a opção --log-update[=nome_arquivo], o mysqld grava um arquivo log contendo todos os comandos SQL que atualizam dados. Se nenhum arquivo for fornecido, o nome da máquina é usado. Se um nome de arquivo for fornecido, mas não possuir o caminho, o arquivo é gravado no diretório de dados. Se nome_arquivo não possuir uma extensão, o mysqld irá criar os arquivos com os nomes desta forma: nome_arquivo.###, onde ### é um número que é incrementado cada vez que mysqladmin refresh, mysqladmin flush-logs ou a instrução FLUSH LOGS forem executados ou o servidor for reiniciado.

NOTA: Para o esquema acima funcionar, você não pode criar seus próprios arquivos com o mesmo nome que os do log de atualização + algumas extensões que podem ser tratadas como números, no diretório usado pelo log de atualização!

Se forem utilizadas as opções --log ou -l, o mysqld escreve um log geral com o nome de arquivo nome_máquina.log, e o reinicio e a recarga não geram um novo arquivo de log (embora ele seja fechado e reaberto). Neste caso você pode copiá-lo (no Unix) usando:

mv nome_máquina.log nome_máquina-antigo.log mysqladmin flush-logs cp nome_máquina-antigo.log para-diretório-backup rm nome_máquina-antigo.log

O log de atualização é inteligente pois registra somente instruções que realmente alteram dados. Portanto, um UPDATE ou um DELETE com uma cláusula WHERE que não encontre nenhum registro não é escrito no log. Ele salta até instruções UPDATE que atribui a uma coluna o mesmo valor que ela possuia.

O registro da atualização é feito imediatamente após uma consulta estar completa mas antes que as bloqueios sejam liberados ou que algum commit seja feito. Isto garante que o log seja escrito na ordem de execução.

Se você desejar atualizar um banco de dados a partir de arquivos de logs de atualização, você pode fazer o seguinte (assumindo que seus logs de atualização estejam nomeados na forma nome_arquivo.###):

shell> ls -1 -t -r nome_arquivo.[0-9]* | xargs cat | mysql

ls é utilizado para obter todos os arquivos de log na ordem correta.

Isto pode ser útil se você tiver que recorrer a arquivos de backup depois de uma falha e desejar refazer as atualizações que ocorreram entre a hora do backup e a falha.

O Log Binário

O log binário deve substituiu o log de atualizações. O log de atualizações será removido do MariaDB 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. Leia '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. Leia '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 'Sintaxe de RESET'), ou apenas alguns deles com PURGE MASTER LOGS (see Seçã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):

Opção Descrição
binlog-do-db=nome_banco_dados Diz ao master que ele deve registrar atualizações no log binário se o banco de dado atual (ex.: aquele selecionado por USE) é 'nome_banco_dados'. Todos os outros bancos de dados que não forem explicitamente mencionados são ignorados. Note que se você utilizá-lo você deve se assegurar que você só faz atualizações no banco de dados atual. (Exemplo: binlog-do-db=algum_bancodados) Exemplo do que não funciona como você poderia esperar: se o servidor é iniciado com binlog-do-db=sales, e você fizer USE prices; UPDATE sales.january SET amount=amount+1000;, esta consulta não será gravada no log binário.
binlog-ignore-db=nome_banco_dados Diz ao master que atualizações onde o banco de dados atual (ex.: aquele selecionado com USE) é 'nome_banco_dados' não deve ser gravado no log binário. Note que se você usar esta opção você deve ter certeza que você só faz atualizações no banco de dados atual. (Exemplo: binlog-ignore-db=algum_banco_dados) Exemplo do que não funciona como você poderia esperar: se o servidor é iniciado com binlog-do-db=sales, e você fizer USE prices; UPDATE sales.january SET amount=amount+1000;, esta consulta será gravada no log binário.

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

  1. Existem as regras binlog-do-db ou binlog-ignore-db?

    • Não: grave a consulta no log binário e saia.
    • Sim: Vá para o passo abaixo.
  2. Então existe algumas regras (binlog-do-db ou binlog-ignore-db ou ambos). Existe um banco de dados atual (algum banco de dados foi selecionado com USE?)?

    • Não: NÃO grave a consulta e saia.
    • Sim: vá para o passo abaixo.
  3. Existe um banco de dados. Existe alguma regra binlog-do-db?

    • Sim: O banco de dados atual se encaixa em qualquer uma das regras binlog-do-db?

      • Sim: grave a consulta e saia.
      • Não: NÃO grave a consulta e saia.
    • Não: Vá para o passo abaixo.
  4. Existem algumas regras binlog-ignore-db. O banco de dados atual se encaixa em qualquer uma das regras binlog-ignore-db?

    • Sim: não grave a consulta e saia.
    • Não: grave a consulta e saia.

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 '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 MariaDB 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. Leia '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 MariaDB a partir de um log binário como mostrado a seguir:

mysqlbinlog arquivo-log | mysql -h nome_servidor

Veja '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 MariaDB 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.

O Log para Consultas Lentas

Quando iniciado com a opção --log-slow-queries[=file_name] o mysqld escreve em um arquivo log contendo todos os comandos SQL que levam mais de long_query_time segundos para executar. O tempo para obter os bloqueios de tabelas iniciais não são contados como tempo de execução.

O log de consultas lentas é gerado depois que uma query é executada e depois de todas as bloqueios serem liberados. Ela pode estar em ordem diferente da que as instruções foram executadas.

Se nenhum nome de arquivo for fornecido, o padrão é o nome da máquina com o sufixo -slow.log. Se um nome de arquivo for especificado, mas não conter o caminho, o arquivo é gravado no diretório de dados.

O log para queries lentas pode ser usado para encontrar queries que levam muito tempo para executar e que devem ser candidatas a otimização. Com um log muito grande, isto pode ser uma tarefa difícil. Você pode utilizar o log de consultas lentas através do comando mysqldumpslow para obter um resumo das consultas que aparecem no log.

Se a opção --log-long-format estiver sendo usada, então as consultas que não estiverem utilizando índices serão escritas. Leia 'Opções de Linha de Comando do mysqld'.

Manutenção do Log de Arquivo

O MariaDB tem vários arquivos de log que possibilitam ver o que está ocorrendo com mais facilidade. Leia 'Os Arquivos de Log do MariaDB'. Porém de tempos em tempos deve ser feita uma limpeza nos arquivos de logs do MariaDB para que eles não ocupem muito do espaço do disco.

Ao utilizar o MariaDB com arquivos log, você necessitará de tempos em tempos remover antigos arquivos de log e dizer ao MariaDB para logar com novos arquivos. Leia 'Backups dos Bancos de Dados'.

Em uma instalação Linux RedHat), você pode usar o script mysql-log-rotate para isto. Se você instalou o MariaDB de uma distribuição RPM, o script deve ter sido instalado automaticamente. Perceba que você deve ter cuidado com este script se você estiver utilizando o log binário para replicação!

Em outros sistemas você deve instalar um pequeno script que será executado pelo cron para lidar com os arquivos de log.

Você pode forçar o MariaDB a iniciar utilizando novos arquivos de log usando mysqladmin flush-logs ou utlizando o comando SQL FLUSH LOGS. Se você usa o MariaDB Versão 3.21 deve utilizar o comando mysqladmin refresh.

O comando acima faz o seguinte:

Se você só estiver utilizando o log de atualização, você tem apenas que atualizar os logs e então mover os arquivos de log antigos para um backup. Se você estiver utilizando o log normal, você pode fazer algo assim:

shell> cd diretório-dados-mysql
shell> mv mysql.log mysql.old
shell> mysqladmin flush-logs

e então fazer um backup e remover o mysql.old.

Replicação no MariaDB

Introdução
Visão Geral da Implementação da Replicação
Detalhes de Implementação da Replicação
Como Configurar a Replicação
Recursos de Replicação e Problemas Conhecidos
Opções de Inicialização da Replicação
Instruções SQL para Controle do Servidor Master
Instruções SQL para Controle do Servidor Slave
FAQ da Replicação
Problemas com Replicação
Relatando Problemas de Replicação

Capacidades de replicação permitidindo que os bancos de dados em um servidor MariaDB seja duplicado em outro foram introduzidos no MariaDB versão 3.23.15. Esta seção descreve os vários recursos da replicação no MariaDB. Ele serve como uma referência para as opções disponíveis na replicação. Você será introduzido a replicação e aprenderá como implementá-la. Em direção ao final, existem algumas questões mais perguntadas (FAQ), descrições de problemas e como resolvê-los.

Sugeriemos que você visite nosso website em https://mariadb.com/ frequentemente e leia as atualizações desta seção. A replicação esta constantemente sendo melhorada e nós atualizamos o manual frequentemente com a informação mais atual.

Introdução

A partir da versão 3.23.15, o MariaDB suporta replicação de uma via internamente. Um servidor atua como o master, enquando o outro atua como slave. O servidor master mantêm um log binário de atualizações (see 'O Log Binário'). É mantido também um arquivo de índices dos logs binários para manter os registro da rotatividade dos logs. Cada slave, na conexão, informa ao master onde parou desde a última atualização propagada corretamente, realiza a atualização e então para e espera o master informar sobre novas atualizações.

Um slave também pode ser um master se você condigurar uma cadeia de servidores em replicação.

Note que se você estiver usando replicação, todas atualizações nas tabelas replicadas devem ser realizadas no servidor master. Senão, você sempre deve ter cuidados para evitar conflitos entre as atualizações que os usuários enviam ao master e aquelas que os usuários enviam ao slave.

Replicação de uma via trazem benefícios de robustez, velocidade e administração do sistema:

Visão Geral da Implementação da Replicação

A replicação no MariaDB baseia-se no fato do servidor master manter o registro de todas as alterações de seus bancos de dados (atualizações, deleções, etc) no log binário. (see 'O Log Binário'). Cada servidor slave recebe do master consultas salvas no log binário, para que assim execute as mesmas consultas nos seus dados replicados.

É muito importante entender que o log binário é simplesmente um registro iniciando a partir de um ponto fixo no tempo (o momento que você habilitou o log binário). Quaisquer slaves que você configure necessitará de cópias do banco de dados do seu master como eles existiam no momento em que o log binário foi habilitado no master. Se você iniciar os slaves com dados diferentes daqueles do master quando o log binário foi iniciado, seus slaves falharão.

A seguinte tabela indica a compatibilidade de replicação master/slave entre diferentes versões do MariaDB.

Master Master Master Master
e posterior 4.0.0 4.0.1 e posterior
Slave e posterior sim não não não
Slave 4.0.0 não sim não não
Slave 4.0.1 sim não sim não
Slave e posterior sim não não sim

Como regra geral, sempre é recomendado usar versões MariaDB recentes, porque as capacidades de replicação estão sendo continuamente melhoradas. Com relação a versão 4.0, recomendamos usar a mesma versão para o master e o slave, com exceção de que o 4.0.2 não é recomandado para replicação.

Note qye quando você atualiza um mestre do MariaDB 3.23 para o MariaDB (ou 4.1) você não deve reiniciar a replicação usando o log binário antigo da versão 3.23, porque isto infelizmente deixa o slave 4.0 confuso. A atualização pode seguramente feita deste modo, assumindo que você tenha uma mestre 3.23 para atualizar e você tenha slaves 4.0:

  1. Bloqueie todas as atualizações no mestre (FLUSH TABLES WITH READ LOCK).
  2. Espere até que todos os slaves tenham buscados todas as alterações pelo master (use SHOW MASTER STATUS no master, e SELECT MASTER_POS_WAIT() nos slaves). Então execute STOP SLAVE nos slaves.
  3. Finalize o MariaDB no master e atualize o master para o MariaDB 4.0.
  4. Reinicie o MariaDB no master. Grave o nome <name> do log binário mais recentemente criado do master. Você pode obter o nome dos arquivos executando SHOW MASTER STATUS no master. Então envie estes comando em cada slave: 

    mysql> CHANGE MASTER TO MASTER_LOG_FILE='<name>', MASTER_LOG_POS=4;
mysql> START SLAVE;

Se você também deve atualizar seus slaves da versão 3.23 para 4.0, você deve primeiro atualizar seus slaves: Desligue cada um, atualize-os e os reinicie. Então atualize o master como descrito.

A partir da versão 4.0.0, pode se usar LOAD DATA FROM MASTER para configurar um escrao. Esteja certo que LOAD DATA FROM MASTER funciona atualmente apenas se todas as tabelas no master são do tipo MyISAM. Além disso, estas instrução irão adquirir lock global de leitura, assim nenhuma escrita será possível enquanto as tabelas estão sendo transferidas do master. Quando implementarmos hot backup de tabelas sem lock (no MariaDB 5.0), este lock global de leitura não será mais necessário.

Devido a estas limitações, recomendamos que você só use LOAD DATA FROM MASTER se o conjunto de dados de master for relativamente pequeno, ou se um lock de leitura prolongado no master é aceitável. Enquanto a velocidade atual do LOAD DATA FROM MASTER pode variar de sistema para sistema, uma boa regra do dedão de quanto tempo será necessário é considerar 1 segundo por 1 MB do arquivo de dados. Você ficará próximo da estimativa se tanto o master quanto o slave forem equivalentes a um Pentium 700 Mhz e estiverem conectado a uma rede de 100 MBits/s. É claro, esta é apenas uma estimativa grosseira da ordem de magnitude.

Uma vez que o slave foi configurado corretamente e está em execução, ele simplesmente conectará ao master e esperará por atualizações nos processos. Se o master for desligado ou o slave perder conectividade com seu master, ele tentará conectar periodicamente até conseguir reconectar e constinuar as atualizações. O intervalo de tentativa é controlado pela opção --master-connect-retry. O padrão é 60 segundos.

Cada slave mantêm registro de onde parou. O servidor master não tem conhecimento de quandos slaves existem ou quais estão atualizados em um determinado momento.

Detalhes de Implementação da Replicação

Três threads estão envolvidas na replicação: uma no master e duas no slave. Quando START SLAVE é executado, a thread de E/S é criada no slave. Ela se conecta ao master e pede pelo envio de seus logs binários. Então uma thread (chamada Binlog dump no SHOW PROCESSLIST no master) é criada no master para enviar estes logs binários. A thread de E/S lê o que o Binlog dump envia e simplesmente a copia para algum arquivo local no diretorio de dados do slave chamado relay logs. A última thread, a thread de SQL, é criada no slave; ela lê o relay logs e executa as consultas contidas nele.

Note que o master tem uma thread para cada servidor slave atualmente conectado.

Com SHOW PROCESSLIST você pode saber o que está acontecendo no master e no slave em relação a replicação.

O exemplo seguinte ilustra como as três threads aparecem em SHOW PROCESSLIST. O formato da saída é aquele usado por SHOW PROCESSLIST a partir do MariaDB versão 4.0.15, quando o conteúdo da coluna State foi alterado para ser mais significativo comparado com versões alterações.

No servidor master a saída se parece com isto:

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
 Id: 2
 User: root
 Host: localhost:32931
 db: NULL Command: Binlog Dump
 Time: 94
 State: Has sent all binlog to slave; waiting for binlog to be updated
 Info: NULL

No servidor slave, a saída se parece com isto:

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
 Id: 10
 User: system user
 Host:
 db: NULL Command: Connect
 Time: 11
 State: Waiting for master to send event
 Info: NULL
*************************** 2. row ***************************
 Id: 11
 User: system user
 Host:
 db: NULL Command: Connect
 Time: 11
 State: Has read all relay log; waiting for the slave I/O thread to update it
 Info: NULL

Aqui a thread 2 está no master. A thread 10 é a thread de E/S no slave. A thread 11 é a thread de SQL no slave; note que o valor na coluna Time pode dizer quando o slave é comparado com o master (see 'FAQ da Replicação').

A lista a seguir mostra os estados mais comuns que você verá na coluna State para a thread Binlog Dump do master. Se você não ver estas threads em um servidor master, a replicação não está sendo executada.

Aqui estão os estados mais comuns que você verá na coluna State para a thread de E/S de um servidor slave. A partir do MariaDB, este estado também aparece na coluna Slave_IO_State da saída de SHOW SLAVE STATUS. Isso significa que você pode ter uma boa visão do que está acontecendo apenas com SHOW STATUS SLAVE.

Aqui estão os estado mais comuns que você verá na coluna State para a thread de SQL de um servidor slave:

A coluna State para a thread de E/S também podem mostrar um string de consulta. Isto indica que a thread leu um evento do relay log, extraiu a conulta dele e está a está executando.

Antes do MariaDB 4.0.2, as threads de E/S e SQL eram combinadas em uma só e nenhum relay log era usado. A vantagem do uso de duas threads é que elas separam a leitura e a execução da consulta em duas tarefas independentes, e assim o trabalho de leitura da consulta não se torna lento se a execução da consulta for lento. Por exemplo, se o servidor slave não estiver em execução por um instante, a sua thread de E/S pode rapidamente buscar todos o conteúdo dos logs binários do master quando o slave iniciar, mesmo se a thread de SQL demorar e levar horas para pegar os logs. Se o slave parar antes da thread SQL executar todas as consultas buscadas, a thread de E/S terá finalmente buscado tudo e assim um cópia segura das consultas estará armazenada localmente nos relay logs do slave para execução na próxima execução do slave. Isto permite que os log binários sejam apagados no master, já que não há mais necessidade de esperar que o slave busque o conteúdo deles.

Por padrão, relay logs são nomeados usando nome de arquivos da forma host_name-relay-bin.nnn, onde host_name é o nome da máquina servidora slave e nnn é uma sequência numérica. Arquivos de relay logs sucvessivos são criados usando uma sequência de números sucessiva, começando com 001. O slave mantém registro dos relay logs em uso atualmente em um arquivo de índice. O nome de arquivo padrão dos relay logs é host_name-relay-bin.index. Por padrão estes arquivos são criados no diretório de dados do slave. O nome de arquivo padrão pode ser sobrescrito com as opções --relay-log e --relay-log-index do servidor.

Relay logs têm o mesmo formato dos logs binários, assim ele podem ser lidos com mysqlbinlog. Um relay log é automaticamente deletado pela thread de SQL tão logo não seja mais necessária (ex.: assim que tiver sido executado todos os seus eventos). Não existem comandos para deletar relay logs já que a thread SQL cuida de fazê-lo. No entanto, a partir do MariaDB 4.0.14, FLUSH LOGS rotaciona os relay logs), o que irá influenciar quando a thread de SQL deletá-los.

Um novo relay log é criado sob as seguintes condições:

Um servidor de replicação slave cria dois arquivos pequenos no diretório de dados. Estes arquivos são chamados master.info e relay-log.info por padrão. Eles possuem informação como aquela mostrada na saída da instrução SHOW SLAVE STATUS (see 'Instruções SQL para Controle do Servidor Slave' para uma descrição deste comando). Como imagem de discos, eles sobrevivem ao desligamento do slave. A próxima vez que o slave é reiniciado, ele pode ler estes arquivos para saber o quanto ele processou do log binário do master e do seus próprios relay logs.

O arquivo master.info é atualizado pela thread de E/S.

A correspondência entre as linhas do arquivo e as colunas mostradas por SHOW SLAVE STATUS aparece a seguir:

Linha Descrição
1 Master_Log_File
2 Read_Master_Log_Pos
3 Master_Host
4 Master_User
5 Senha (não mostrado por SHOW SLAVE STATUS)
6 Master_Port
7 Connect_Retry

O arquivo relay-log.info é atualizada pela thread de SQL. A correspondência entre as linhas do arquivo e as colunas mostradas por SHOW SLAVE STATUS apaerece a seguir:

Linha Descrição
1 Relay_Log_File
2 Relay_Log_Pos
3 Relay_Master_Log_File
4 Exec_Master_Log_Pos

Quando você faz backup dos dados de seu slave, você deve fazer backup destes 2 pequenos arquivos, junto com seus relay logs pois eles são necessários para continuar a replicação depois que você restaurar os dados do slave. Se você perder os seus relay logs mas ainda tiver o arquivo relay-log.info, você pode verifclos para determinar por quanto tempo a thread de SQL executou no log binário do master. Então você pode usar CHANGE MASTER TO com as opções MASTER_RELAY_LOG e MASTER_RELAY_POS para dizer ao slave para reler os log binários a partir deste ponto. Isto exige que o log binário ainda exista no servidor master. é claro.

Se seu slave está sujeito a replicação de instruções LOAD DATA INFILE, você também deve fazer backup dos arquivos SQL_L0AD-* que podem existir no diretório que o slave utiliza para este propósito. O slave precisará destes arquivos para continuar a replicação de qualquer instrução LOAD DATA INFILE interrompido.

A localização do diretório é especificada usando a opção --slave-load-tmpdir. Seu valor padrão, se não especificado, é o valor da variável tmpdir.

Como Configurar a Replicação

Aqui está uma descrição rápida de como configurar uma replicação completa em seu servidor MariaDB atual. Ele assume que você deseja replicar todos os bancos de dados e nunca configurou uma replicação anteriormente. Você precisará desligar seu servidor master rapidamente para completar os passos delineados abaixo.

O procedimento é gravado para a configuração de um único slave, mas você pode usá-lo para configurar vários slaves.

Este método é o modo mais direto de se configurar um slave, mas ele não é o único. Por exemplo, se você já tem uma cópia instantânea dos dados do master, e o master já tem o seu ID do servidor definido e o log binário habilitado, você pode configurar um slaver sem desligar o master ou mesmo bloquear suas atualizações. Para maiores detalhes, veja 'FAQ da Replicação'.

Se você deseja administrar uma configuração de replicação MySQL, sugerimos que leia todo este e experimente todos os comandos mencionados em 'Instruções SQL para Controle do Servidor Master' e 'Instruções SQL para Controle do Servidor Slave'. Você também deve se familiarizar com as opções de inicialização da replicação em my.cnf na 'Opções de Inicialização da Replicação'.

Note que este procedimento e algumas das instruções SQL da replicação em seções posteriores se referrem ao privilégio SUPER. Antes do MariaDB 4.0.2, use o privilégio PROCESS.

  1. Certifique-se que você possui uma versão recente do MariaDB instalado no servidor master e no(s) slave(s), e que estas versões sào compatíveis de acordo com a tabela mostrada em 'Visão Geral da Implementação da Replicação'.

    Por favor não relate os erros até que você tenha verificado que o problema está presente na última distribuição.

  2. Configure uma conta no servidor master com o com a qual o slave possa se conectar. Deve ser dada a esta conta o privilégio REPLICATION SLAVE. (Se a versão do MariaDB for anterior a 4.0.2, de à conta o privilégio FILE.) Se a conta é somente para a replicação (o que é recomendável), então você não precisará fornecer nenhum privilégio adicional para ele.

    O nome de máquina no nome da conta deve ser aquele usado por cada um dos servidores slaves para conectar ao master. Por exemplo, para criar um usuário chamado repl que pode acessar seu master de qualquer máquina, você deve utilizar este comando:

    mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%' IDENTIFIED BY '<password>';

    Para versões do MariaDB anteriores a 4.0.2, use este comando:

    mysql> GRANT FILE ON *.* TO repl@'%' IDENTIFIED BY '<password>';

    Se você planeja usar as instruções LOAD TABLE FROM MASTER ou LOAD DATA FROM MASTER a partir da máquina slave, você precisará de permissão para esta conta adicional.

    • Conceda a conta os privilégios globais SUPER e RELOAD.
    • Conceda o privilégio SELECT em todas as tabelas que você deseja carregar. Qualquer das tabelas master nas quais a conta não possa fazer um SELECT serão ignoradas por LOAD DATA FROM MASTER.
  3. Se você estiver usando tabelas MyISAM, descarregue todas as tabelas e bloqueie as consultas de escrita executando o comando FLUSH TABLES WITH READ LOCK 

    mysql> FLUSH TABLES WITH READ LOCK;

    e faça uma cópia de todos os dados existentes em seu servidor master.

    A maneira mais fácil de fazer isto é simplesmente usar um programa (tar no Unix, PowerArchiver, WinRAR, WinZip ou qualquer outro software similar no Windows) para produzir um arquivo de banco de dados no diretório de dados do seu master. Por exemplo, para usar tar que cria um arquivo que inclui todos os bancos de dados, altere a localização no diretório de dados do servidor master, e então execute este comando:

    shell> tar -cvf /tmp/mysql-snapshot.tar .

    Se você quiser que o arquivo inclua apenas um banco de dados chamado estebd, utilize este comando:

    shell> tar -cvf /tmp/mysql-snapshot.tar ./this_db

    Então copie o arquivo para o diretório /tmp na máquina servidora slave. Naquela máquina, altere a localização em um diretório de dados do slave e desempacote o arquivo usando este comando:

    shell> tar -xvf /tmp/mysql-snapshot.tar

    Você pode não desejar replicar o banco de dados MariaDB. Se não, você pode excluí-lo do arquivo. Você também não precisa incluir qualqer arquivo de log nos arquivos master.info ou relay-log.info.

    Enquanto o lock de leitura colocado por FLUSH TABLES WITH READ LOCK estiver em funcionando, leia o valor atual do nome do log binário e offset no master:

    mysql > SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| mysql-bin.003 | 73 | test,bar | foo,manual,mysql |
+---------------+----------+--------------+------------------+
1 row in set (0.06 sec)

    A coluna File exibe o nome do log, enquanto Position exibe o offset. No exemplo acima, o valor do log binário é mysql-bin.003 e o offset é 73. Grave os valores. Você precisará usá-los mais tarde quando estiver configurando o slave.

    Uma vez realizada a cópia e gravado o nome do log e offset, você pode reabilitar a atividade de escrita no master:

    mysql> UNLOCK TABLES;

    Se você estiver usando tabelas InnoDB, você deve usar a ferramente InnoDB Hot Backup que está disponível para aqueles que compraram as licenças comerciais do MariaDB, suporte ou a própria ferramenta de backup. Ele faz uma cópia consistente sem fazer nenhum lock no servidor master, e grava o nome do log e o offset correspondente em um snapshot para ser usado postriormente no slave. Mais informações sobre esta ferramenta esta disponível em http://www.innodb.com/order.php.

    Sem a ferramenta Hot Backup, o modo mais rápido para tirar uma cópia das tabelas InnoDB é desligar o servidor master e copiar os arquivos e logs de dados do InnoDB e os arquivos de definição de tabela (.frm). Para gravar o nome e offset do arquivo de log atual você deve fazer o seguinte antes de desligar o servidor:

    mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

    E então grave o nome e offset do log da saída de SHOW MASTER STATUS como mostrado anteriormente. Uma vez gravado o nome e o offset do log, desligue o servidor sem destravar as tabelas para se certificar que ele finalizará com a cópia correspondente ao arquivo de log e offset:

    shell> mysqladmin -uroot shutdown

    Uma alternativa para tabelas MyISAM e InnoDB é fazer um dump SQL do master em vez de uma cópia binária como acima; para isso você pode usar mysqldump --master-data em seu master e mais tarde executar o dump SQL em seu slave. No entanto, isto é mais lento que fazer a cópia binária.

    Se o master foi executado anteriormente sem o --log-bin habilitado, os valores do nome do log e da posição mostrados por SHOW MASTER STATUS ou mysqldump estarão vazios. Neste caso, grave a string vazia ('') para o nome do log e 4 para o offset.

  4. Assegure-se que a seção [mysqld] do arquivo my.cnf no master inclui a opção log-bin. Esta seção também deve conter a opção server-id=unique number, onde master_id deve ser um valor inteiro entre 1 e 2^32 - 1. Por exemplo: 

    [mysqld]
log-bin server-id=1

    Se estas opções não estão presentes, adicione-as e reinicie o servidor.

  5. Pare o servidor que será usado como slave e adicione o seguinte ao arquivo my.cnf: 

    [mysqld]
server-id=slave_id

    O valor slave_id, como o valor master_id, deve ser um valor inteiro de 1 to 2^32 - 1. Adicionalmente, é muito importante que o ID do slave seja diferente do ID do master. Por exemplo:

    [mysqld]
server-id=2

    Se você estiver usando vários servidores, cada um deve ter um valor server-id que seja diferente daquele do master e de cada um dos slaves. Pense nos valores de server-id como algo similar ao endereço IP: Estes IDs identificam de forma única cada instância de servidor na comunidade dos parceiros de replicação.

    Se você não quiser especificar um server-id, ele será configurado com 1 se você não tiver definido master-host, senão ele será definido com 2. Note que no caso de omissão do server-id, um master irá recusar conexões de todos os slaves e um slave irá recusar se conectar a um master. Assim, omitir server-id só é bom para backups com um log binário.

  6. Se você fizer um backup biário dos dados do servidor master, copie-o para o diretório de dados do servidor slave antes de iniciá-lo. Certifique-se que os privilégios nos arquivos e diretórios estão corretos. O usuário com o qual o MariaDB executa precisa estar apto a lê-los e alterá-los, assim como no master.

    Se você fizer um backup usando mysqldump, inicie o slave primeiro (veja o próximo passo).

  7. Inicie o servidor slave. Se ele tiver sido replicado previamente, inicie o servidor slave com a opção --skip-slave-start. Você também pode querer iniciar o servidor slave com a opção --log-warnings. Deste modo você irá obter mais mensagens sobre problemas (por exemplo, problemas de rede, ou conexão).
  8. Se você fez um backup dos dados do servidor master usando mysqldump, carregue o arquivo de dump no servidor slave: 

    shell> mysql -u root -p < dump_file.sql
  9. Execute os seguintes comandos no slave, substutitua os valores dentro de <> com o os valores atuais relevantes ao ser sistema: 

    mysql> CHANGE MASTER TO
 -> MASTER_HOST='<master host name>',
 -> MASTER_USER='<replication user name>',
 -> MASTER_PASSWORD='<replication password>',
 -> MASTER_LOG_FILE='<recorded log file name>',
 -> MASTER_LOG_POS=<recorded log offset>;

    A tabela a seguir lista o tamanho máximo da string para as variáveis:

    MASTER_HOST 60
    MASTER_USER 16
    MASTER_PASSWORD 32
    MASTER_LOG_FILE 255
  10. Inicie a thread slave: 

    mysql> START SLAVE;

Depois de realizado este procedimento, o slave deve se conectar ao master e pegar todas as atualizações que ocorreram desde que o backup foi restaurado.

Se você esqueceu de configurar o server-id no master, os slaves não poderão se conectar a eles:

Se você esqueceu de configurar o server-id no slave, você irá obter o seguinte erro no arquivo de log:

Warning: one should set server_id to a non-0 value if master_host is set.
The server will not act as a slave.

Você também encontrará mensagens de erro no log de erro do slave se ele não puder replicar por qualquer motivo.

Uma vez que um slave está replicando, você encontrará um arquivo chamado master.info e um chamado relay-log.info no diretório de dados. Estes dois arquivos são usados pelo slave para manter o registro de quanto foi processado do log binário do master. Não remova ou edite o arquivo, a menos que você realmente saiba o que está fazendo e entenda as implicações. Mesmo neste caso, é mais aconselhável usar o comando CHANGE MASTER TO.

NOTA: o conteúdo de master.info sobrepõe algumas opções especificadas na lina de comando ou no my.cnf veja 'Opções de Inicialização da Replicação' para mais detalhes.

Agora que você tem uma cópia instantânea, você pode usá-la para configurar outros slaves. Para isso siga a porção referente ao slave descrita acima. Você não precisa ter outra cópia do master.

Recursos de Replicação e Problemas Conhecidos

Abaixo uma explicação do que é e o que não é suportado:

A seguinte tabela lista problemas na versão 3.23 que estão corrigidas na versão 4.0:

Opções de Inicialização da Replicação

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 '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:

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 MariaDB, as seguintes opções também é tratada de forma especial:

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 MariaDB 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. Leia '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:

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:

  1. Existe alguma regra --replicate-do-db ou --replicate-ignore-db?

    • Sim: teste-as como para --binlog-do-db e --binlog-ignore-db (see '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.
  2. 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).
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.

Instruções SQL para Controle do Servidor Master

PURGE MASTER LOGS
RESET MASTER
SET SQL_LOG_BIN
SHOW BINLOG EVENTS
SHOW MASTER STATUS
SHOW MASTER LOGS
SHOW SLAVE HOSTS

0 replicação pode ser controlada por meio da interface SQL. Esta seção discute instruções para gerenciamento dos servidores masters de replicação. 'Instruções SQL para Controle do Servidor Slave' discute instruções para gerenciamento dos servidores slaves.

PURGE MASTER LOGS

PURGE {MASTER|BINARY} LOGS TO 'log_name'
PURGE {MASTER|BINARY} LOGS BEFORE 'date'

Deleta todos os logs binários que estão listados no índice de log anteriores ao log ou data especificado. O log também remove da lista gravada no índice de log, e assim o log dado se torna o primeiro.

Exemplo:

PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2003-04-02 22:46:26';

A variante BEFORE está disponível no MariaDB 4.1; este argumento de data pode estar no formato 'YYYY-MM-DD hh:mm:ss'. MASTER e BINARY são sinônimos, embora BINARY possa ser usado apenas a partir do MariaDB.

Se você tiver um slave ativo que está atualmente lendo um dos logs que você stá tentando deletar, este comando não faz nada e falha com um erro. No entanto, se você tiver um slave ativo e apagar um dos logs que ele quiser ler, o slave não poderá replicar uma vez que ele esteja ativo. O comando é seguro para de se executar enquanto os sslaves estiverem replicando. Você não precisa de pará-los.

Você deve primeiro verificar todos os slaves com SHOW SLAVE STATUS para ver qual log eles estão lendo, e então você deve fazer uma lista dos logs no master com SHOW MASTER LOGS, encontrar o log mais novo entre todos os slaves (se todos os slaves estão atualizados, ele será o último log da lista), tirar backup de todos os logs que você está prestes a deletar (opcional) e deletar até o log alvo.

RESET MASTER

RESET MASTER

Deleta todos os logs binários listado no arquivo de índice, zerando o arquivo de índice do log binário.

Esta instrução rea chamada FLUSH MASTER antes do MariaDB 3.23.26.

SET SQL_LOG_BIN

SET SQL_LOG_BIN = {0|1}

Disabilita ou habilita o log binário para a conexão do usuário (SQL_LOG_BIN é uma variável de sessão) se o cliente conecta usando uma conta que tem o privilégio SUPER. A instrução é ignorada se o cliente não possui este privilégio.

SHOW BINLOG EVENTS

SHOW BINLOG EVENTS [ IN 'log_name' ] [ FROM pos ] [ LIMIT [offset,] row_count ]

Mostra o evento no log binário. Se você não especificar 'log_name', o primeiro log binário será exibido.

Esta instrução está disponível a partir do MariaDB 4.0.

SHOW MASTER STATUS

SHOW MASTER STATUS

Fornece a informação de status no log binário do master.

SHOW MASTER LOGS

SHOW MASTER LOGS

Lista o log binário no master. Você deve usar este comando antes de PURGE MASTER LOGS para descobrir até onde você deve ir.

SHOW SLAVE HOSTS

SHOW SLAVE HOSTS

Mostra uma lista de slaves atualmente registrados com o master. Note que slaves não iniciados com a opção --report-host=slave_name não estarão visíveis nesta lista.

Instruções SQL para Controle do Servidor Slave

CHANGE MASTER TO
LOAD DATA FROM MASTER
LOAD TABLE tbl_name FROM MASTER
MASTER_POS_WAIT()
RESET SLAVE
SET GLOBAL SQL_SLAVE_SKIP_COUNTER
SHOW SLAVE STATUS
START SLAVE
STOP SLAVE

A replicação pode ser controlada por meio da interface SQL. Esta seção discute instruções para gerenciamento dos servidores slaves de replicação. 'Instruções SQL para Controle do Servidor Master' discute instruções para gerenciamento dos servidores master.

CHANGE MASTER TO

CHANGE MASTER TO master_def [, master_def] ...
master_def =
 MASTER_HOST = 'host_name'
 | MASTER_USER = 'user_name'
 | MASTER_PASSWORD = 'password'
 | MASTER_PORT = port_num
 | MASTER_CONNECT_RETRY = count
 | MASTER_LOG_FILE = 'master_log_name'
 | MASTER_LOG_POS = master_log_pos
 | RELAY_LOG_FILE = 'relay_log_name'
 | RELAY_LOG_POS = relay_log_pos
 | MASTER_SSL = {0|1}
 | MASTER_SSL_CA = 'ca_file_name'
 | MASTER_SSL_CAPATH = 'ca_directory_name'
 | MASTER_SSL_CERT = 'cert_file_name'
 | MASTER_SSL_KEY = 'key_file_name'
 | MASTER_SSL_CIPHER = 'cipher_list'

Altera os parâmetros que o servidor slave usa para conectar e comunicar com o servidor master. Os valores possíveis para o valor master_def estão mostrados acima.

As opções do relay log (RELAY_LOG_FILE e RELAY_LOG_POS) estão disponíveis a partir do MariaDB 4.0.

As opções SSL (MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY, e MASTER_SSL_CIPHER) estão disponíveis a partir do MariaDB. Você pode alterar estas opções mesmo nos slaves que são compilados sem suporte a SSL. Eles serão salvos no arquivo master.info mas ignorados até que você use um servidor que tenha suporte a SSL habilitado.

Por exemplo:

mysql> CHANGE MASTER TO
 -> MASTER_HOST='master2.mycompany.com',
 -> MASTER_USER='replication',
 -> MASTER_PASSWORD='bigs3cret',
 -> MASTER_PORT=3306,
 -> MASTER_LOG_FILE='master2-bin.001',
 -> MASTER_LOG_POS=4,
 -> MASTER_CONNECT_RETRY=10;
mysql> CHANGE MASTER TO
 -> RELAY_LOG_FILE='slave-relay-bin.006',
 -> RELAY_LOG_POS=4025;

MASTER_USER, MASTER_PASSWORD, MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT, MASTER_SSL_KEY, and MASTER_SSL_CIPHER are information for the slave to be able to connect to its master. If you don't specify some of these informations, the non-specified informations will keep their old value. For example, if the password to connect to your MariaDB master has changed, you just need to issue

mysql> STOP SLAVE; -- if replication was running
mysql> CHANGE MASTER TO MASTER_PASSWORD='new3cret';
mysql> START SLAVE; -- if you want to restart replication

to tell the slave about the new password; no need to specify the information which did not change (host, port, user etc).

MASTER_HOST, MASTER_PORT are the hostname or IP adress of the master host, and its TCP port. Note that if MASTER_HOST is equal to localhost, then, like in other parts of MySQL, the port may be ignored (if Unix sockets can be used for example).

Se você especificar MASTER_HOST ou MASTER_PORT, o slave assumirá que o mestre é diferente do anterior (mesmo se você especificar um valor de nost ou porta iguais ao do valor atual.) Neste caso Assim, os valores antigos do nome e posição do log binário do mestre não são mais aplicáveis, assim se você não especificar MASTER_LOG_FILE e MASTER_LOG_POS no comando, MASTER_LOG_FILE='' e MASTER_LOG_POS=4 são silenciosamente adicionados a ele.

MASTER_LOG_FILE e MASTER_LOG_POS são as coordenadas das quais a thread de E/S do slave começara a ler do master na próxima vez em que ele for iniciado. If you specify any of them, you can't specify RELAY_LOG_FILE or RELAY_LOG_POS. If none of MASTER_LOG_FILE and MASTER_LOG_POS was specified, then the last coordinates of the slave SQL thread before CHANGE MASTER was issued, are used. This ensures that replication has no discontinuity, even if the slave SQL thread was late compared to the slave I/O thread, when you just want to change, say, the password to use. This safe behaviour was introduced starting from MariaDB 4.0.17 and 4.1.1. (Before these versions, the used coordinates were the last coordinates of the slave I/O thread before CHANGE MASTER was issued, which caused the SQL thread to sometimes lose some events from the master, thus breaking replication.)

CHANGE MASTER TO deleta todos os relay logs (e inicia um novo), a menos que você especifique RELAY_LOG_FILE ou RELAY_LOG_POS (neste caso os relay logs serão mantidos; desde o MariaDB a variável global RELAY_LOG_PURGE será definida com zero sem aviso prévio). CHANGE MASTER TO atualiza master.info e relay-log.info.

CHANGE MASTER é util para configurar um slave quando você tem a cópia do master e gravou o registro e offset no master que corresponde a cópia tirada. Você pode executar CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master', MASTER_LOG_POS=log_offset_on_master no slave depois de restaurar a cópia.

O primeiro exemplo acima (CHANGE MASTER TO MASTER_HOST='master2.mycompany.com' etc) altera as coordenadas do master e do seu log binário. Isto é quando você deseja que o slave replique o master. O segundo exemplo, usado com menos frequência, é quando o slave possui relay logs que, por alguma razão, você deseja que o slave execute novamente; para fazer isto o master não precisa estar alcançavel, você só precisa fazer CHANGE MASTER TO e iniciar a thread de SQL (START SLAVE SQL_THREAD). Você pode usar isto mesmo fora da consiguração de replicação, em um servidor standalone, slave-de-ninguém, para recuperação depois de uma falha.

Suponha que o seu servidor tenha falhado e você tenha restaurado um backup. Você deseja reexecutar o próprio log binário do servidor (não os relay logs, mas logs binários regulares), supostamente chamado myhost-bin.*. Primeiro faça uma cópia destes logs binários em alguns lugares seguros, no caso de você não seguir exatamente o procedimento abaixo e acidentalmente apagar os logs binários de servidor. Se você estiver usando o MariaDB ou mais novos, defina SET GLOBAL RELAY_LOG_PURGE=0 para segurança adicional. Então inicie o servidor sem log-bin, com um novo ID do servidor (diferente do anterior), com relay-log=myhost-bin (para fazer o servidor acreditar que estes logs binários regulares são relay logs) e skip-slave-start, então execute estas instruções:

mysql> CHANGE MASTER TO
 -> RELAY_LOG_FILE='myhost-bin.153',
 -> RELAY_LOG_POS=410,
 -> MASTER_HOST='some_dummy_string';
mysql> START SLAVE SQL_THREAD;

Então o servidor irá ler e executar seus próprios logs binários, e assim conseguindo a recuperação de falhas. Uma vez que a recuperação está finalizada, execute STOP SLAVE, desligue o servidor, delete master.info e relay-log.info, e reinicie o servidor com suas opções originais. No momento, especificar MASTER_HOST (mesmo com um valor modelo) é compulsório para fazer o servidor pensar que ele é um slave, e dar ao servidor um novo ID, diferente do anterior é compulsório senão o servidor verá os eventos com seus IDs e pensará que ele está em uma configuração de replicação circular e ignora os eventos, o que é indesejado. No futuro planejamos adicionar opções para lidar com estas pequenas restrições.

LOAD DATA FROM MASTER

LOAD DATA FROM MASTER

Tira uma cópia do master para o slave. Atualiza os valores de MASTER_LOG_FILE e MASTER_LOG_POS assim o slave será iniciado replicando da posição correta. Respeitará a regras de exclusão de tabelas e bancos de dados especificadas com as opções replicate-*.

O uso desta instrução está sujeito ao seguinte:

No futuro está planejado fazê-lo funcionar com tabelas InnoDB e remover a necessidade de lock deleitura global usando o recurso de backup online sem bloqueio.

Se você estiver carregando tabelas grandes, você pode aumentar os valores de net_read_timeout e net_write_timeout no mestre e no slave. Veja 'SHOW VARIABLES'.

Note que LOAD DATA FROM MASTER NÂO copia nenhuma tabela do banco de dados MariaDB. Isto é para tornar facil de se ter diferentes usuários e privilégios no master e no slave.

Esta instrução exige que o usuário de replicação usado para se conectar ao master tenha privilégios RELOAD e SUPER no master, privilégios SELECT em todas as tabelas do master que você queira carregar. Todas as tabelas do master nas quais os usuários não tenham privilégio SELETC serão ignoradas pelo LOAD DATA FROM MASTER; isto ocorre porque o master irá esconde-los do usuário: LOAD DATA FROM MASTER chama SHOW DATABASES para saber qual banco de dados do master carregar, mas SHOW DATABASES retorna apenas o banco de dados nos quais o usuário tem algum privilégio. Veja 'Recuperando Informações sobre Bancos de Dados, Tabelas, Colunas e Índices'. No lado do slave, o usuário que executa LOAD DATA FROM MASTER deve ter permissão para apagar e criar o banco de dados e tabelas envolvidos.

LOAD TABLE tbl_name FROM MASTER

LOAD TABLE tbl_name FROM MASTER

Faz o download de uma cópia da tabela do master para o slave. Esta instrução é implementada principalmente para depuração de LOAD DATA FROM MASTER. Exige que o usuário de replicação que é usado para conectar ao master tenha privilégios RELOAD e SUPER no master, e SELECT na tabela do master que será carregada. No lado do slave, o usuário que envia LOAD TABLE FROM MASTER deve ter permissão para apagar e criar a tabela. Leia as anotações sobre tempo limite nadescrição de LOAD DATA FROM MASTER abaixo, elas se aplicam aqui também. Por favor, leia também as limitações de LOAD DATA FROM MASTER acima, elas também se aplicam (por exemplo, LOAD TABLE FROM MASTER só funciona com tabelas MyISAM).

MASTER_POS_WAIT()

SELECT MASTER_POS_WAIT('master_log_file', master_log_pos)

Esta é uma função, não um comando. É usada para assegurar que o slave tenha alcançado (lido e executado) uma dada posição no log binário do master. Veja 'Funções Diversas' para uma descrição completa.

RESET SLAVE

RESET SLAVE

Faz o slave esquecer a sua posição de replicação no log binário do master. Esta instrução é usada para uma inicialização limpa: ela deleta os arquivos master.info e relay-log.info, todos os relay logs e inicia um novo relay log. Nota: Todos os relay logs são deletados, mesmo se não forem totalmente executados pela threads SQL do slave. (Esta é uma condição que deveria existir em um slave de replicação altamente carregado, ou se você enviasse uma instrução STOP SLAVE.) As informações de conexão armazenadas no arquivo master.info são imediatamente recarregadas com os valores especificados nas opções de inicializacão, se forem especificadas. Estas informações incluem valores como máquina master, porta do master, usuário do master e senha do master. Se a thread SQL do slave estava no meio de uma replicação de tabelas temposrárias quando ela foi parada, e RESET SLAVE é excutado, estas tabelas temporárias replicadas são deletadas no slave.

Esta instrução era chamada FLUSH SLAVE antes do MariaDB 3.23.26.

SET GLOBAL SQL_SLAVE_SKIP_COUNTER

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n

Salta os próximos n eventos do master. Útil para recuperação de paradas da replicação causada por um erro.

Esta instrução só é válida quando a thread slave não está em execução, em caso contrário, retorna um erro.

Antes do MariaDB 4.0, omite a palavra chave GLOBAL da instrução.

SHOW SLAVE STATUS

SHOW SLAVE STATUS

Fornece a informação de status nos parâmetros essenciais da thread do slave. Se você utilizar esta instrução usando no cliente MariaDB, você pode usar o terminador \G em vez de um ponto e vírgula no fim, para conseguir um layout vertical mais legível:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
 Slave_IO_State: Waiting for master to send event
 Master_Host: localhost
 Master_User: root
 Master_Port: 3306
 Connect_Retry: 3
 Master_Log_File: gbichot-bin.005
 Read_Master_Log_Pos: 79
 Relay_Log_File: gbichot-relay-bin.005
 Relay_Log_Pos: 548
Relay_Master_Log_File: gbichot-bin.005
 Slave_IO_Running: Yes
 Slave_SQL_Running: Yes
 Replicate_Do_DB:
 Replicate_Ignore_DB:
 Last_Errno: 0
 Last_Error:
 Skip_Counter: 0
 Exec_Master_Log_Pos: 79
 Relay_Log_Space: 552
 Until_Condition: None
 Until_Log_File:
 Until_Log_Pos: 0
 Master_SSL_Allowed: No
 Master_SSL_CA_File:
 Master_SSL_CA_Path:
 Master_SSL_Cert:
 Master_SSL_Cipher:
 Master_SSL_Key:
Seconds_Behind_Master: 8

Dependendp da sua versão do MariaDB, você pode não ver todos os campos como aqui mostrado. Alguns campos estão presentes apenas a partir do MariaDB.

Os campos mostrados por SHOW SLAVE STATUS tem o seguinte significado:

START SLAVE

START SLAVE [thread_name [, thread_name] ... ]
START SLAVE [SQL_THREAD] UNTIL
 MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos START SLAVE [SQL_THREAD] UNTIL
 RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos thread_name = IO_THREAD | SQL_THREAD

START SLAVE sem nenhuma opção inicia ambas as threads slaves. A thread de E/S lêem as consultas do servidor master e as armazena no relay logs. A thread de SQL le o relay log e executa a consulta. Note que se START SLAVE obter sucesso no inicialização da thread slave ela retornará sem qualquer erro. Mas mesmo neste caso pode ser que a thread slave iniciou e parou mais tarde (por que elas não conseguiram se conectar ao master ou leram o seu log binário ou qualquer outro problema). START SLAVE não lhe avisará sobre insto. Você deverá verifica seu arquivo log de erro do slave por mensagens de erro gerada pela thread slave, ou verificar que eles estão rodando bem com SHOW SLAVE STATUS.

A partir do MariaDB 4.0.2, você pode adicionar as opções IO_THREAD ou SQL_THREAD à instrução a ser chamada quando a thread iniciar.

A partir do MariaDB, uma cáusula UNTIL pode ser adicionada para especificar que o slave deve iniciar até que a thread de SQL alcance um determinado ponto no log binário dp master ou no relay log do slave. Quando a thread SQL alcança este ponto, ela para. Se a opção SQL_THREAD é especificada na instrução, ela inicia apenas a thread de SQL. Senão, ela inicia ambas as threads slaves. Se a thread SQL já estiver em execução, a claúsula UNTIL é ignorada e um aviso é enviado.

Com uma cláusula UNTIL, você deve especificar tanto uma nome de arquivo de log quanto uma posição. Não misture opções do master e do relay logs.

Qualquer condição UNTIL é restaurada por uma instrução STOP SLAVE subsequente, ou uma instrução START SLAVE que não incluir a cláusula UNTIL, ou um servidor reinicie.

A cláusula UNTIL pode ser útil para depurar a replicação, ou para fazer com que a replicação proceda até um pouco antes do ponto que você deseja evitar que o slave replique uma instrução. Por exemplo, se uma instrução DROP TABLE foi executada no master, você pode usar UNTIL para dizer ao slave para executar até aquele ponto, mas não depois. Para encontrar qual é o evento, use mysqlbinlog com o log do master ou o relay logs, ou usando uma instrução SHOW BINLOG EVENTS.

Se você estiver usando UNTIL para ter o processo slave replicando consultas nas seções, é recomendado que você inicie o slave com a opção --skip-slave-start para evitar que a thread de SQL execute quando o slave iniciar. É provavelmente melhor usar esta opção em um arquivo de opção em vez de usá-la na linha de comando, assim uma reinicialização inesperada do servidor não faz com que isso seja esquecido.

A instrução SHOW SLAVE STATUS inclui campos na saída que mostram o valor atual da condição UNTIL.

Este comando é chamado SLAVE START antes do MariaDB 4.0.5. No momento, SLAVE START ainda é aceito para compatibilidade com versões anteriores, mas está obsoleto.

STOP SLAVE

STOP SLAVE [thread_name [, thread_name] ... ]
thread_name = IO_THREAD | SQL_THREAD

Para a thread slave. Como o START SLAVE, esta instrução pode ser usada com as opções IO_THREAD e SQL_THREAD para chamar a thread ou threads que irão parar.

Este comando é chamado SLAVE STOP antes do MariaDB 4.0.5. No momento, SLAVE STOP ainda é aceito para compatibilidade com versões anteriores, mas está obsoleto.

FAQ da Replicação

P: Como eu configuro um slave se o master já estiver em execução e eu não quiser pará-lo?

R: Existem diversas opções. Se você tirou um backup do master em alguns pontos e gravou o nome e offset do log binário (da saída do SHOW MASTER STATUS) correspondente à cópia, faça o seguinte:

  1. Esteja certo de que o slave possuí um ID server único.
  2. Execute as seguintes instruções no slave, preenchendo os valores apropriados para cada parâmetro: 

    mysql> CHANGE MASTER TO
 -> MASTER_HOST='master_host-name',
 -> MASTER_USER='master_user_name',
 -> MASTER_PASSWORD='master_pass',
 -> MASTER_LOG_FILE='recorded_log_name',
 -> MASTER_LOG_POS=recorded_log_pos;
  3. Execute START SLAVE no slave.

Se você já não tiver um backup do master, aqui está um modo rápido de fazê-lo de forma consistente:

  1. FLUSH TABLES WITH READ LOCK
  2. gtar zcf /tmp/backup.tar.gz /var/lib/mysql ( ou uma variação disto)
  3. SHOW MASTER STATUS - esteja certo de gravar a saída - você precisará dela mais tarde
  4. UNLOCK TABLES

Uma alternativa é tirar um dump do SQL do master em vez de uma cópia binária como acima; para isto você podee usar mysqldump --master-data em seu master e posteriormente executar este dump SQL em seu slave. Isto é, no entanto, mais lento que fazer uma cópia binária.

Não importa qual dos dois métodos você usa, mais tarde siga as instruções para o caso em que você tem uma cópia e gravou o nome e offset dos logs Você pode usar a mesma cópia para configurar diversos slaves. Uma vez que os logs binários do master estão intáctos, você pode esperar por dias ou meses para configurar um slave uma vez que você possui a cópia do master. Em teoria a lacuna de espera pode ser infinita. As duas limitações práticas é o espaço em disco do master sendo preenchido com logs antigos e a quantidade de tempo que o slave gastará para buscá-los.

Você também pode usar LOAD DATA FROM MASTER. Este é um comando conveniente que tira uma cópia, a restaurá no slave e ajustar o nome e offset do log no slave, todos de uma vez. No futuro, LOAD DATA FROM MASTER será o modo recomendado de configurar um slave. Esteja avisado, no entanto, que o lock de leitura pode ser mantido por um longo tempo se você usar este comando. Ele ainda não está implementado de forma tão eficiente quanto gostariamos. Se você tiver tabelas grandes, o método preferível neste momento ainda é com uma cópia tar local depois de executar FLUSH TABLES WITH READ LOCK.

P: O slave precisa estar conectado ao master o tempo todo?

R: Não, ele não precisa. O slave pode ser desligado ou permanecer desconectado por horas ou mesmo dias, então reconecta e busca as atualizações. Por exemplo, você pode usar uma relação master/slave sobre uma conexão dial-up que está ligada esporádicamente apenas por um curto período de tempo. A implicação disto é que a uma hora dada qualquer não temos garantias de que o slave está sincronizado com o master a menos que você tire algumas medidas especiais. No futuro, teremos a opção de bloquear o master até que pelo menos um slave esteja sincronizado.

P: Como posso saber se um slave está atrasado comparado ao master? Em outra palavras, como eu sei que o dado da última consulta replicada pelo escravo?

R: Se o slave for 4.1.1 ou mais novo, leia a coluna Seconds_Behind_Master de SHOW SLAVE STATUS. Para versão mais antigas o seguinte se aplica. Isto só é possível se a thread salve de SQL existir (p.ex. se ele for exibida em SHOW PROCESSLIST, see 'Detalhes de Implementação da Replicação') (no MariaDB 3.23: se a thread slave existir, p.ex. e mostrada em SHOW PROCESSLIST), e se ela executou pelo menos um evento do master. Realmente, quando a thread slave de SQL executa um evento lido do master, esta thread modifica seu próprio tempo do timestamp do evento (é por isto que TIMESTAMP é bem replicado). Assim é indicado na coluna Time na saída de SHOW PROCESSLIST, o número de segundos entre o timestamp do último evento replicado e o tempo real da máquina slave. Vopcê podee usar isto para determinar a data do último evento replicado. Note que se o seu slave foi desconectado do master por uma hora e então reconectado, você poderá ver uma vlaor de 3600 na coluna Time para a thread slave de SQL em SHOW PROCESSLIST... Isto ocorreria porque o slave está executando consultas de uma hora atrás.

P: Como eu forço o master a bloquear as atualizações até que o slave as busque?

R: Use o seguinte procedimento:

  1. No master, execute estes comandos: 

    mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

    Grave o nome do log e o offset da saída da instução SHOW.

  2. No slave, execute este comando, onde as coordenadas da replicação que são os argumentos da função MASTER_POS_WAIT() são os valores gravados nos passos anteriores: 

    mysql> SELECT MASTER_POS_WAIT('log_name', log_offset);

    A instrução SELECT será bloqueada até que o slave alcance o arquivo de log e offset especificados. Neste ponto, o slave estará em sincronia com o master e a instrução irá retornar.

  3. No master, execute a seguinte instrução para permitir que o master comece a processar atualizações novamente: 

    mysql> UNLOCK TABLES;

P: Sobre quais assuntos eu devo estar ciente ao configurar uma replicação de duas vias?

R: Atualmente a replicação do MariaDB não suporta nenhum protocolo de locking entre master e slave para garantir a atomicidade de uma atualização distribuída (entre servidores). Em outras palavras, é possível para um cliente A fazer uma atualização para um co-master 1, e neste tempo, antes de propagar para o co-master 2, o cliente B pode fazer uma atualização para o co-master 2 que fará a atualização do cliente A funcionar diferentemente da que ele fez no co-master 1. Assim, quando a atualização do cliente A fizer a atualização para o co-master, ele produzirá tabelas que são diferentes daquelas que você tem no co-master 1, mesmo depois de todas as atualizações do co-master2 também terem sido propagadas. Por isso você não deve co-encadear dois servidores em uma replicação de duas vias, a menos que você possa assegurar que suas atualizações possem seguramente ocorrer em qualquer ordem, ou que de alguma forma você cuide de alguma forma a atualização fora de ordem no código do cliente.

Você também deve perceber que replicação de duas vias não melhorar em muito o desempenho, já que temos atualizações envolvidas. Ambos os servidores precisam fazer a mesma quantidade de atualizações cada, como se tivesse um servidor. A única diferença é que haverá uma pouco menos de contenção de lock, porque as atualizações originando em outro servidor serão serializadas em uma thread slave. mesmo assim, este benefício pode ser por atrasos de rede.

P: Como eu posso usar replicação para melhorar a performance do meu sistema?

R: Você devev configurar um servidor como master e direcionar todas as escritas para ele. Então configure tantos slaves quantos você pode comprar e instalar, e distribua as leituras entre o master e os slaves. Você também pode iniciar os slaves com --skip-bdb, --low-priority-updates e --delay-key-write=ALL para conseguir aumento de velocidade para o slave. Neste caso o slave usará tabelas MyISAM não transacionais em vez de tabelas BDB para conseguir mais velocidade.

Q: O que eu devo fazer para preparar o código do cliente em minhas próprias aplicações para usar replicação para melhora de performance?

A: Se a parte do seu código que for responsável pela acesso ao banco de dados tiver sido abstaído/modularizado apropriadamente, converte-lo para executar com uma configuração de replicação deve ser bem fácil. Apenas altere a implementação de seu acesso a banco de dados para enviar todas as escritas para o master e todas as leituras para o master e o slave. Se o seu código não tiver este nível de abstração, configurar um sistema de replicação lhe dará a oportunidade e motivação de limpá-lo. Você deve iniciar criando uma biblioteca ou módulo wrapper com as seguites funções:

safe_ no nome de cada função significa que a função cuidará do tratamento de todas as condições de erro.

Você pode, é claro, usar diferentes nomes para as funções. O importante é ter uma interface unificada para conexão para leitura, conexão para escrita, fazer uma leitura e fazer uma escrita.

Você deve então converter o código do seu cliente para usar a biblioteca wrapper. Este pode ser um processo doloroso e assustador a princípio, mas será gratificante a longo prazo. Todas as aplicações que usam a abordagem descrita poderão tirar vantagem de uma configuração master/slave, mesmo envolvendo vários slaves. O código será muito mais fácil de manter, e adicionar opções para soluções de problemas será trivial. Você só precisará modificar uma ou duas funções, por exemplo, para registrar quanto tempo uma consulta gastou ou qual consulta, entre todas elas, retornou um erro.

Se você já tiver escrito muito código, você pode querer automatizar a conversão de tarefas usando o utilitário replace, que vem com a distribuição padrão do MariaDB, ou simplesmente escrever seu próprio script Perl. Provavelmente, o seu código segue algum padrão de reconhecimento. Se não, então talvez sejá melhor reescrevê-lo ou pelo menos colocá-lo dentro de um padrão.

Q: Quando e em quanto a replicação do MariaDB pode aumentar a performance do meu sistema?

A: A replicação do MariaDB é mais benéfica para um sistema com leituras frequentes e escritas infrequentes. Em teoria, usando uma configuração um mastre/vários slaves você pode escalar o sistema adicionando mais slaves até que você fique sem largura de banda na rede, ou a sua carga de atualizações cresça ao ponto que o master não possa tratá-la.

Para determinar quantos slaves você pode ter antes dos benefícios adicionados começarem a estabilzar e quanto você pode melhorar o desempenho do seu site, você precisa saber o padrão de suas consultas e determinar empiricamente (pelo benchmark) a ralação entre a taxa nas leituras (leituras por segundo, ou max_reads) e nas escritas (max_writes) em um master e um slave comum. O exemplo aqui lhe mostrará um calculo simplificado do que você pode obter com replicação para o nosso sistema hipotético.

Vamos dizer que o sistema de cargas consiste de 10% de escrita e 90% de leitura, e determinamos max_reads para ser 1200 - 2 * max_writes. Em outras palavras, nosso sistema pode fazer 1200 leituras por segundo sem nenhuma escrita, a escrita média é duas vezes mais lenta que a leitura média e a realação é linear. Vamos supor que o master e cada slave possuem a mesma capacidade, e temos 1 master e N slaves. Então temos para cada servidor (master ou slave):

leituras = 1200 - 2 * escritas (a partir do benchmark)

leituras = 9* escritas / (N + 1) (as leituras são separadas, mas a escrita deve ir para todos os servidores)

9*escritas/(N+1) + 2 * escritas = 1200

escritas = 1200/(2 + 9/(N+1)

Esta análise leva as seguintes conclusões:

Note que nossos calculos assumem uma largura de banda de rede infinita, e negligencia vários outros fatores que podiam se tornar significante em seu sistema. Em muitos casos, você pode não conseguir fazer um cálculo similar ao acima que irá predizer exatamente o que acontecerá em seus sistema se você adicionar N slaves de replicação. No entanto, responder as seguintes questões deve ajudá-lo a decidir quando e quanto a replicação aumentará a performance do seu sistema:

P: Como eu posso usar replicação para fornecer redundância/alta disponibilidade?

R: Com os recursos disponíveis atualmente, você teria que configurar um master e um slave (ou diversos slaves) e escrever um script que monitoraria o master para ver se ele está no ar e instruir as suas aplicações e os slaves do master a alterar no caso de falha. Sugestões:

Atualmente estamos trabalhando na integração de um sistema de eleição de master autmotico dentro do MariaDB, mas até que ele esteja pronto, você terá que criar suas próprias ferramentas de monitoramento.

Problemas com Replicação

Se você tiver seguido as instruções e suia configuração de replicação não está funcionando, primeiro verifique o seguinte:

Relatando Problemas de Replicação

Quando você tiver determinado que não há erro de usuário envolvido, e a replicação ainda não funciona perfeitamente ou está instável, é hora de começar a fazer num relatório de erros. Nós precisamos do máximo de informações que você puder fornecer para conseguirmos rastrear o bug. Por favor gaste algum tempo e esforço preparando um bom relato de erro.

Se você tiver uma forma repetitível de demonstrar o problema, por favor inclua-o em nosso banco de dados de bugs https://jira.mariadb.org. Se você tem um problema de fantasma (um problema que não pode ser duplicado a sua vontade), use o seguinte procedimento:

  1. Verifique se nenhum erro de usuário está envolvido. Por exemplo, se você atualiza o slave fora da thread slave, os dados podem ficar fora de sincronia e podem ocorrer violações de chave única nas atualizações. Neste caso a thread slave irá terminar e esperar que você limpe as tabelas manualmente para entrar em sincronia. Este não é um problema de replicação; é um problema de interferência externa que faz com que a replicação falhe.
  2. Execute o slave com as opções log-slave-updates e log-bin. Elas farão com que o registre todas as atualizações que ele receber no seu próprio log binário.
  3. Salve todas as evidências antes de restaurar o estado da replicação. Se não tivermos nenhuma informação ou apenas algum esboço, será um pouco mais difícil para rastrearmos o problema. As evidências que você deve coletar são:

    • Todos os logs binários no master
    • Todos os logs binários no slave
    • A saída de SHOW MASTER STATUS no master na hora que você descobriu o problema.
    • A saída de SHOW SLAVE STATUS no master na hora que você descobriu o problema.
    • Logs de erro no master e no slave
  4. Utilize mysqlbinlog para examinar os logs binários. A informação a seguir pode ser útil para encontrar a consulta problemática, por exemplo: 

    mysqlbinlog -j pos_from_slave_status /caminho/para/log_do_slave | head

Uma vez que você coletou as evidências do problema fantasma, tente isolá-lo em um caso de testes separados inicialmente. Então relate o problema para https://jira.mariadb.org/ com a maior quantidade possíveis de informações.

Anterior Próximo
Tutorial de Introdução Do MySQL Início Otimização do MariaDB