Mysql for IBMers

Treinamento MySQL Administrators
For IBMers
Subjects of this training are based on “SCMDBA” certification curriculum path of MySQL Oracle ®
By Wagner Bianchi - IBM Global Delivery BrazilBy Wagner Bianchi - IBM Global Delivery Brazil

Apresentação
Objetivos deste treinamento:
Este treinamento tem o objetivo de apresentar a arquitetura do servidor
de bancos de dados MySQL e suas principais features nas versões mais
atuais, 5.0 e 5.1 - com a intenção de formação de competências e
habilidades para a atuação no gerenciamento, controle e monitoramento
do produto aqui focado, aumentando assim, o poder de resolução de
incidentes pelos membros da equipe IBM.

Apresentação
Colaborador:
Wagner Bianchi é tecnólogo em Gerenciamento de Banco de Dados com ênfase
em Sistemas de Informação e atualmente cursa o MBA em Administração de Empresas
pela Fundação Getúlio Vargas.
Possui certificações Sun MySQL 5.0 Certified Associate (SCMA), Sun MySQL 5.0
Developer (SCMDEV I e II), Sun MySQL 5.0 Database Administrator (SCMDBA I e II) e
desde de junho/2010 atua pela IBM Brasil. Possui experiência de 6 anos com o servidor
de bancos de dados MySQL, tendo publicado vários artigos sobre o produto em
ambiente Linux. Trabalhando com plataforma Microsoft, possui as certificações que
compõem o pacote MCDBA – SQL Server 2000. Em 2009, foi reconhecido como Sun
Microsystems Official MySQL Instructor e MySQL Evangelist.

Apresentação
Mapa do laboratório:
O laboratório escolhido para a execução deste treinamento está equipado
com computadores com o mínimo de 1GB de RAM, processador Core 2
Duo, munidos do sistema operacional MS Windows XP, com o MySQL
5.1.47 à instalar, máquina virtual VirtualBox rodando o sistema
operacional Ubuntu 10.04 LTS com acesso à internet para a instalação do
MySQL a partir do s repositórios listados no arquivo
/etc/apt/sources.list.
Após instalado o MySQL, o aluno será orientado a efetuar o restore do
arquivo world.sql, que estará localizado no desktop do sistema
operacional Ubuntu 10.04 LTS, CentOS 5.5 ou Debian 5 da máquina
virtual, denominada MySQL01.

Era uma vez…
O MySQL inicialmente foi batizado como msql e surgiu da iniciativa de três
amigos (Michael “Monty” Widenius, David Armarx e Allan Larsson) que
fazia parte do time de uma empresa suéca chamada TcX;
Eles não tinham opções com boa velocidade para recuperar dados para
fomentar a necessidade de obter relatórios e assim, decidiram escrever
um amontoado de “pilhas de array” para armazenar os dados;
Anos depois, surgiu o MySQL 3.23 que ainda era considerado um
gerenciador de arquivos, já contava com recursos como InnoDB e
replicação. Um grande marco foi o lançamento da versão 5.0 em 2004;
Michael Monty Widenius colocou no produto MySQL a primeira sílaba
do nome de sua filha mais nova, Myrian. Hoje, continua cuidando
do MySQL em um projeto denominado MariaDB, nome de sua 2 filha.

Ementa de Treinamento
Instalação do SGBD MySQLInstalação do SGBD MySQL
Arquitetura de SGBD MySQL
Logs
Arquivo de Configuração
Storage Engines
Manutenção de Tabelas
Variáveis de Ambiente
Variáveis de Status
Comandos Administrativos
INFORMATION_SCHEMA
Gerenciamento de Usuários
Scale-Out e Alta-Disponibilidade
Certificação – Curriculum Path

Instalação do SGBD MySQL
A instalação do servidor de bancos de dados MySQL é uma das instalação
mais fáceis de se realizar se comparada à instalações de outros servidores;
As complexidades são inerentes ao sistema operacional do host, que
poderá afetar não só a sua instalação como um todo, mas também
questões sérias ligadas ao fator performance;
Para ambientes que optam por utilizar o MySQL em plataforma Microsoft,
sua instalação é realizada através do sistema “Next-Next-Finish”, que
conduzirá o usuário até o final da instalação, passando por configurações
padronizadas ou detalhadas;

Linux x Windows (MySQL’s Performance)
Box Configuration:
-> Intel Itanium HT 9300 64x
-> 8GB RAM

Para clientes que optam por utilizar o MySQL em ambiente munido com
sistemas operacionais Unix Like (distribuições Linux e/ou Unix), a
instalação do MySQL requer um pouco mais de trabalho “braçal”;
Ter uma boa noção dos principais comandos suportados pela distribuição
Linux utilizada é um fator decisivo para o manuseio de arquivos, proceder
com a listagem dos diretórios e a execução da instalação via pacotes;
O usuário poderá automatizar a execução dos pacotes requeridos para
instalação via gerenciadores como o apt-get para distribuições Linux
baseados no Debian ou ainda com o rpm que estão disponíveis em
“distros” baseadas no Red Hat;

Instalações podem ser efetuadas a partir de pacotes pré-compilados ou
ainda via código-fonte – este último é desencorajado pela equipe MySQL
Oracle em seu manual de referência online por ser o último pacote a
receber as novas release candidate features;
Um instalação do MySQL via código-fonte requer que o administrador de
bancos de dados tenha um conhecimento mais apurado relacionado com
sistemas operacionais Unix Like, pois são necessárias a instalação de
bibliotecas especiais;
Faremos a instalação em ambiente linux, neste treinamento, utilizando
pacotes rpm localizados no diretório /root. Lembre-se de estar logado
com o usuário “root”;

Instalação do SGBD MySQL – CentOS 5.5
A distribuição de linux CentOS é uma versão free do Red Hat, distribuição
esta que a maioria das empresas as quais privam por suporte provido pelo
próprio fabricante utilizam (saiba mais em www.centos.org);
A única diferença entre o CentOS e o Red Hat é que este último é
radicalmente conservador e livre de bugs, enquanto aquele que
utilizaremos para explorar o treinamento atual poderá apresentar alguma
instabilidade em u ambiente com muitos hits;
É uma alternativa interessante para aquele que deseja testar o MySQL
para finalidades de simular o mesmo em ambiente Red Hat, pois, utiliza
este último utiliza o mesmo formato de file system e gerenciador de
pacotes - rpm;

O primeiro passo para a instalação é acessar o site mysql.com e clicar em
download. O browser do usuário será guiado para selecionar os pacotes
de acordo com o sistema operacional no qual o MySQL será aplicado;
Selecione Red Hat & Oracle Enterprise Linux e na sequência proceder
com o download dos pacotes assinados com as seguintes nomeclaturas:
– MySQL-client…
– MySQL-server…
– MySQL-shared…
– MySQL-shared-compact…

Após baixar e salvar os arquivos em uma pasta acessível no file system do
sistema operacional local, utilize o comando rpm para instalação dos
pacotes do MySQL;
Não há uma ordem na qual os pacotes deverão ser executados, mas,
considere execute primeiro o server, depois os clients (MySQL-client e
MySQL-shared*);
shell> rpm –i MySQL-server-community-5.1.48-1.rhrelx.i386.rpm

Após a instalação, é necessário proceder com algumas verificações de
segurança, pois, alguns usuários devem ser removidos, assim como o
banco de dados test, sendo que outras configurações também devem ser
realizadas;
O Administrador de Bancos de dados não precisa se preocupar quanto a
uma sequência de tasks à executar, basta rodar um aplicativo que é
disponibilizado juntamente com a instalação do MySQL:
shell> mysql_secure_installation

O aplicatiovo mysql_secure_installation guiará o DBA na realização
das principais tarefas que trarão o servidor de bancos de dados MySQL a
produção de forma mais segura;
O que este aplicativo fará, interagindo com o DBA:
– Setará uma senha para o usuário root – caso esta já tenha sido configurada,
entre a mesma senha novamente;
– Remoção de usuários anônimos – este usuários são criados com a instalação e
necessitam ser removidos quando o MySQL for colocado em produção;
– Oferece a possibilidade de permitir que o root acesse o servidor MySQL
apenas a partir do host local;
– Oferece a remoção do test database;
– Após o término do run deste script, relê as tabelas de privilégios;

Após finalizar a instalação física e rodar o utilitário para garantir a
segurança do banco, verificar se os processos continuam “de pé” com o
comando abaixo:
shell> ps –aux | grep mysqld*
Este comando listará todos os processos que tenham a string “mysqld%”,
da lista de processos do Linux;
Neste momento, se você fez a instalação conforme citamos neste
treinamento, você verá 3 processos;

Como veremos à frente neste treinamento, o MySQL conta com algumas
variáveis que definem várias propriedades de seu ambiente, sendo duas
de grande importâcia para citarmos neste momento;
Uma instalação padrão do MySQL em ambiente Unix Like, contará com o
conteúdo do BASEDIR com o path /usr e o DATADIR com o path
/var/lib/mysql, tendo o seu arquivo de configuração disponível por
padrão nos seguintes locais:
– /etc
– /etc/mysql

Dentro do que é chamado de BASEDIR, que é na verdade o diretório de
instalação do MySQL, ficam localizados os aplicativos e scripts necessários
para o running status servidor de bancos de dados MySQL;
Neste diretório é encontrado um subdiretório “bin”, onde se encontram
vários dos aplicativos e principalmente o mysqld e o mysqld_safe:
– mysqld: é o próprio MySQL. Este é o deamon que recebe todas as
requisições e manipula toda a arquitetura interna do servidor de bancos de
dados;
– mysqld_safe: script em shell, responsável por checar se o mysqld está
rodando. Caso o mysqld caia por algum motivo, o mysqld_safe tentará
levantá-lo e escreverá no log de erros o motivo da queda e o momento
(data/hora) em que o SGBD foi erguido ou não;

Arquitetura de SGBD MySQLArquitetura de SGBD MySQL
Logs
Storage Engines
INFORMATION_SCHEMA

