Mysql for IBMers

Treinamento MySQL AdministratorsFor 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 cuidandodo MySQL em um projeto denominado MariaDB, nome de sua 2 filha.


Ementa de Treinamento

Instalação do SGBD MySQLInstalação do SGBD MySQLArquitetura de SGBD MySQLLogsArquivo de ConfiguraçãoStorage EnginesManutenção de TabelasVariáveis de AmbienteVariáveis de StatusComandos AdministrativosINFORMATION_SCHEMAGerenciamento de UsuáriosScale-Out e Alta-DisponibilidadeCertificaçã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;




Instalação do SGBD MySQLArquitetura de SGBD MySQLArquitetura de SGBD MySQLLogsArquivo de ConfiguraçãoStorage EnginesManutenção de TabelasVariáveis de AmbienteVariáveis de StatusComandos AdministrativosINFORMATION_SCHEMAGerenciamento de UsuáriosScale-Out e Alta-DisponibilidadeCertificação – Curriculum Path


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:\...\MySQL\MySQL Server 5.1.0\bin>mysqld.exe --install MySQL_2Service successfully installed.

Após criado um novo serviço, podemos utilizar o comando net start <service_name> para iniciar o MySQL:

C:\Arquivos de programas\MySQL\MySQL Server 5.1.0\bin>net start MySQL_2O 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:\...\MySQL\MySQL Server 5.1.0\bin>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;



Instalação do SGBD MySQLArquitetura de SGBD MySQLLogsLogsArquivo de ConfiguraçãoStorage EnginesManutenção de TabelasVariáveis de AmbienteVariáveis de StatusComandos AdministrativosINFORMATION_SCHEMAGerenciamento de UsuáriosScale-Out e Alta-DisponibilidadeCertificação – Curriculum Path


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';

Query OK, 0 rows affected (0.00 sec)

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,, INSERT INSERT 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;Query OK, 0 rows affected (0.06 sec)

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';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;


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;



Instalação do SGBD MySQLArquitetura de SGBD MySQLLogsArquivo de ConfiguraçãoArquivo de ConfiguraçãoStorage EnginesManutenção de TabelasVariáveis de AmbienteVariáveis de StatusComandos AdministrativosINFORMATION_SCHEMAGerenciamento de UsuáriosScale-Out e Alta-DisponibilidadeCertificação – Curriculum Path


Arquivo de Configuração

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



Instalação do SGBD MySQLArquitetura de SGBD MySQLLogsArquivo de ConfiguraçãoStorage EnginesStorage EnginesManutenção de TabelasVariáveis de AmbienteVariáveis de StatusComandos AdministrativosINFORMATION_SCHEMAGerenciamento de UsuáriosScale-Out e Alta-DisponibilidadeCertificação – Curriculum Path


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

1 row in set (0.00 sec)

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;Query OK, 0 rows affected (0.00 sec)

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 |+-----------------+--------------------+----------+----------+1 row in set (0.00 sec)



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;

+-----------------+--------------------+----------+----------+

| Table | Op | Msg_type | Msg_text |

+-----------------+--------------------+----------+----------+

| 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 SET SET 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;Query OK, 0 rows affected (0.02 sec)

mysql> create table tbl_filha ( -> id_pai int not null primary key, -> constraint foreign key (id_pai) -> references tbl_pai(id) -> ) engine=innodb;Query OK, 0 rows affected (0.00 sec)



Declarando a FOREIGN KEYFOREIGN KEY com ALTER TABLEALTER TABLE:

mysql> create table tbl_pai ( -> id int not null primary key -> ) engine=innodb;Query OK, 0 rows affected (0.03 sec)

mysql> create table tbl_filha ( -> id_pai int not null primary key -> ) engine=innodb;Query OK, 0 rows affected (0.01 sec)

mysql> alter table tbl_filha add constraint FK_NAME -> foreign key (id_pai)references tbl_pai (id);Query OK, 0 rows affected (0.13 sec)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:

mysql> create table tbl_pai ( -> id int not null primary key -> ) engine=innodb;Query OK, 0 rows affected (0.00 sec)

mysql> create table tbl_filha ( -> id_pai int not null primary key -> ) engine=innodb;Query OK, 0 rows affected (0.00 sec)

mysql> alter table tbl_filha add constraint FK_NAME -> foreign key (id_pai) references tbl_pai (id) -> on delete cascade on update cascade;Query OK, 0 rows affected (0.05 sec)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;


ArchiveTabela 1:Tabela 1:

mysql> create table tb_myisam engine=myisam as mysql> 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: 0 Records: 112050 Duplicates: 0 Warnings: 0

Tabela 2:Tabela 2:

mysql> create table tb_innodb engine=innodb as mysql> create table tb_innodb engine=innodb as -> select * from mysql.user;-> select * from mysql.user;


Tabela 3:Tabela 3:

mysql> create table tb_archive engine=archive as mysql> create table tb_archive engine=archive as -> select * from mysql.user;-> select * from mysql.user;



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;


Manutenção de Tabelas

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:\mysql\data\test\*.MYI"Checking MyISAM file: D:\apache2triad\mysql\data\test\t2.MYIData 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 CHECK CHECK 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 TABLE CHECK 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 |

