Meetup (MySQL & MongoDB) 11-05-2017

Ola pessoal,

No dia 11-05, participei do meu primeiro evento voltado a MySQL e MongoDB, o qual foi organizado pela Percona em São Paulo.

Além de rever grandes amigos, em 4 horas aprendi horrores com grandes profissionais, como Marcelo Altmann, Airton Lastori, Wagner Bianchi, Adamo e também de conhecer o fundador do canal Bóson Treinamentos, canal que me proporcionou muito conhecimento, Fábio dos Reis.
Continue lendo

Obter logins e senhas no MySQL II

Ola caro amigo leitor,

No post obter logins e senhas no mysql foi disponibilizado um script para gerar um .sql com todos os logins e senhas de um servidor MySQL.

Desta vez, vamos aproveitar a facilidade do Percona Tool Kit e trabalhar com o utilitário pt-show-grants.

Em algumas distribuições, este pacote já esta disponível no repositório. Para checar basta:
Continue lendo

Obter logins e senhas no MySQL

Ola pessoal,

Ao efetuar uma migração no MySQL, no momento do restore podemos nos deparar com erros referentes ao definer setado nos objetos das bases, seja Views, Procedures ou Triggers.

Exemplo do erro:

A cada nova versão, o banco interno do MySQL sofre alterações de estrutura, e não é recomendável restaurar o banco mysql obtido em uma versão 5.1 direto no 5.6 ou 5.7 por exemplo. Neste caso, executo um script no shell para obter a relação dos usuários, já com a senha criptografada junto as permissões. Segue:
Continue lendo

Migrando bases grandes no MySQL

Todo mundo diz que gerenciar o MySQL é fácil, afinal pelo phpmyadmin você consegue fazer quase tudo, inclusive efetuar import/export das bases facilmente, mas não existem Ateus quando você tem que migrar uma base com mais de 4GB por exemplo para outro servidor.

Tenho um amigo que passou por esta situação, precisou migrar uma base MySQL de um Revenda Cpanel para o seu host, porém na origem a base tinha cerca de 4GB, onde o phpmyadmin fazia o backup da base, mas devido as limitações do ambiente, ele não conseguia “varrer” todos os dados.

Os limites no phpmyadmin estão ligados diretamente as variáveis do php no ambiente Web, onde erros como Allowed Memory Size, Out off Memory são comuns neste tipo de ação. Tendo a autonomia, você pode aumentar o valor da variável “memory_limit” no php.ini, ou também existem variáveis do próprio phpmyadmin que aumentam o limite para o restore de uma base por exemplo, porém ambas não resolveram o meu problema.

Já trabalhei com bases muito superiores a 4GB, onde a migração apesar de ser um pouco demorada, sempre foi conclusiva, utilizando o próprio client do MySQL.

Nestes caso, no ambiente Cpanel criei um usuário com o host ‘%’, permitindo o acesso remoto a base, e atribui o all privileges para o usuário na base em que seria feito o backup.
Continue lendo

Replicação MySQL – Introdução

Ola pessoal,

Antes de configurarmos uma replicação no MySQL, é importante entendermos como ela funciona, por isso neste post vamos tratar de uma breve introdução a replicação Master x Slave no MySQL.

O MySQL por default já oferece suporte para Replicação. Funciona por um mecanismo assíncrono, unidirecional com o fornecimento de logs (binários) entre um servidor Master / Slave. Quando um servidor é denominado como Master, este recebe todas as atualizações (insert, alter, update), onde o Slave recebe todas as atualizações que ocorrem com êxito no master, mantendo desta forma os dados íntegros do servidor Master.

O Slave muitas vezes é definido como Ready Only, sendo possível apenas efetuar consultas (select) neste servidor, e demais comandos de alteração devem ser aplicados no servidor Master.

Existem Threads pré definidas no MySQL responsáveis pela comunicação entre os servidores, que são:

IO_THREAD – Responsável pela conexão entre o servidor Master X Slave e pelo download dos logs binarios entre a origem (Master) ao destino (Slave). Ao fazer o download dos logs binarios do servidor Master, o IO_THREAD armazena estes logs no relay log (Slave), arquivo que o Slave vai ler para aplicar as transações.

SQL_THREAD – Esta é a thread que aplica todos os logs obtidos no relay log no servidor Slave.

Resumindo (POR CIMA), o primeiro se conecta e obtem os logs do Master, e o segundo executa os logs obtidos no servidor Slave.

Uma imagem que resume muito bem este cenário:

AR

Imagem obtida no site: http://www.devmedia.com.br/

Não existe um limite definido de quantos slaves um único master pode ter abaixo dele. Como um servidores Slave consome uma quantidade pequena de recursos, este limite é baseado na disponibilidade do ambiente como em quantidade de consultas, escrita, disponibilidade de memória & Cpu entre outros. Se citarmos uma bala de “prata”, não é recomendável ter a mais de 30 slaves sob um master.
Continue lendo

Manutenção em tabelas – MySQL

Ola pessoal,

Manter a integridade dos dados e efetuar uma manutenção das tabelas em sua base de forma períodica, é importante para sempre manter um resultado eficaz em produção.

As tabelas em sua base podem ficar corrompidas devido a uma falha no servidor, principalmente quando ele é reiniciado de forma incorreta. Com isso, você pode perceber lentidões em consultas que geralmente são rapidas, porém podemos ter certeza ao consultar os logs de erro do MySQL.

Segue abaixo a relação de instruções SQL que podemos utilizar no dia a dia:

Analyze table:

Analisa e armazena a distribuição de chave de uma tabela, para uma tomada de decisão referente a junção das tabelas ou na utilização dos indices. Durante esta analise, a tabela ganha um nível de bloqueio para os engines InnoDB e MyISAM.

Esta instrução esta disponível para os Engines: InnoDB e MyISAM.

Ex feito em tabelas MyISAM e InnoDB:

Caso a tabela não tenha sido alterada desde o ultimo analyze, a mesma não será analisada novamente: ‘Table is already up to date’.

Check table:

Verifica a integridade da tabela a fim de identificar algum erro ou inconsistência.

É valida para os Engines: InnoDB, MyISAM, Archive. Caso seja executada em uma tabela MyISAM, as estatisticas dos indices também são atualizadas. Abaixo segue demais opções que podem ser incluidas apenas ao MyISAM:

– Quick: Não verifica os registros buscando as ligações incorretas. Validas para o Engine InnoDB e MyISAM e views.
– Fast: Verifica apenas as tabelas que não foram fechadas de forma correta. Valido apenas para tabelas MyISAM e views, e inválido para o InnoDB.
– Changed: Verifica somente as tabelas que foram alteradas desde a ultima analise ou que não foram fechadas de forma correta. Aplica-se para tabelas MyISAM e views, e inválido ao InnoDB.
– Medium: Efetua uma varredura para verificar se os registros/ligações removidas são válidas. Calcula também uma chave de conferência para os registros com base no check sum calculado para as chaves. Aplica-se para tabelas MyISAM e views, e inválido ao InnoDB.
– Extended: Faz uma consulta completa para todas as chaves de cada registro. Aplica-se para tabelas MyISAM e views, e inválido ao InnoDB.

Segue um exemplo de execução em tabelas MyISAM e InnoDB:
Continue lendo

Locks no MySQL

Ola pessoal,

Depois de falarmos sobre transações e níveis de isolamento, vamos fechar este assunto com os conceitos de bloqueio utilizados no MySQL.

O MySQL usa uma arquitetura multi-thread para gerenciar as conexões a todos os usuários, onde cada conexão tera uma thread como um controlador. O bloqueio adotado pelo MySQL impede a ocorrência de problemas com dados acessados de forma simultânea por vários clientes, onde uma conexão não ira interferir na outra.

Quando varios clientes tentam manipular o mesmo dado, o MySQL atribui um bloqueio a um cliente com base na thread, onde enquanto este bloqueio não seja liberado, os outros clientes não conseguem manipular o mesmo dado, ou seja, cada um tem a sua vez.

O efeito do mecanismo de bloqueio é serializar o acesso aos dados, onde clientes que tentam efetuar operações conflitantes deverão aguardar a sua vez.

Mas nem todo o tipo de acesso gera um conflito, um exemplo:

– Caso a conexão “A” e “B” precisem ler algum dado, isso não irá gerar um conflito e os dois poderão ler ao mesmo tempo.

– Caso a conexão “A” inicie uma leitura e a “B” precise gravar um novo dado, a conexão “B” deverá aguardar a leitura da conexão “A” ser finalizada, para assim conseguir gravar o novo dado.

– Agora se a conexão “A” iniciar uma gravação de dados, todas as conexões abaixo deverão aguardar a gravação ser concluida, seja ela uma conexão de leitura ou gravação.

Uma operação de leitura deve bloquear uma operação de gravação, porém uma operação de gravação deve bloquear as demais seja leitura ou gravação até a sua finalização

Tipos de bloqueio:

— Implicito

Os bloqueios sobre os dados podem ser de forma implícita, explícita ou com advisory locks.

Caso você trabalhe com o autocommit habilitado no MySQL, o servidor adquiri bloqueios implicitamente para cada comando, e cancela o mesmo após a conclusão.
Continue lendo

Metadados Information_schema – MySQL

Ola pessoal,

Sabemos que um banco de dados é um conjunto estruturado de dados com o objetivo de retornar alguma informação.

Quando falamos de “metadados”, tratamos sobre os dados sobre outros dados. Um pouco confuso, mas o principal objetivo é saber que os metadados tratados no MySQL, estão disponíveis na information_schema. Saber manusear os metadados nesta base é tarefa diária do DBA.

A information_schema é a estrutura de dicionário de dados utilizada pelo MySQL, funcionando como um repositório central para metadados de qualquer banco de dados.

Nela podemos obter:

– Todo o schema de objetos
– Estatisticas do servidor (Conexões, uso de CPU, Bytes enviados e recebidos)
– Privilégios
– Store procedure e Views

Porém ele é um banco de “dados virtual”, já que em nenhum momento ele esta armazenado no disco. Mas contem tabelas como qualquer outra base, onde o seu conteudo pode ser acessado com a instrução select.

O primeiro exemplo, podemos verificar os grants atribuidos a um usuário:

Acompanhar os processos que são executados na instância. Geralmente, esta opção é mais completa do que utilizar o “show processlist”, já que você consegue atribuir critérios para filtrar a sua busca:
Continue lendo

Transações no MySQL

Ola pessoal,

Falaremos agora sobre transações, para então dar continuidade a outro assunto que é importante, os níveis de isolamento.

Primeiramente, uma transação é um meio de executar uma ou mais instruções SQL com uma única unidade de trabalho, onde todas ou nenhuma das instruções são bem sucedidas.

Ou seja, se todas as instruções foram concluidas sem erros, você poderá registrar estas em definitivo no banco de dados. Porém caso ocorra algum erro, você poderá retornar a um ponto de salvamento ou efetuar um rollback, cancelando a alteração.

Um exemplo simples via SQL:

Continue lendo