Arquitetura do SGBD MySQL
O servidor de bancos de dados MySQL é um software que utiliza o sistema
computacional de forma bastante otimizada, buscando fazer muito com
muito poucos componentes;
Se divide em duas camadas, sendo que na primeira camada encontram-se
os chamados de core-subsystems que controlam desde o parser de
instruções SQL, passando pela otimização e execução de consultas com
base em caches e buffers previamente criados;
Na segunda camada encontram os motores de armazenamento ou os
chamados Storage Engines que dão ao MySQL toda a flexibilidade
necessária para que este se encaixe bem em qualquer tipo de projeto;

Cada novo banco de dados que é criado em um servidor de bancos de
dados MySQL, é um novo diretório no DATADIR;
Diferentemente de outros produtos de bancos de dados que armazenam
os dados em um só arquivo ou mesmo, arquivos particionados, o MySQL
poderá criar um ou vários arquivos por tabela;
O comportamento de localização do DATADIR e do BASEDIR são
controlados pelo arquivo de configuração do MySQL que é lido todos as
vezes que o servidor de bancos de dados é reiniciado;
Veremos mais à frente que o MySQL possui vários tipos de logs para
armazenar informações sobre o seu funcionamento;

A comunicação com o servidor de bancos de dados MySQL é realizada
seguindo o modelo cliente-servidor – vários clientes requisitam
informações de um servidor mediante login, host e senha;
Cada conexão é tratada como uma nova thread que é criada – ou
reutilizada – para atender as requisições do lado externo ao SGBD, sendo
o MySQL um servidor de bancos de dados multi-threaded;
O servidor de bancos de dados MySQL, aquele que recebe todas as
conexões é o binário mysqld, que poderá ser verificado no MS Windows
pelo gerenciador de tarefas (Ctrl+Alt+Del) ou através do comando ps, no
terminal do Linux;

Dentro do processo maior que é o mysqld, vários outros pequenos
programas, conhecidos como módulos estão rodando e interagindo com
as requisições dos usuários;
Assim que o mysqld é levado para a memória, várias estruturas internas
são levadas consigo, tais como:
– Gerenciador e Controlador de threads;
– Grant Tables, que são as tabelas do banco de dados mysql que armazenam os
dados de usuários, como permissões, host e senha (criptografada);
– Estruturas de buffers e caches como key_buffer, buffer_pool e query cache;
– Buffer Log Transactions – innodb_log_buffer_size;
– MEMORY tables do dicionário de dados – INFORMATION_SCHEMA;

O MySQL, por ser um servidor de bancos de dados multi-plataforma,
suporta vários protocolos e pontes de comunicação para que conexões
sejam estabelecidas;
Protocolo Tipo Conexão Sistemas Operacionais
Socket File Local Unix Like Only
TCP/IP Local, Remote All
Named Pipes Local Windows Only
Shared Memory Local Windows Only

Os protocolos de comunicação --named-pipes e --shared-memory são
desabilitados por default em ambiente MS Windows. Para habilitá-los,
precisaremos iniciar o MySQL com estes parâmetros;
Conexões locais em Unix Like systems utilizam o arquivo de socket que é o
mais rápido meio de tráfego de dados (input/output) entre clientes e o
servidor e somente está disponível para conexões “localhost”;
– Conexões que utilizam o IP 127.0.0.1 utilizam TCP/IP – “driblam” o socket;
Para se conectar ao servidor de bancos de dados MySQL, podemos fazê-
la através de interfaces gráficas e/ou através do prompt de comandos ou
ainda, utilizando o terminal;

Em linha de comando, podemos utilizar o aplicativo cliente denominado
“mysql”. Este aplicativo é disponibilizado durante a instalação do MySQL;
Após a instalação do MySQL, basta abrirmos o terminal ou prompt e
chamar o aplicativo, adicionando alguns parâmetros:
• -u <usuario>
• -p<senha> ***atenção***
• -h <ip_do_host_onde_roda_o_mysql>
• -P <porta>

Conexão a um servidor MySQL local:
shell> mysql –u usuario_ibm –p
Conexão a um servidor rodando no IP 192.168.1.2 na porta 3308:
shell> mysql –u usuario_ibm –p –h 192.168.1.2 –P 3308
Conexão a um servidor remoto utilizando um valor DNS:
shell> mysql –u usuario_ibm –p –h mysqlibm000120

Além de acessar o MySQL através de 3rd
party apps ou utilizando o mysql-
client, após qualquer modificação nas suas configurações é necessário
proceder com a sua reinicialização;
Como em ambiente MS Windows, após uma instalação padrão, é criado
um serviço com o nome “MySQL”, basta utilizamos o aplicativo nativo
“services.msc” para darmos um restart no serviço;
Em ambiente Unix Like, um script é disponibilizado automaticamente,
após a instalação, para receber os parâmetros start, stop ou restart:
shell> /etc/init.d/mysql {start | stop | restart}

Ainda no MS Windows, temos muita flexibilidade em ter mais de uma
instância, que no caso poderá ser renomeada em meio ao processo de
instalação;
Para instalar um novo serviço para o MySQL neste mesmo ambiente, basta
posicionar o prompt no diretório “bin”, dentro do BASEDIR do MySQL e criar
um novo serviço com o seguinte comando:
C:...MySQLMySQL Server 5.1.0bin>mysqld.exe --install MySQL_2
Service successfully installed.
Após criado um novo serviço, podemos utilizar o comando net start
<service_name> para iniciar o MySQL:
C:Arquivos de programasMySQLMySQL Server 5.1.0bin>net start MySQL_2
O serviço de MySQL_2 está sendo iniciado.
O serviço de MySQL_2 foi iniciado com êxito.

Para remover um serviço MySQL criado, posicione o seu prompt no
diretório “bin”, localizado dentro do BASEDIR do MySQL e entre com o
seguinte comando:
C:...MySQLMySQL Server 5.1.0bin>mysqld.exe --remove MySQL_2
Service successfully removed.
Pré-requisitos para mais de uma instância em um mesmo host:
– Porta individual;
– BASEDIR e DATADIR individuais;
– Arquivos de logs individuais;

LogsLogs
Storage Engines
INFORMATION_SCHEMA

Logs
O MySQL Server armazena os mais variados tipos de informações em vários
arquivos de logs, dos quais veremos:
– General Query Log;
– Binary Log;
– Slow Query Log;
– Error Log;
– Status File;

General Query Log
O log geral, também chamado de General Query Log, armazena informações
relacionadas com o start e shutdown do servidor de bancos de dados MySQL
e toda consulta SQL enviada e ele;
Consultas que foram executadas com sucesso e também aquelas que não
tiveram sucesso em sua execução serão escritas neste log, que fica localizado
no DATADIR do MySQL;
O conteúdo deste arquivo é escrito pelo SGBD MySQL linha a linha na ordem
em que estes conteúdos vão sendo enviados ao SGBD e podem ser lidos
diretamente, acessando o arquivo;
Para habilitar este log em um servidor de bancos de dados MySQL, inicie o
mysqld standalone ou adicione a opção no arquivo de opção my.ini ou
my.cnf: log [=[path]nome_arquivo]

General Query Log
Conteúdo do log geral do MySQL:
– O DBA deverá ter atenção ao ativar este log pois o servidor de bancos de
dados MySQL poderá perder parte de sua boa performance ao armazenar
todos os comandos SQL recebidos em um arquivo em disco;

General Query Log
No MySQL 5.1, podemos ainda decidir em tempo de execução, habilitar
ou desabilitar o log geral através dos comandos:
SET GLOBAL general_log = ‘ON’;
SET GLOBAL general_log = ‘OFF’;
Utilize o opção general_log_file no arquivo de configuração para
especificar um nome para o log – caso não seja utilizada esta opção, um
arquivo com o nome do host será criado, localizado por padrão dentro do
DATADIR;

General Query Log
O Administrador de Bancos de dados poderá também decidir, no MySQL
5.1, qual será o destino de armazenamento do conteúdo do general_log;
São três as opção:
– FILE: os logs serão armazenados somente em um arquivo de logs em disco;
– TABLE: os logs serão armazenados somente em uma tabela do banco de
dados mysql, denominada general_log;
– NONE: os logs não serão armazenados em nenhum dos possíveis locais;
Uma combinação entre os valores FILE e TABLE será permitida, desde
que se separe os valores com vírgula;

General Query Log
Os possíveis valores para a variável de ambiente log_output:
mysql> SET GLOBAL log_output = 'FILE';
Query OK, 0 rows affected (0.00 sec)
mysql> SET GLOBAL log_output = 'TABLE';
mysql> SET GLOBAL log_output = 'FILE,TABLE';
Considere que haverá uma quantidade enorme de overhead ao decidir
armazenar logs em TABLE ou TABLE,FILE – além dos processos
adicionais que necessitarão utilizar memória;

Binary Log
O log binário é responsável para armazenar os logs de interações com o
servidor que são consultas que modificam o estado de um banco de dados;
Declarações UPDATEUPDATE,, INSERTINSERT e DELETEDELETE são escritas no log binário, mas
SELECTSELECT’s não;
São informações são armazenadas em formato binário. Os comandos são
escritos no log tão logo que são executados. Quando estes fazem parte de
uma transação, eles são escritos logo após receberem um COMMITCOMMIT, ou seja,
são escritos no log como unidades transacionais;
É utilizado para tornar replicação (scale-out) entre servidores uma realidade;
Para habilitar o log binário, adicione ao arquivo de opções, dentro do
agrupamento [mysqld] a opção log-bin [=[path]nome_arquivo]

Binary Log
Em uma instalação padrão, o log binário se encontra no diretório de
dados do servidor de bancos de dados MySQL, o DATADIR;
O path relacionado com a ativação deste log, pode ser alterado,
informando o novo caminho no arquivo de opções:
log-bin=/var/lib/mysql/mysqld-bin
Ao habilitarmos o log binário, outro arquivo, com extensão “.index” será
criado no mesmo diretório. Este arquivo armazena os arquivo utilizados
para armazenar uma lista dos arquivos de log binário utilizados
atualmente no servidor de bancos de dados MySQL;
O conteúdo do arquivo “.index” é texto puro;