+-------------+--------+----------+---------------------------------------+



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;+-------------+---------+----------+-----------------------------+| Table | Op | Msg_type | Msg_text |+-------------+---------+----------+-----------------------------+| teste.tbl_3 | analyze | status | Table is already up to date |+-------------+---------+----------+-----------------------------+1 row in set (0.03 sec)

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] TABLE ANALYZE [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;+-------------+----------+----------+----------+| Table | Op | Msg_type | Msg_text |+-------------+----------+----------+----------+| teste.tbl_3 | optimize | status | OK |+-------------+----------+----------+----------+1 row in set (0.05 sec)


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] TABLE OPTIMIZE [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 –u shell > 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);


Gerenciamento de Usuários

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 SHOW SHOW 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';Query OK, 0 rows affected (0.14 sec)

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';Query OK, 0 rows affected (0.05 sec)

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';Query OK, 0 rows affected (0.00 sec)



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 GRANT WITH 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;



No exemplo abaixo, criamos uma nova conta de usuário com a declaração GRANTGRANT – nesse momento o SQL_MODESQL_MODE é igual a vazio – limitado os recursos para o usuário joca, para acessar o banco de dados world e poder somente realizar 1 conexão por hora, enviar somente 1 consulta e 1 UPDATEUPDATE:

mysql> GRANT ALL PRIVILEGES ON world.* TO 'joca'@'localhost'

-> IDENTIFIED BY '12345'

-> WITH MAX_CONNECTIONS_PER_HOUR 1

-> MAX_QUERIES_PER_HOUR 1

-> MAX_UPDATES_PER_HOUR 1;


Caso a opção MAX_CONNECTIONS_PER_HOURMAX_CONNECTIONS_PER_HOUR seja omitida do comando GRANTGRANT, a variável de ambiente max_user_connectionsmax_user_connections será utilizada como valor padrão;



Podemos também, conceder privilégios para um usuário para que este possa conceder privilégios iguais ou menores que os seus para outros usuários;

Basta acrescentarmos a declaração WITH GRANT OPTIONWITH GRANT OPTION ao final de uma declaração GRANTGRANT, que concede privilégios a um usuário;

Muito utlizado em que que existam vários departamentos sobre o departamento de tecnologia. Atribuímos os privilégios máximos ao gerente do departamento e este por sua vez, concede aos seus subordinados as devidas permissões iguais ou menores que as suas (o comando seguinte não criará um novo usuário, somente dará permissão a um já existente):

mysql> GRANT SELECT, INSERT, DELETE, UPDATE ON world.*

-> TO 'jim'@'localhost' WITH GRANT OPTIONWITH GRANT OPTION;




A partir de então, configuramos as permissões do usuário jim para que ele dê permissões no máximo iguais as suas para um usuário já existente na tabela User do banco de dados mysql;

mysql> GRANT SELECT ON world.City TO 'dim'@'localhost';


Caso o usuário jim tente dar permissões a mais do que aquelas que foram concedidas ao seu usuário, o servidor de bancos de dados MySQL retornará uma mensagem de erro relatando a operação ilegal:

mysql> GRANT DROP ON world.* TO 'dim'@'localhost';

ERROR 1044 (42000): Access denied for user 'jim'@'localhost'

to database 'world'



A sintaxe para o comando REVOKEREVOKE é praticamente a mesma do comando GRANTGRANT. São pequenas modificações;

Suponhamos que o usuário jim tenha os seguinte privilégios em um servidor de bancos de dados MySQL:

mysql> show grants for 'jim'@'localhost';

+----------------------------------------------------------------------+

| Grants for jim@localhost |

+----------------------------------------------------------------------+

| GRANT USAGE ON *.* TO 'jim'@'localhost' IDENTIFIED BY PASSWORD ‘1234'|

| GRANT SELECT ON `world`.* TO 'jim'@'localhost' WITH GRANT OPTION |

+----------------------------------------------------------------------+




Digamos que nesse momento queremos retirar todos os privilégios e também o GRANT OPTIONGRANT OPTION do usuário jim. O seguinte comando REVOKEREVOKE fará isso:

mysql> REVOKE ALL PRIVILEGES, GRANT OPTION ON world.*

-> FROM 'jim'@'localhost';


No caso que precisemos revogar privilégios de INSERTINSERT, SELECTSELECT, UPDATEUPDATE, DELETEDELETE ou qualquer outro tipo de privilégio, basta separá-los com vírgula;

Para que o comando REVOKEREVOKE trabalhe como o esperado, ele deve seguir os privilégios concedidos no comando GRANTGRANT;



Podemos setar um password para contas de usuários de várias formas, com o comando CREATE USERCREATE USER, GRANTGRANT, ambos utilizando a cláusula IDENTIFIED BYIDENTIFIED BY. Temos disponível também o comando SET SET PASSWORDPASSWORD;

Para atribuir ou trocar a senha de um usuário com o comando SET SET PASSWORDPASSWORD, é preciso utilizar a função PASSWORDPASSWORD() que criptografará a senha, deixando-a como uma string aceita para servidor de bancos de dados MySQL;

mysql> SET PASSWORD = PASSWORD('12345');Query OK, 0 rows affected (0.00 sec)

mysql> SET PASSWORD FOR 'usuario_3'@'localhost' = PASSWORD('12345');Query OK, 0 rows affected (0.02 sec)


Certificação – Curriculum Path

Mysql for IBMers

Technology

Transcript of Mysql for IBMers