Binary Log
Para obter um melhor desempenho do servidor de bancos de dados
MySQL em relação aos logs binários, sempre utilize as opções:
– max_binlog_size: limita o tamanho dos arquivos de log binário e
rotacionando estes ao atingir a tamanho limite. Trabalhar com um maior
número de arquivos menores é bem mais interessante que trabalhar com
pouco arquivos muito grandes;
– max_binlog_cache_size: limita o tamanho do cache em memória
para declarações armazenadas em cache para serem utilizadas por outros
processos do servidor de bancos de dados MySQL;
– expire_logs_days: esta opção configura os arquivos que serão apagados
dos disco por controle automático do MySQL. Arquivos mais antigos que x dias
serão excluídos do disco e da lista do arquivo “.index”;

Binary Log
O mysqlbinlog é o utilitário para leitura do log binário, converção do
seu conteúdo em texto puro. (Bom para point-in-time-recovery);
shell> mysqlbinlog <arquivo_log_binário>
O log binário é uma ótima opção para que o Administrador de Bancos de
Dados trabalhe de forma bem mais segura com backups on-line e point-
in-time recovery, pois, é através dele que conseguimos recuperar o
estado do banco de dados até um dado momento no tempo antes de um
crash;
shell> mysqlbinlog notebook-bin.000001
--start-datetime="2010-06-22 06:00:00"
--stop-datetime="2010-07-01 01:10:13“ > arquivo.sql

Log Slow Queries
O Slow Query Log ou ainda log para consultas lentas, é um log em que o
servidor de bancos de dados MySQL utiliza para escrever as consultas com
tempo maior que o tempo definido em log_query_time;
O MySQL (mysqld) armazena consultas lentas neste log após a sua execução.
O tempo de espera em via de um LOCK TABLESLOCK TABLES explícito não é
contabilizado;
O tempo mínimo que pode ser definido é 1 e o máximo é 10, medidos em
segundos, configurável através da opção long_query_time;
Além de consultas lentas, outras consultas também podem utilizar o Slow
Query Log, que pode ser habilitado, alterando o arquivo de opções,
adicionando ao agrupamento [mysqld]
log-slow-queries [=nome_arquivo]

Log Slow Queries
Podemos adicionar ao my.ini ou my.cnf as seguinte opções para verificar
outros problemas:
– log-queries-not-using-indexeslog-queries-not-using-indexes
Escreve no log de consultas lentas, as consultas que realizam table scan, ou
seja, consultas que não utilizam índices;
– log-slow-admin-statementslog-slow-admin-statements
Escreve no log de consultas lentas, as declarações de cunho administrativo
que apresentam lentidão, como OPTIMIZE TABLEOPTIMIZE TABLE, ANALYZE TABLEANALYZE TABLE e
ALTER TABLEALTER TABLE, sendo o último em alguns casos o mais complicado;

Log Slow Queries
O aplicativo mysqldumpslow é disponibilizado no momento da instalação
do MySQL para facilitar a leitura dos logs de consultas lentas em linha de
comando;
O conteúdo deste log são as consultas com tempo maior que
long_query_time, registrando também data/hora, número da thread
que a executou e o usuário@host, autor da consulta;
Na versão 5.1 do servidor de bancos de dados MySQL, houveram mudanças
quanto ao nome e a maneira de se habilitar este log. Na versão 5.0, a variável
que habilita este log é chamada log_slow_queries enquanto que na versão 5.1
este foi rebatizado com o nome de slow_query_log, ganhando outras variáveis
para habilitá-lo em tempo de execução ou ainda decidir sobre o seu destino de
armazenamento.
Na versão 5.1 do servidor de bancos de dados MySQL, houveram mudanças
quanto ao nome e a maneira de se habilitar este log. Na versão 5.0, a variável
que habilita este log é chamada log_slow_queries enquanto que na versão 5.1
este foi rebatizado com o nome de slow_query_log, ganhando outras variáveis
para habilitá-lo em tempo de execução ou ainda decidir sobre o seu destino de
armazenamento.

Log Slow Queries
Para habilitar os logs via arquivo de configuração, sendo este my.ini (MS
Windows) ou my.cnf (Unix Like), precisamos localizar o agrupamento
[mysqld] e adicionar as seguintes opções:
[mysqld]
# slow log options and configurations
slow_queries_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 5.800000 # microsegundos
Caso esta opção não seja configurada no arquivo de configurações do
MySQL, ao habilitar este log em tempo de execução, o servidor de bancos
de dados iniciará o armazenamento dos logs em log_output – sendo
log_output = FILE, um arquivo será criado em um diretório
conhecido pelo MySQL como DATADIR;
Configurei o novo path para
o arquivo, reiniciei o
servidor e o arquivo não
apareceu no diretório!!!!!
Configurei o novo path para
o arquivo, reiniciei o
servidor e o arquivo não
apareceu no diretório!!!!!

Log Slow Queries
Com relação ao novo formato praticado pelo MySQL 5.1, podemos deixar
o log de consultas lentas habilitado no arquivo de configuração do MySQL,
com a opção log_slow_queries = 1 e habilitá-lo ou não em tempo de
execução:
mysql> SET GLOBAL slow_query_log = 1;
mysql> SHOW VARIABLES LIKE 'log_slow%';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| log_slow_queries | ON |
+------------------+-------+
1 row in set (0.00 sec)

Log Slow Queries
O Administrador de Bancos de dados poderá também decidir, no MySQL
5.1, qual será o destino de armazenamento das consultas mais lentas que
long_query_time;
São três as opção:
– FILE: os logs serão armazenados somente em um arquivo de logs em disco;
– TABLE: os logs serão armazenados somente em uma tabela do banco de
dados mysql, denominada slow_log;
– NONE: os logs não serão armazenados em nenhum dos possíveis locais;
Uma combinação entre os valores FILE e TABLE será permitida, desde
que se separe os valores com vírgula;

Log Slow Queries
Os possíveis valores para a variável de ambiente log_output:
mysql> SET GLOBAL log_output = 'FILE';
mysql> SET GLOBAL log_output = 'TABLE';
mysql> SET GLOBAL log_output = 'FILE,TABLE';
Considere que haverá uma quantidade enorme de overhead ao decidir
armazenar logs em TABLE ou TABLE,FILE – além dos processos
adicionais que necessitarão utilizar memória;

Log de Erro
O log de erros, chamado de Error Log, também está localizado no diretório de dados do
servidor de bancos de dados MySQL;
O log de erros é um arquivo com extensão “.err” e contém informações que indicam
quando o servidor de bancos de dados MySQL, o mysqld, foi iniciado e foi parado e
alguns outros erros críticos de quando o servidor estava rodando;
Erros de inicialização de Storage Engines, problemas com relicação e outros problemas
que afetam o funcionamnto são facilmente encontrados no log de erro;
Podemos habilitar o log de erros, adicionando ao arquivo de opções, dentro do
agrupamento [mysqld], a seguinte linha:
log-error [=[path]nome_arquivo]

Log de Erro
Podemos ainda incluir no log todos os WARNINGS enviados pelo SGBD
MySQL, adicionando ao arquivo de opções a seguinte linha:
log-warnings
– WARNINGS podem ser exibidos com o comando SHOW WARNINGS em tempo
de execução , acessando o mysqld com o mysql client ainda com qualquer outra
interface gráfica que permite o acesso ao MySQL;
– WARNINGS podem acontecer por vários motivos;
– Interessante para auditar o que está saindo errado com os aplicativos que utilizam
os bancos de dados do servidor MySQL;

Log de Erro
Uma situação cotidiana para o Administrador de Bancos que lida com o
servidor de bancos de dados MySQL é a de trabalhar alguns opções no
arquivo de configuração e ao subir o processo/serviço, ele reporta erro.
Estes erros podem ser visualizados abrindo o arquivo de lo de erro do
MySQL, que armazena tais mensagens em texto puro;
Um outra alternativa e bastante interessante até pela sua agilidade é a
possibilidade de iniciar o MySQL em linha de comando em modo
standalone com a opção --console;
Com esta opção, os logs que normalmente seriam enviados para um
arquivo em disco, agora serão enviados para o terminal;

Log de Erro
Exemplo:
shell> mysqld --console
100618 14:48:35 InnoDB: Started; log sequence number 0 47727
100618 14:48:35 [Note] Event Scheduler: Loaded 0 events
100618 14:48:35 [Note] mysqld: ready for connections.
Version: '5.1.44-community' socket: '' port: 3306 MySQL Community Server (GPL)
Os erros decorrentes da inicialização do MySQL são apontados no próprio
terminal ou prompt, que também pode ser chamado de saída padrão;
Assim, fica bem mais ágil resolver os problemas de não start do
processo/serviço do MySQL em Linux e MS Windows, respectivamente;

Log de Erro
Como atualmente o MySQL tem muita penetração em vários tipos de
mercado no mundo inteiro para os mais variados tipos de aplicação,
vários membros da comunidade de usuários tem fomentado projetos
muito interessantes;
Para melhor visualização do log de erros, podemos utilizar uma
ferramenta que é disponibilizada gratuitamente pela Percona, chamada
mk-error-log, que compõe o pacote de scripts do MaatKit
(www.maatkit.org);
– Além do supracitado script, este pacote possui muitas outras ferramentas
bastante interessantes para administração do ambiente – todos em linha de
comando. (Documentation www.maatkit.org/doc/)

Log de Erro
MaatKit mk-error-log Analyzer:
shell> /usr/bin/mk-error-log /var/lib/mysql/mysqld.err
Count Level Message
===== ======= ==================================================
5 info mysqld started
4 info mysqld version info
3 info InnoDB: Started
2 info mysqld ended
1 unknown Number of processes running now: 0
1 error [ERROR] /usr/sbin/mysqld: unknown variable 'ssl-ke
1 error [ERROR] Failed to initialize the master info struc

Status File
O servidor de bancos de dados MySQL cria muitos status de seu
funcionamento em conjunto com o sistema operacional, localizado no
diretório de dados, DATADIR;
Tal arquivo tem extensão “.pid”, sendo que, para habilitar a criação destes
arquivos que são utilizados também por outros aplicativos, adicione ao
arquivos de opções, dentro do agrupamento [mysqld], a seguinte linha:
pid-file [=[path]arquivo_nome]
Sem a criação deste arquivo pelo MySQL, ele não subirá o
processo/serviço;

Logs
Arquivo de ConfiguraçãoArquivo de Configuração
Storage Engines
INFORMATION_SCHEMA

O arquivo de configuração do MySQL, também conhecido como arquivo
de opções, é um arquivo de grande importância para o comportamento
do servidor de bancos de dados Open Source mais utilizado do mundo;
Sua função é a de justamente parametrizar as principais áreas as quais o
MySQL utiliza para manipular os dados durante o seu funcionamento –
isso inclui backup, portas, DATADIR, BASEDIR, criação de buffers e caches,
criação de tabelas temporárias, diretório temporário e muitos outros
pontos;
O conteúdo deste arquivo é de texto puro, sendo ele editado através de
um editor de textos como o bloco de notas ou ainda o vi/vim;

As localizações dos arquivo de configuração entre os sistemas
operacionais MS Windows e Linux diferem quanto aos seus padrões;
No Windows, o arquivo será procurado primeiramente no diretório de
instalação do sistema operacional (C:WINDOWS) e o arquivo procurado
será o my.ini e depois o my.cnf, nesta ordem;
No Linux ou sistemas Unix Like, o arquivo de configuração será procurado
em /etc ou /etc/mysql – não é necessário que o arquivo tenha a
extensão “.cnf” – podemos criar um arquivo sem extensão, por exemplo;
O arquivo de configuração deverá contar pelo menos com os
agrupamentos [client] e [mysqld] – clientes e servidor,
respectivamente;

Todas as vezes que algum valor de alguma opção for alterada no arquivo
de configurações, será necessário reiniciar o MySQL para que as novas
configurações passem a valer;
– [client]: controla opções necessárias para que os clientes ao se conectar,
encontrem o servidor;
– [mysqld]: controla opções de comportamento do servidor, opções de storage
engines, diretório temporário, porta e vários outros;
– [mysqldump]: controla opção relacionadas com o running do mysqldump;
– [mysql_cluster]: controla as opções de configuração do MySQL Cluster;

Arquivo de Configurações
Exemplo:
[client]
port = 3306 # Client port’s conn
socket = /var/lib/mysql/mysqld.sock # socket file
[mysqld]
user = mysql # User that will start mysqld
port = 3306 # Server’s port listen
socket = /var/lib/mysql/mysqld.sock # socket file
pid-file = /var/lib/mysql/mysqld.pid # PID file
basedir = /usr # BASEDIR
datadir = /var/lib/mysql # DATADIR

O arquivo de configuração é alvo de toda e qualquer modificação
relacionada com a aplicaçao de métricas de tuning baseadas no engine
que controla as tabelas de um banco de dados;
Cada engine tem suas próprias opções, por exemplo:
[mysqld]
# InnoDB Tuning Configuration
innodb_buffer_pool_size = 2048M
innodb_log_buffer_size = 128M
innodb_thread_concurrency = 0
innodb_flush_method = O_DIRECT
innodb_concurrency_tickets = 800
innodb_autoinc_lock_mode = 1

Através do arquivo de configuração, podemos também controlados as
variáveis ou opções conhecidas como Per-Client Variables, que tem a
finalidade de controlar a quantidade de caches e buffers que serão
concedidas a cada thread:
[mysql]
# Per-client variables
max_allowed_packet = 128M # max size of required data pack
read_buffer_size = 16M # sequential buffer needs
read_rnd_buffer_size = 32M # aux MyISAM to retrieve data
sort_buffer_size = 16M # ORDER BY, GROUP BY … buffer
join_buffer_size = 16M # Used by joins with no index
net_buffer_length = 1M # Initial thread result buffer
thread_stack = 192K # Used to put objects in pile

Os valores de variáveis que são informadas em KB, MB, GB e TB, quando
configuradas no arquivo de opções, consideram somente a primeira letra,
conforme a tabela a seguir:
Unidade my.ini/my.cnf
KB K
MB M
GB G
TB T

Logs
Storage EnginesStorage Engines
INFORMATION_SCHEMA

Storage Engines
O MySQL permite a você escolher um entre vários Storage Engines
quando inicia a criação de tabelas em seu banco de dados;
Os Storage Engines, chamados antes de Table Types (deprecated),
também é conhecido como motor de armazenamento ou ainda
engenharia de armazenamento, ao pé da letra;
Cada Storage Engine tem suas respectivas características, desde um
engine bastante veloz e enxuto, no caso do MyISAM (padrão) até um
engine mais robusto que é o InnoDB;

Storage Engines
O MySQL, por via de sua arquitetura, é tipo como um Plugable Database,
pois, vários ativistas da comunidade do MySQL desenvolvem seus
próprios engines com características de outros SGBD’s, plugam no MySQL
e trabalham com aquelas características dentro de seu projetos ;
Cada engine tem suas próprias características que dão muita flexibilidade
na utilização do MySQL;

Storage Engines
Podemos checar quais são os Storage Engines habilitados em nossa
instalação de MySQL atual, através do comando:
mysql> SHOW ENGINES;SHOW ENGINES;
Este comando exibirá uma lista de engines que são conhecidos por
engines default, ou seja, aqueles que já são habilitados por padrão;

Storage Engines
Podemos perceber que há muitas opções de Storage Engines para se
utilizar, cada com a sua característica diferente, sendo que, são eles
transacionais ou não-transacionais;
Atentando-se à figura anterior, percebemos que o Storage Engine padrão
do MySQL é o MyISAM, mas isso poderá ser modificado facilmente
através da linha de comando – alterando o engine padrão somente para
sua sessão (SET SESSION) - ou de forma global, através do arquivo de
opções my.ini ou my.cnf, adicionando a seguinte linha ao agrupamento
[mysqld]:
[mysqld]
default-storage-engine=meu_storage_preferido

MyISAM
MyISAMMyISAM é o Storage Engine padrão do MySQL, baseado no código do antigo
Engine chamado ISAM - já obsoleto na versão 5.0 - só que com muito mais
funcionalidades (chamadas de extensões);
Quando criamos uma tabela MyISAM, são adicionados três tipos de arquivos
dentro do diretório do banco de dados contido dentro do diretório chamado
de DATADIR ou diretório de dados:
– Um arquivo “.MYD”: é o arquivo de dados da tabela;
– Um arquivo “.MYI”: é o arquivo de índices da tabela;
– Um arquivo “.frm”: é o arquivo que contém o “CREATE TABLECREATE TABLE”;
Normalmente, este três arquivos são armazenados em um mesmo local,
dentro do diretório do banco de dados, sob o diretório de dados do MySQL.
Em sistemas que suportam links simbólicos (symlinks), podemos armazenar
tais arquivos em outros locais;

MyISAM
MyISAM tem o controle mais flexível de colunas auto_increment em relação a
outros engines, uma vez que os identificadores são armazenados na própria
tabela e recuperados toda vez que uma nova linha é inserida;
Muito rápido para leitura e bastante lento para ambientes com muitas
escritas ou concorrência por recursos;
Não tem suporte a transações e nem a integridade referencial;
Tem bloqueio em nível de tabelanível de tabela, ou seja, cada comando, seja ele INSERTINSERT,
DELETEDELETE ou UPDATEUPDATE irá adquirir bloqueio de toda a tabela;
Deadlocks não ocorrem!Deadlocks não ocorrem!

MyISAM – Row Format
Suportam FULL-TEXTFULL-TEXT searching e Tipos de Dados Espaciais para
aplicações de Geoprocessamento;
Tabelas MyISAM tem formatos de linha particulares, podendo ser:
– Fixed-Row Format:Fixed-Row Format: todas as linhas deste tipo de tabela MyISAM tem o mesmo
tamanho (fácil de recuperar mas necessitam de mais espaço);
– Dynamic-Row Format:Dynamic-Row Format: o tamanho das linhas varia e não são eficientemente
recuperadas. Fragmentações ocorrem com maior facilidade e consomem
menos espaço;
– Compressed Format:Compressed Format: tais tabelas são comprimidas para liberar espaços,
otimizadas para leitura e são read-only.

MyISAM – Row Format
Para checarmos se uma tabela contralada pelo Storage Engine MyISAM
tem linhas fixas ou dinâmicas, podemos utilizar o comando SHOW TABLE
STATUS:
mysql> CREATE TABLE test.tab_myisam(id int, name char(60)) ENGINE = MyISAM;
mysql> SHOW TABLE STATUS FROM test LIKE 'tab_myisam'G
Tabelas MyISAM com tipos de dados CHAR() terão sempre suas linhas
com tamanho fixo, enquanto que, mesmo que que tenha uma só coluna
com tipos de dados VARCHAR() já terá suas linhas em formato dinâmico;
É a velha discussão entre ter mais velocidade ou gastar menos espaço!

MyISAM – Crash-Recovery
MyISAM apresenta graves problemas de crash em tabelas. Sistemas que
trabalham em locais com problemas de queda de energia podem ter problemas
com tabelas MyISAM, que são mais sensíveis que todas as outras por ter estrutura
mais enxuta;
No Linux, podemos facilmente simular o problema através do seguinte comando:
shell> kill -9 `pgrep mysqld`
Quando o banco retorna às operações, o mecanismo de crash-recoverycrash-recovery do
MyISAM não consegue se recuperar;
Caso você tenha um ambiente com poucas escritas e mais leituras que necessite
de boa performance na resposta, considere utilizar o mais novo Engine chamado
MARIAMARIA. O teste do MARIAMARIA pode ser visto em:
– http://imasters.uol.com.br/artigo/7913/mysql/maria_o_novo_storage_engine_do_mysql/

MyISAM – Key Cache Strategies
O MyISAM, assim como vários outros produtos servidores de bancos de
dados que estão no mercado, utiliza a estratégia de inserção em cache
dos blocos de dados mais utilizados;
Este mecanismo utiliza o LRU (Least Recently Used) como algorítimo para
efetuar as trocas dos blocos de dados menos utilizados por aqueles que
são mais utilizados;
Uma estrutura interna é mantida pelo MyISAM, denominada key_buffer
que adiciona os objetos mais utilizados em um buffer especial,
possibilitando melhores respostas segundo estatísticas internas;

Administradores de Bancos de Dados ao optar por utilizar tabelas
controlados pelo engine MyISAM, poderão facilmente ler os índices de
tabelas em tempo de execução para agilizar a leitura de determinados
dados;
Podemos criar key_buffers especialistas para armazenar os índices que
nos interessam naquele momento, ou mesmo por via de um grande
acesso a uma tabela devido a uma atividade sazonal;
Ao criar um novo key_buffer, informamos qual é o tamanho deste buffer,
nomeamos o mesmo e carregamos os dados do índice para dentro deste
novo key_buffer – adicional àquele que já existe globalmente;

O primeiro ponto é verificar o tamanho dos índices da tabela que
queremos carregar no em um key_buffer especialista:
mysql> SELECT TABLE_NAME,
-> CONCAT(SUM(INDEX_LENGTH/1024/1024),‘ MB') AS "INDEX SIZE(MB)"
-> FROM INFORMATION_SCHEMA.TABLES
-> WHERE TABLE_SCHEMA = 'test' AND TABLE_NAME = 'tab_myisam'
-> GROUP BY TABLE_NAME
-> ORDER BY TABLE_NAME;
+------------+----------------+
| TABLE_NAME | INDEX SIZE(MB) |
+------------+----------------+
| tab_myisam | 0.01171875 MB |
+------------+----------------+

Tendo a noção do espaço necessário para alocação do índice em cache,
podemos proceder com a criação do key_buffer especialista que seria
conforme o seguinte:
mysql> SET GLOBAL key_tab_myisam.key_buffer_size = 1*1024*1024;
Carregamos os índices no cache que acabamos de criar:
mysql> CACHE INDEX tab_myisam IN key_tab_myisam;
+-----------------+--------------------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+-----------------+--------------------+----------+----------+
| test.tab_myisam | assign_to_keycache | status | OK |
+-----------------+--------------------+----------+----------+

O comando CACHE INDEX ainda nos possibilita dizer qual o índice a ser
carregado na memória através do seu nome – para checar o nome do
índice, utilize a coluna Key_name do resultado do comando SHOW INDEX
FROM <table>;
mysql> SHOW INDEX FROM tab_myisam;
+------------+------------+----------+--------------+
| Table | Non_unique | Key_name | Seq_in_index |
+------------+------------+----------+--------------+
| tab_myisam | 0 | PRIMARY | 1 |
+------------+------------+----------+--------------+
O resultado acima foi suprimido para ser melhor encaixado nesta
apresentação;

Após recuperarmos o nome do índice que nos interessa colocar em
memória cache, podemos utilizar a seguinte sintaxe no comando CACHE
INDEX:
mysql> CACHE INDEX tab_myisam INDEX(PRIMARY) IN key_tab_myisam;
+-----------------+--------------------+----------+----------+
+-----------------+--------------------+----------+----------+
| test.tab_myisam | assign_to_keycache | status | OK |
+-----------------+--------------------+----------+----------+
Para mais de uma tabela e mais de um índice, separe os objetos por
vírgula, mantendo-os nas devidas posições dentro do comando;

Por fim, carregamos o key_buffer criado, juntamente com os dados dos
índices da tabela tab_myisam no espaço de memória física do host:
mysql> LOAD INDEX INTO CACHE tab_myisam;
+-----------------+--------------+----------+----------+
+-----------------+--------------+----------+----------+
| test.tab_myisam | preload_keys | status | OK |
+-----------------+--------------+----------+----------+
A cláusula IGNORE LEAVES faz com que somente os dados do nível não
folha (root) sejam carregados para o cache;

Após recuperarmos o nome do índice que nos interessa colocar em
memória cache, podemos utilizar a seguinte sintaxe no comando LOAD
INDEX INTO CACHE:
mysql> LOAD INDEX INTO CACHE tab_myisam INDEX (PRIMARY);
+-----------------+--------------+----------+----------+
+-----------------+--------------+----------+----------+
| test.tab_myisam | preload_keys | status | OK |
+-----------------+--------------+----------+----------+
Para mais de uma tabela e mais de um índice, separe os objetos por
vírgula, mantendo-os nas suas devidas posições dentro do comando;

MyISAM – Specific Options
Todos os engines têm suas próprias opções que podem ser adicionadas ao
agrupamento [mysqld] do arquivo de configuração do servidor de bancos
de dados MySQL;
O MyISAM possui muitas delas que são específicas do engine e outras que
controlam o seu comportamento e também são utilizadas e/ou
compartilhadas por outros motores;
O mais interessante é ter ciência que, cada engine terá sempre os seus
próprios parâmetros para controle de seu comportamento – o importante
é ter a exata ciência do perfil do banco de dados a ser tunado ou
reconfigurado para influenciar as métricas;

MyISAM – Specific Options
Opções específicas e que afetam o comportamento da manipulação de dados
em tabelas MyISAM:
[mysqld]
# Specific MyISAM Options
key_buffer_size = 256M # Stores indexes blocks
key_cache_age_threshold = 300 # Key Cache algorithm
key_cache_block_size = 1024 # Key Cache algorithm
key_cache_division_limit = 100 # Key Cache algorithm
bulk_insert_buffer_size = 128M # Buffer to data bulk inserts
preload_buffer_size = 32K # Preload initial buffer
concurrent_insert = 2 # Selects + Inserts “simults”
delay_key_write = on # Flush delay of index changes
tmp_table_size = 64M # Size of temp tables – Pss!!!

InnoDB
O InnoDB é o Storage Engine, de longe, o mais utilizado no mundo por suas
características e suporte a vários features importantes;
Ao criar uma tabela controlado pelo Storage Engine INNODB, um arquivo “.frm” é
criado no diretório do banco de dados, sob o diretório de dados do MySQL (DATADIR);
Índices e dados são armazenados dentro de um Tablespace, localizado no DATADIR de
ambos os sistemas operacionais – MS e Ux -, com o nome de ibdata1, onde são
armazenados também os segmentos de undo e de redo;
InnoDB da suporte à transações, 100% ao modelo ACID (atomicidade, concorrência,
isolamento e durabilidade), provê auto_recovery muito eficiente, com 6 níveis e
multiversionamento de dados para “leitura consistente” - MVCC;
Tem também, suporte a integridade referencial com Primary Keys e Foreign Keys;

InnoDB
Em 2005, a ORACLE anunciou a compra da empresa finlandesa INNOBase OY,
que desenvolveu o INNODB e continuo a distribuí-lo sob os termos da GNU
GPL (General Public License). O software é embutido ao MySQL através de um
acordo contratual perpétuo;
Após instalar o MySQL e sabendo que o InnoDB não será utilizado,
interessante desabilitá-lo para que não haja desperdício de memória e isto
poderá ser efetuado através do arquivo de opções, my.ini ou my.cnf;
[mysqld]
skip-innodb
Após adicionar a opção supracitada no arquivo de configuração, reinicie o
MySQL e faça a recuperação dos engines disponíveis atualmente no MySQL;

InnoDB - Architecture
A arquitetura do InnoDB se apresenta desta forma, segundo os seus
componentes de controle de manipulação de dados:

InnoDB
O INODB possui uma série de logs que são armazenados em arquivos
chamados ib_logfilex. Tais logs, em uma instalação padrão, ficam
armazenados no mesmo diretório aonde está localizado o Tbalespace;
O tablespace do InnoDB é um arquivo compartilhado, ou seja, armazena
dados e índices de todas as tabelas InnoDB que existirem no servidor MySQL
(esse tablespace é referenciado como sendo uma single storage area). Não
existe um arquivo específico para índices e outro para dados, assim como
acontece com o MyISAM;
Podemos ter ainda, um tablespace para cada tabela, adicionando a opção
abaixo no arquivo de opções, my.ini ou my.cnf:
[mysqld]
innodb_file_per_table

InnoDB - Arquivos
Quando adicionada a opção citada ao arquivo de opções, devemos reiniciar o
MySQL para que, quando o SGBD iniciar o módulo InnoDB e ler as opções setadas
no arquivo de opções, ele crie um tablespace para cada tabela;
Notaremos que agora teremos dois arquivos no diretório do banco de dados sob o
diretório de dados do MySQL (DATADIR):
– Um arquivo “.frm”: normalmente criado para cada tabela controlado pelo
Storage Engine INNODB;
– Um arquivo “.ibd”: arquivo que é o Tablespace individual, criado a partir das
novas configurações do arquivo de opções;

InnoDB - Arquivos
Além do tablespace compartilhado, o InnoDB possibilita que o
administrador de bancos de dados tenha por padrão de instalação dois
arquivos de transaction log;
Para controlar os logs que o InnoDB utiliza para transações, temos
disponíveis as seguintes opções:
[mysqld]
innodb_buffer_log_size = 8M # Size of the log in RAM
innodb_log_file_size = 32M # Size of the file on disk
innodb_log_files_in_group = 5 # Amount of files – 0 to 4
innodb_log_group_home_dir = /path # Location of log files

InnoDB – Controle de Memória
O InnoDB trabalha intensamente com a memória, trabalhando com um
mecanismo interno chamado de “buffer pool” para colocar a quantidade
possível de dados em memória;
O grande segredo de trabalhar bem com o InnoDB e fazer com que ele
tenha quase a mesma performance do MyISAM é saber trabalhar
questões relacionadas com memória e seu principal parâmetro o
innodb_buffer_pool_size;
Em um ambiente 64bits, este parâmetro poderá alocar mais que 4GB e
em versões mais atuais do InnoDB – InnoDB Plugin – conseguirá alocar
mais de 16 cores do processador do servidor físico;

InnoDB – Controle de Memória
Os parâmetros do InnoDB para controle de memória são muitos, mas os
principais são aqueles que estão na lista abaixo:
[mysqld]
# InnoDB Basic Memory Configuration
innodb_buffer_pool_size = 1024M
innodb_thread_concurrency = 0
innodb_commit_concurrency = 0
innodb_additional_mem_poo_size = 8M
innodb_concurrency_tickets = 500
innodb_max_dirty_pages_pct = 0
innodb_flush_method = O_DIRECT
innodb_table_locks = 1

InnoDB – Integridade Referêncial
Muito cuidado ao configurar o InnoDB para atuar com várias tablespaces. O
tablespace principal continua sendo utilizado para armazenar o dicionário de
dados e o segmento de rollback;
Com o InnoDB, podemos desenvolver os relacionamentos entre as tabelas de
nosso banco de dados, utilizando chaves primárias – PRIMARY KEYPRIMARY KEY – e
chaves estrangeiras – FOREIGN KEYFOREIGN KEY;
Para atribuir uma constraint ou restrição de relacionamento para garantir a
integridade referencial temos que saber o que é a integridade referencial e ter
ciência dos requisitos para firmar o relacionamento entre as tabelas;
As chaves estrangeiras suportadas pelo Storage Engine InnoDB tem suas
respectivas propriedades de CASCADECASCADE, NO ACTIONNO ACTION, SET NULL e SETSET
DEFAULTDEFAULT;

Para criar FOREIGN KEYSFOREIGN KEYS, temos que nos atentar para as seguintes regras:
– As colunas envolvidas no relacionamento devem ser indexadas. Caso um
índice não seja criado explicitamente para a FOREIGN KEY, o MySQL criará
um automaticamente;
– As colunas envolvidas no relacionamento devem ter o mesmo tipo de dados
numérico;
– As colunas devem utilizar ou não a propriedade UNSIGNED;
Podemos atribuir os relacionamento na criação das tabelas ou ainda com
a declaração ALTER TABLEALTER TABLE;
Veremos a seguir as duas formas;

Declarando a FOREIGN KEYFOREIGN KEY na criação da tabela filha:
mysql> create table tbl_pai (
-> id int not null primary key
-> ) engine=innodb;
mysql> create table tbl_filha (
-> id_pai int not null primary key,
-> constraint foreign key (id_pai)
-> references tbl_pai(id)
-> ) engine=innodb;

Declarando a FOREIGN KEYFOREIGN KEY com ALTER TABLEALTER TABLE:
-> ) engine=innodb;
-> id_pai int not null primary key
-> ) engine=innodb;
mysql> alter table tbl_filha add constraint FK_NAME
-> foreign key (id_pai)references tbl_pai (id);
Records: 0 Duplicates: 0 Warnings: 0

Poderíamos ter utilizado as propriedades ON DELETEON DELETE e ON UPDATEON UPDATE,
como fazemos logo abaixo, com CASCADECASCADE:
-> ) engine=innodb;
-> id_pai int not null primary key
-> ) engine=innodb;
mysql> alter table tbl_filha add constraint FK_NAME
-> foreign key (id_pai) references tbl_pai (id)
-> on delete cascade on update cascade;
Records: 0 Duplicates: 0 Warnings: 0

Colocando a propriedade CASCADECASCADE na atribuição de uma constraint
FOREIGN KEYFOREIGN KEY, ao excluir o registro PAI, todos os registros na tabela filha
que tenham o mesmo identificador da chave primária da tabela PAI, serão
excluídos;
Colocado a propriedade NO ACTIONNO ACTION na atribuição de uma constraint
FOREIGN KEYFOREIGN KEY, ao tentar excluir o registro PAI, este não será exlcuído por
causa da amarração deste registro na tabela filha;
Colocado a propriedade SET NULLSET NULL na atribuição de uma constraint
FOREIGN KEYFOREIGN KEY, ao excluir o registro PAI, aonde existir o identificador do PAI
– PRIMARY KEYPRIMARY KEY – no filho, seu valor será setado para NULLNULL. Logicamente, a
coluna da FOREIGN KEYFOREIGN KEY não poderá receber um valor NULLNULL se ela foi
declarada como NOT NULLNOT NULL;

InnoDB – Plugin
O InnoDB Plugin é um modulo externo que pode ser adicionado ao MySQL
de forma dinâmica, sendo esta uma versão muito mais poderosa do
storage engine transacional mais utilizado no MySQL;
O InnoDB plugin é disponibilizado pela empresa InnoBASE, antiga
InnoBASE OY, que desde 2005 foi obtida pela Oracle. Desde então, o
interesse em fomentar o MySQL como Plugable Database aumentou e
tomou outras proporções;
Esta versão do InnoDB está na versão 1.0.7 GA e pode ser utilizada com o
MySQL na versão 5.1.46 em diante – necessita um grande workaround
para habilitá-lo, mas “os fins justificam os meios”;

InnoDB – Plugin
O que mais chamou a ateção no InnoDB Plugin, é que o novo formato de
arquivo denominado “Barracuda”, deu ao MySQL a possibilidade de
trabalhar com alta compressão de dados e aumento na sua performance
em mais de 200%;
Várias modificações são esperadas para a nova versão do MySQL, a 5.5,
que será a primeira versão do MySQL Oracle, já com o InnoDB como
Storage Engine default, substituindo o MyISAM;

InnoDB – Plugin Performance
Utilização ou escala de mais de 16 cores para leitura e escrita:

Várias instâncias de innodb_buffer_pool

Performance de leitura e escrita na utilização de tabelas particionadas
com o partitioning engine controladas pelo InnoDB Plugin;

Mutexes:

Archive
O Archive é um Storage Engine que provê eficiente forma para armazenar grandes
quantidade de dados quando não é necessário se ter índices e se precisa liberar
espaço em disco;
Esse Engine só suporta declarações SELECTSELECT e INSERTINSERT;
Toda tabela Archive é, após ser criada, cria no diretório do banco de dados a que
pertence, sob o diretório de dados, um arquivo “.frm”, que é o arquivo que
contém o CREATE TABLECREATE TABLE, os seguintes arquivos:
– Um arquivo “.ARZ”: esse é o arquivo que contém os dados – datafile;
– Um arquivo “.ARM”: esse arquivo armazena metadados da tabela;
– Um arquivo “.frm”: que contém o CREATE TABLECREATE TABLE;
O Archive vem habilitado a partir da versão MySQL 5.0 max beta;

Archive
É uma ótima opção para se formar os históricos ou mesmo armazenar parte
dos dados de uma outra grande tabela para aliviar otimizar consultas;
Economizar espaços, mas com algumas limitações e com muita segurança,
essa é a principal característica de uma tabela que é controlada pelo Storage
Engine Archive;
Para fazer um teste e já demonstrar como criar tabelas controladas pelo
Storage Engine Archive, vamos criar 3 tabelas com o mesmo números de
linhas, sendo que uma primeira será uma tabela controlada pelo Storage
Engine MyISAM, a segunda utilizaremos o tipo INNODB e ao final, criaremos
uma tabela controlada pelo Engine Archive;
Ao final, veja o quanto os dados foram comprimidos;

Archive
Tabela 1:Tabela 1:
mysql> create table tb_myisam engine=myisam asmysql> create table tb_myisam engine=myisam as
-> select * from mysql.user;-> select * from mysql.user;
Query OK, 112050 rows affected (0.00 sec)Query OK, 112050 rows affected (0.00 sec)
Records: 112050 Duplicates: 0 Warnings: 0Records: 112050 Duplicates: 0 Warnings: 0
Tabela 2:Tabela 2:
mysql> create table tb_innodb engine=innodb asmysql> create table tb_innodb engine=innodb as
Tabela 3:Tabela 3:
mysql> create table tb_archive engine=archive asmysql> create table tb_archive engine=archive as

Archive
Ao consultar o tamanho dos dados registrados em bytes na coluna
DATA_LENGTH da tabela TABLES do dicionário de dados, vemos:

Memory
Memory Storage Engine controla tabelas previamente criadas, mantendo seus
dados em memória. Antes tinham o nome de HEAP;
Toda tabela controlada pelo Storage Engine MySQL está associada a um
arquivo de extensão “.frm”, que é criado no diretório do banco de dados a
que ela pertence, sob o diretório de dados do MySQL;
Para criar uma tabela controlada por este Storage Engine, basta utilizar a
declaração Engine, como segue:
CREATE TABLE test_table(id int, name CHAR(60))Engine=MEMORY;Engine=MEMORY;
Tem ótima performance mas o conteúdo das tabelas Memory não são
mantidos quando o servidor é reiniciado;

Memory
Após reiniciar o servidor, somente a estrutura da tabela permancerá no
banco de dados, sendo os dados desconsiderados por estarem em
memória;
Além de índices BTREE INDEXBTREE INDEX, tabelas controladas pelo Storage Engine
Memory também podem ter HASH INDEXHASH INDEX, que são índices baseados em
endereços hash de memória: fx00a26a4d7c2cee8e1af1958caf8365dda4
HASH INDEXHASH INDEX são muito velozes para comparações com os operadores =
e <=>, enquanto que BTREE INDEXBTREE INDEX são mais usuários e trabalham bem
com qualquer tipo de comparação, por exemplo com o uso de BETWEENBETWEEN;

Federated
O Storage Engine Federated está disponível no MySQL desde a versão
5.0.3;
A principal função deste Storage Engine é acessar dados em tabelas de
outros servidores MySQL remotos, sem a utilização de replicação ou
mesmo qualquer tecnologia de cluster;
Quando utilizamos uma tabela controlada pelo Storage Engine Federated
em um servidor de bancos de dados MySQL local, as consultas a este
banco buscam dados do servidor remoto. Tabelas locais não armazenam
dados;
Caso você resolva instalar o MySQL a partir do source (código fonte),
inclua a opção --with-federated-storage-engine;

Federated
Quando criamos uma tabela controlado pelo Storage Engine Federated, é
criado um único arquivo, de extensão “.frm” no diretório do banco de dados,
sob o diretório de dados do MySQL (DATADIR);
Ao selecionarmos dados de uma tabela do tipo Federated, uma conexão com
um servidor remoto é feita e então os dados remotos são retornados. A
conexão é realizada utilizando a MySQL client APIMySQL client API;
Primeiro, decidimos qual é a tabela do servidor remoto que queremos criar
uma tabela “atalho” no servidor local. Essa tabela remota pode ser do tipo
MyISAM, INNODB ou controlada por qualquer outro Storage Engine;
Após definir a tabela remota e os dados, a tabela controlada pelo Storage
Engine Federated e criada no servidor local;

Federated
Tabela remota:
CREATE TABLE test_table (
id INT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(32) NOT NULL DEFAULT '',
other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id), INDEX name (name),
INDEX other_key (other) )
ENGINE=MyISAM
DEFAULT CHARSET=latin1;

Federated
Tabela local:
CREATE TABLE federated_table (
id INT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(32) NOT NULL DEFAULT '',
other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id), INDEX name (name),
INDEX other_key (other) )
ENGINE=FEDERATED DEFAULT CHARSET=latin1
CONNECTION='mysql://fed_user@remote_host:9306/
federated/test_table';

Federated
Antes da versão 5.0.13, a declaração COMMENTCOMMENT era utilizada no lugar de
CONNECTION.CONNECTION. A formula geral da string de conexão abordada na
declaração CONNECTIONCONNECTION ou COMMENTCOMMENT ao final da tabela é a seguinte:
Esse Storage Engine plenitude no caminho do que é chamado de alta-
disponibilidade em bancos de dados, pois, com ele, você poderá
facilmente obter dados remotos em conjunção com os dados locais;
Uma tabela do tipo Federated não precisa conter exatamente as mesmas
colunas da tabela remota;

Federated
Tabelas controladas pelo Storage Engine Federated não suportam
transações;
Suportam SELECTSELECT, INSERTINSERT, DELETEDELETE e UPDATEUPDATE;
Não são utilizados nenhum tipo de bloqueio em tabelas controladas por
este Storage Engine;
Não suportam a criação de índices;

Problemas em tabelas de seu banco de dados? CRASH!CRASH!
Para lidar com problemas em tabelas, estas controladas por um dos vários Storage
Engines existentes no MySQL, precisamos entender primeiro como funciona cada
Storage Engine e posteriormente tomar as melhores decisões quanto à manutenção
destas tabelas;
O MySQL possui muitos recursos para lidar com problemas em tabelas, desde uma
queda na performance até problemas mais graves relacionados com crash ou
corrompimento de tabelas;
Geralmente, como o trabalho do DBA MySQL é baseado em terminais (Unix Like) ou
prompts (MS Windows), alguns comandos ou declarações estão disponíveis para o
profissional trabalhar com a análise, checagem, otimização, backup, restore e
reparação de tabelas de um banco de dados;

Além de comandos que podem ser executados, existem vários aplicativos
que são instalados juntamente com a instalação do servidor MySQL para
possibilitar manutenção em tabelas;
Tais aplicativos podem requerer autenticação, pois acessarão as tabelas
através do servidor MySQL ou não, acessando os arquivos e efetuando a
reparação ou outro trabalho;
Os aplicativos ficam na pasta bin em uma instalação padrão do servidor
MySQL;

myisam_recover
Tabelas MyISAM podem apresentar problemas de corrompimento com
bastante facilidade;
Podemos utilizar o my.ini ou o my.cnf para reiniciar o banco, forçando um
recovery, ou auto_repair de uma tabela MyISAM adicionando a
seguinte opção ao agrupamento [mysqld]:
[mysqld]
myisam-recover=BACKUP,FORCE
Após adicionar a linha acima e salvar o arquivo, o servidor MySQL deve ser
reiniciado;

myisam_recover
A opção myisam_recover, que pode ser adicionada ao arquivo de opções do
MySQL, my.ini ou my.cnf, contempla as seguintes opções (auto-repair):
– DEFAULTDEFAULT: efetua o recovery sem trabalhar as demais opções;
– BACKUPBACKUP: efetua backup das tabelas, caso seu estado do arquivo de dados (“.MYD.MYD”)
tenha sido modificado durante o processo de recovery;
– FORCEFORCE: efetua o recovery, mesmo que linhas sejam perdidas do arquivo de dados
(“.MYD.MYD”);
– QUICKQUICK; o menos eficiente dos métodos, não faz a checagem na tabela e tenta efetuar
um rápido recovery;
Normalmente, a opção myisam-recover é mais eficiente com problemas
relacionados ao arquivo de índices (“.MYI.MYI”);

myisamchk
Trabalhos de reparação em tabelas MyISAM também podem ser desempenhados
com o aplicativo myisamchk, que é disponibilizado juntamente com a instalação
do servidor MySQL (instalação padrão);
O myisamchk é utilizado em linha de comando, tanto em sistemas operacionais
MS Windows quanto em Unix Like Systems;
Digitando myisamchk -?, serão exibidas as opções;
C:>myisamchk -a D:mysqldatatest*.MYI"
Checking MyISAM file: D:apache2triadmysqldatatestt2.MYI
Data records: 0 Deleted blocks: 0
- check file-size
- check record delete-chain
- check key delete-chain
- check index reference

CHECK TABLES
Caso necessitemos de recuperar informacões do estado atual da tabela para
diagnosticar algum problema, podemos utilizar o comando de checagem CHECKCHECK
TABLETABLE, que retornará uma mensagem de OK quando a tabela não contar com
nenhum problema ou uma mensagem de erro, relatando quais são os problemas
encontrados:
mysql> CHECK TABLE tbl_3;
+-------------+-------+----------+---------------------------------------+
+-------------+-------+----------+---------------------------------------+
| teste.tbl_3 | check | error | Size of datafile is: 490Should be: 637|
| teste.tbl_3 | check | error | Corrupt |
+-------------+-------+----------+---------------------------------------+
2 rows in set (0.31 sec)
Comando utilizado também com tabelas InnoDB e Archive;

CHECK TABLES
CHECK TABLESCHECK TABLES também são suportados por tabelas InnoDB e Archive. Para
tabelas MyISAM, os índices tem suas estatísticas atualizadas;
Sintaxe Geral do comando:Sintaxe Geral do comando:
CHECK TABLECHECK TABLE tbl_nametbl_name [,[, tbl_nametbl_name] ... [] ... [optionoption] ...] ...
optionoption = {FOR UPGRADE | QUICK | FAST | MEDIUM | EXTENDED | CHANGED}= {FOR UPGRADE | QUICK | FAST | MEDIUM | EXTENDED | CHANGED}

REPAIR TABLE
Caso a tabela esteja corrompida e o servidor MySQL esteja acessível, mas não a
tabela, ainda temos alguns comandos para reparação de uma tabela:
– REPAIR TABLEREPAIR TABLE: efetua a reparação de uma tabela MyISAM, com a opção
FORCE (-f). Linhas podem ser perdidas;
mysql> select * from tbl_3;
ERROR 1194 (HY000): Table 'tbl_3' is marked as crashed and should be
repaired
mysql> REPAIR TABLE tbl_3;
+-------------+--------+----------+---------------------------------------+
+-------------+--------+----------+---------------------------------------+
| teste.tbl_3 | repair | warning | Number of rows changed from 101 to 91 |
| teste.tbl_3 | repair | status | OK |
+-------------+--------+----------+---------------------------------------+
2 rows in set (0.03 sec)

REPAIR TABLE
REPAIR TABLEREPAIR TABLE só é suportado por tabelas MyISAM e Archive;
Requer privilégios SELECTSELECT e INSERTINSERT na tabela;

Após a tabela ser reparada, atente-se para o seu conteúdo e certifique-se
que este não foi perdido de forma extrema ou mesmo danificado;
Caso haja dano nos dados, é aconselhável o restore do último backup
confiável com o utilitário mysqldump, o qual veremos mais à frente;
Existem outros comandos para analisar a performance da tabela e
também atualizar as suas estatísticas para otimização de busca de dados
em tabelas e outro para otimizar a mesma, desfragmentando as suas
páginas de dados, diminuindo o espaço a ser percorrido;
Os comandos são utilizados dentro do mysql monitor;

ANALYZE TABLE
ANALYZE TABLE;ANALYZE TABLE;
O comando ANALYZE TABLEANALYZE TABLE é responsável por organizar a chave utilizada para
consultas em uma tabela. Durante o comando, a tabelas MyISAM e BDB recebem
um LOCK READLOCK READ interno e tabelas InnoDB recebem um bloqueio exclusivo;
mysql> ANALYZE TABLE tbl_3;
+-------------+---------+----------+-----------------------------+
+-------------+---------+----------+-----------------------------+
| teste.tbl_3 | analyze | status | Table is already up to date |
+-------------+---------+----------+-----------------------------+
Comando utilizado também com tabelas InnoDB e BDB;

ANALYZE TABLE
Requer privilégios SELECTSELECT e INSERTINSERT;
Equivalente a utilizar o utilitário myisamchk com a opção –-analyze;
ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLEANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_nametbl_name [,[, tbl_nametbl_name] ...] ...

OPTMIZE TABLE
OPTIMIZE TABLE;OPTIMIZE TABLE;
Desfragamenta as páginas de dados e elimia espaços em branco após grandes
atualizações em uma tabela de um banco de dados, otimizando a busca de
informações;
Caso haja páginas divididas – “split pages” – esse comando reparará e
reclassificará as páginas de índices atualizando as estatísticas de índices,
otimizando consultas posteriores;
mysql> OPTIMIZE TABLE tbl_3;
+-------------+----------+----------+----------+
+-------------+----------+----------+----------+
| teste.tbl_3 | optimize | status | OK |
+-------------+----------+----------+----------+

OPTMIZE TABLE
Comando utilizado também com tabelas InnoDB e Archive;
Requer que o usuário tenha privilégios SELECTSELECT e INSERTINSERT na tabela;
OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLEOPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_nametbl_name [,[, tbl_nametbl_name] ...] ...

mysqlcheck
O utilitário mysqlcheck é um utilitário também disponibilizado a partir da
instalação do servidor MySQL;
Esse utilitário pode ser acessado através do terminal ou prompt para
reparar, analisar, checar e otimizar tabelas;

mysqlcheck
Para checar as opções do mysqlcheck, basta digitar:
shell > mysqlcheck –ushell > mysqlcheck –u <user><user> -p <banco> <tabela> [options]-p <banco> <tabela> [options]
As opções que foram utilizadas no exemplo foram:
– -c: CHECK;
– -a: ANALYZE;
– -o: OPTIMIZE;
Para saber das opções disponíveis para utilização do mysqlcheck, utilize a
opção --help (este utilitário é um cliente mysql, portanto necessita que o
banco esteja no ar para o seu funcionamento);

Assim como em todos os Sistemas de Gerenciamento de Bancos de Dados,
não somente os dados deve ser gerenciados, mas também os usuários que
acessam o servidor;
O gerenciamento de usuários ou de contas de usuários, como é chamado no
MySQL, é feito nos níveis de banco de dados, tabela e coluna;
Para que um usuário de conecte ao servidor de bancos de dados MySQL, é
necessário que seu username, password e hostname sejam aqueles que foram
cadastrados quando da sua inclusão como usuário de um banco de dados, em
um servidor MySQL;
Um usuário que acaba de ser criado, terá privilégios hipotéticos, nomeado
pelo MySQL de USAGEUSAGE, podendo executar pequenos comandos, estes que não
alteram o estado do banco de dados;

A inclusão e gerenciamento de usuários em um servidor de bancos de dados no MySQL
pode se dar via linha de comando – terminal ou prompt - ou ainda via MySQL
Administrator;
Via MySQL Administrator, que é uma interface gráfica de administração e
gerenciamento de servidores de bancos de dados MySQL, cedida pela MySQL Inc., a
adição de usuários é bem facilitada e os comandos são enviados ao SGBD por esta
aplicação;
Para gerenciarmos usuários em um servidor de banco de dados MySQL em linha de
comando – terminal ou prompt -, é necessário conhecermos os principais comandos
para administração de usuários, criação, concessão de privilégios e a revogação destes;
Para criação, concessão de privilégio e sua a revogação destes, utilizamos as
declarações CREATE USERCREATE USER, GRANTGRANT e REVOKEREVOKE. Tais comandos provê interface direta
com as tabelas chamadas grant tables;

Os usuários devidamente cadastrados em um servidor de bancos de
dados MySQL, tem suas informações inseridas em tabelas do banco de
dados chamado mysql, que é o banco de dados que abriga tabelas com
informações de usuário e seus privilégios, chamadas de grant tables;
Nota de segurança:
Quando se instala de forma padrão um servidor de bancos de dados
MySQL, algumas contas iniciais são criadas sem password. Como sabemos
que o principal usuário do MySQL é o usuário root, ele se encontra no
momento incial sem uma senha, o que traz problemas graves de
insegurança do servidor e seus bancos de dados.

As tabelas de privilégios, em inglês, grant tables, são tabelas contidas no
banco de dados mysql, que armazenam informações de controle de acesso ao
servidor de bancos de dados MySQL;
Quando um usuário é cadastrado em um servidor de bancos de dados MySQL,
através do comando CREATE USERCREATE USER, um linha é inserida na tabela UserUser do
banco de dados mysql. Nesse momento, este usuário não tem nenhum
privilégio, somente o de acessar o servidor e utilizar os comandos SHOWSHOW
STATUSSTATUS e SHOW VARIABLESSHOW VARIABLES. Tal privilégio é chamado de USAGEUSAGE ou ainda
“no privileges”;
Caso dermos privilégios para este usuários, de acordo com estes privilégios, as
outras tabelas do banco de dados mysql, vão recebendo novas linhas,
atingindo novos níveis de privilégios sobre objetos de um ou mais bancos de
dados, afetando as tabelas dbdb, tables_privtables_priv, columns_privcolumns_priv e
procs_privprocs_priv;

Os privilégios para um usuário podem ser aplicados nos seguintes níveis:
ONON *.*
ONON db_name.*
ONON db_name.table_name
ONON db_name.routine_name
O símbolo * significa todos e a declaração ONON significa “em”, ou seja,
podemos conceder privilégios à usuários em todos os bancos de dados e
todas as tabelas existentes em um servidor de bancos de dados MySQL,
conceder privilégios em todos as tabelas de um banco de dados, em uma
tabela de uma banco de dados e ainda aplicar privilégios para um usuário
em uma determinada rotina (Stored Procedure, Cursor e/ou Function);

A autenticação de um usuário em um servidor de bancos de dados MySQL
primeiro verifica a existência do par User + Host. Conferido esse par, a
senha é verificada para identificar o usuário;
Estas informações são armazenadas na tabela User do banco de dados
mysql;
O Host de onde o usuário origina a conexão deve ser cadastrado
juntamente com seu nome de usuário, que deve ser intuitivo e caso utilize
caracteres especiais deve ser deveidamente delimitado por aspas simples
ou duplas;

Podemos cadastrar usuários em um servidor de bancos de dados MySQL,
através do comando CREATE USERCREATE USER, conforme segue abaixo um exemplo:
CREATE USERCREATE USER ‘jim’@@’localhost’;
O usuário jim, foi devidamente cadastrado no servidor de bancos de dados
MySQL e como não abordamos a declaração IDENTIFIED BYIDENTIFIED BY, uma senha
para este não foi atribuída. Por motivos de segurança, interessante seria
cadastrarmos usuários com senha, da seguinte forma:
CREATE USERCREATE USER ‘jim’@@’localhost’ IDENTIFIED BYIDENTIFIED BY ‘ABCR54327’;

Nesse momento, adicionarmos o usuário jim, para originar conexões com o
servidor de bancos de dados MySQL a partir do host chamado localhost
com senha ABCR54327;
Neste momento, jim tem privilégios mínimos, chamados de USAGEUSAGE ou ainda
“no privileges” e somente pode se conectar ao MySQL e enviar pequenos e
hipotéticos comandos;
Caso jim tente se conectar de um host diferente de localhost ou
127.0.0.1, sua conexão será banida pelo servidor de bancos de dados
MySQL;
Para verificar os privilégios de um usuário, temos as seguintes declarações:
SHOW GRANTSSHOW GRANTS;
SHOW GRANTS FORSHOW GRANTS FOR ‘jim’@‘localhost’;

Ao checarmos os privilégios do usuário jim, temos o seguinte retorno do servidor
de bancos de dados MySQL:
mysql> SHOW GRANTS FOR 'jim'@'localhost';
+--------------------------------------------------+
| Grants for jim@localhost |
+--------------------------------------------------+
| GRANT USAGE ON *.* TO 'jim'@'localhost' |
+--------------------------------------------------+

No momento, como o usuário jim não tem nenhum privilégio, ou somente privilégio
USAGE, temos que saber quais são os possíveis privilégios que podemos conceder ao
usuário;
O tipos de privilégios disponíveis no MySQL se dividem em Administrative PrivilegesAdministrative Privileges e
Database-Access PrivilegesDatabase-Access Privileges;
Podemos conceder privilégios de acesso global, para um usuário acessar qualquer
tabela em qualquer banco de dados, para acesso não-global, incidindo em qualquer
tabela dentro de um banco de dados, uma ou mais colunas de uma tabela em um
banco de dados ou ainda acesso a uma Stored Routine;
Para conceder privilégios à usuários, utilizamos a declaração GRANTGRANT. Tal declaração
também criará um novo usuário caso o SQL_MODESQL_MODE não esteja configurado com a
opção NO_AUTO_CREATE_USER;

Gerenciamento de Usuários – Adm Privs

Gerenciamento de Usuários – DB Access Privs

Acesso global a qualquer tabela, routine em qualquer banco de dados:Acesso global a qualquer tabela, routine em qualquer banco de dados:
mysql> GRANT ALL PRIVILEGES ON *.* TO 'jim'@'localhost';
Acesso de leitura a uma tabela de um banco de dados:Acesso de leitura a uma tabela de um banco de dados:
mysql> GRANT SELECT ON teste.* TO 'jim'@'localhost';
Acesso de leitura e escrita a uma tabela de um banco de dados:Acesso de leitura e escrita a uma tabela de um banco de dados:
mysql> GRANT SELECT, INSERT ON teste.* TO 'jim'@'localhost';

Acesso de leitura em colunas de uma tabela de um banco de dados:Acesso de leitura em colunas de uma tabela de um banco de dados:
mysql> GRANT SELECT (ID, Name) ON world.City TO 'jim'@'localhost';
Podemos liberar o acesso do usuário jim para que este acesse o servidor
de bancos de dados MySQL a partir de outros servidores. Para isso,
devemos, primeiro, comentar com o símbolo #, a opção denominada
bind-adress no arquivo de opções, my.ini ou my.cnf;
Feito isso, podemos conceder o privilégio para acesso originado de outros
servidores, que por sua vez, tem suas particularidades;

Para liberarmos o acesso remoto, é permitido, dentro do servidor de bancos de
dados MySQL, trabalharmos com valores DNS ou mesmo valores de IP e/ou faixa
de IP, ou ainda, aceitar para um determinado usuário, conexões vindas de
qualquer servidor;
O seguinte comando, cria um novo usuário, chamado jim, com a mesma senha
de antes, mas agora com acesso liberado a partir de um servidor/host
denominado ferrari.com:
mysql> GRANT SELECT (ID, Name) ON world.City TO 'jim'@'ferrari.com';
Podemos fazer o mesmo utilizando IP’s, mas com mais flexibilidade, pois podemos
utilizar o coringa % para determinar uma faixa de IP no qual o usuário poderá se
conectar;

Para liberar uma faixa de IP’s para acesso remoto ao servidor de bancos
de dados MySQL, pelo usuário jim, podemos proceder da seguinte forma:
mysql> GRANT SELECT (ID, Name) ON world.City TO 'jim'@'192.168.0.%';
Outros casos podem ser aplicados:
mysql> GRANT SELECT (ID, Name) ON world.City TO 'jim'@'192.168.%';

Por padrão, não existem limites ao número de consultas ou conexões ao servidor de
bancos de dados MySQL realizadas por um usuário;
Podemos adicionar à declaração GRANTGRANT, utilizada para conceder privilégios à usuários
devidamente cadastrados em um servidor de bancos de dados MySQL, algumas outras
declarações para limitar o número máximo de conexões por hora, o número máximo
de consults que um usuário poderá enviar ao SGBD e o número máximo de UPDATEUPDATEs;
Tais opções utilizam também a cláusula WITHWITH, como utiliza-se com WITH GRANTWITH GRANT
OPTIONOPTION;
Para liberar mais recursos à contas que já chegaram a seus limites de interações com o
servidor de bancos de dados MySQL, basta enviarmos um FLUSH PRIVILEGESFLUSH PRIVILEGES;

Mysql for IBMers

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (10)

Similar to Mysql for IBMers

Similar to Mysql for IBMers (20)

More from Wagner Bianchi

More from Wagner Bianchi (16)

Mysql for IBMers

Editor's Notes