A agência reguladora antitruste da Rússia, FAS, aprovou nesta sexta-feira (19/03) a compra da Sun Microsystems pela Oracle por US$ 7 bilhões sob a condição de que a Oracle continue desenvolvendo a base de dados MySQL, da Sun.

O FAS afirmou que teria causa para ir à justiça e pedir por uma invalidação do acordo, já aprovado incondicionalmente pela União Europeia, caso a Oracle não cumpra com suas exigências.

“O FAS analisou o pedido e … decidiu aprová-lo”, afirmou a agência em comunicado, acrescentando que a aprovação seria válida apenas se a Oracle cumprir suas exigências em relação ao MySQL.

A agência afirmou que a Oracle deve continuar criando novas versões da base de dados dentro das especificações da licença normalmente acessível e que não deve forçar clientes a contratar seus serviços caso queiram uma licença comercial para o uso do MySQL.

O FAS ainda acrescentou que a condição vale por apenas quatro anos após a conclusão formal do acordo.

Em janeiro, a Oracle conseguiu a aprovação da União Europeia para a aquisição, após prometer que manterá o mercado aberto para que outros produzam software de armazenamento para o MySQL e que aumentará investimentos no setor.

A empresa também prometeu criar um conselho separado para consumidores usuários da base de dados do MySQL. Essas concessões deixaram a reguladora europeia satisfeita de que o negócio não afetará de maneira nenhuma o mercado.

Mas o criador do MySQL, Michael Widenius, que é contra o plano de fusão, disse que a decisão executiva da União Europeia foi errada e divulgou sua oposição na Rússia e na China.

Fonte: G1

Você pode já ter lido vários artigos sobre esse assunto na web, mas provavelmente conseguiu apenas partes da informação necessária. É hora de colocar tudo junto e na prática.

Você tem um projeto/sistema rodando no MySQL e de repente você descobre que você precisa migrar para PostgreSQL. E você se depara com um SQL diferente para cada plataforma, o MySQL trabalha com SQL e o PostgreSQL trabalha com PL/SQL, mas você não tem tempo para reescrever o código do zero e, logicamente, se você tiver tempo de reestruturar o seu projeto para PostgreSQL, o seu Data Base vai ficar mais organizado e, como um bom Data Base deve ser com relacionamento entre tabelas, trigger, functions e etc.

Na verdade, pode haver boas razões para migrar um Data Base de MySQL para PostgreSQL:

• Você podera vender o seu produto com total tranquilidade (PostgreSQL é licenciada BSD, o diferente de  MySQL)
• Você pode encontrar artigos “Migrando MySQL para PostgreSQL” na web, mas você não vai encontrar nenhuma “Migrando PostgreSQL para MySQL”
• PostgreSQL não pode ser apenas mais um péssimo banco de dados se o Skype, Cisco, Juniper, IMDb, Pandora ou NOVA TV decidiram confiar nele, além de a Sun Microsystems tê-lo tornado como base de dados de escolha (o que é extremamente hilario, já que em janeiro de 2008 ela comprou o MySQL)

No PostgreSQL você ainda pode sentir um pouco como se senti uma pessoa com segurança particular. Existem alguns grandes projetos como o Asterisk, Horde ou DBMail que já reconheceram suas qualidades e que, embora o MySQL tenha sido sua primeira escolha de Banco de Dados, eles estão demonstrando grande esforço para fazer tudo funcionar corretamente.

Convertendo Base de Dados MySQL para PostgreSQL

Primeiro vamos fazer Backup de nossa Data Base MySQL com o software mysqldump do próprio MySQL:

"mysqldump --compatible=postgresql bancodedados > bkp-bancodedados.sql"

Convertendo caracteres para o SQL ficar funcional no PostgreSQL:

"sed "s/\\\'/\'\'/g" bkp-bancodedados.sql"

* Este processo vai demorar muito tempo porque o software "sed" varrerá
 todo o arquivo para fazer a conversão

"psql -h server -d databasename -U username -W < bkp-bancodedados.sql"

Por vezes existem projetos em que se torna conveniente (por várias razões) utilizar outro tipo de base de dados. Seja que banco de dados for, a sua integração é sempre diferente do SQL Server.

Neste caso vou mostrar como fazer a integração entre o C# e o MySQL.

Supondo que já existe uma instalação do MySQL na máquina, precisamos instalar um intermediário entre o C# e a base de dados. Neste caso necessitamos instalar o MySQL Connector NET.

Download

A versão 5.2 já tem suporte ao Visual Studio 2008, mas eu vou utilizar a última versão (6.0).

Instalamos o Connector Net 6.0.

Devemos já ter uma base de dados com uma tabela (users por exemplo), em que os campos da tabela são: id, nome, email.

Como exemplo criamos um projecto Windows Forms Application.

Antes de mais nada, devemos fazer uma referência à classe que vai ligar o C# ao MySQL. Para isso vamos ao painel Solution Explorer, na raiz do projeto, clicamos com o lado direito do mouse e selecionamos Add Reference.

Na primeira divisória (.NET) selecionamos a referência MySQL.Data e damos OK.

Não esquecer: incluir no início do código as classes:

using System.Data;

using MySql.Data.MySqlClient;

Sem adicionar a referência à MySQL.Data, a classe MySql.Data.MySqlClient não será reconhecida.

Para exemplificar fazemos um formulário de inserção de dados (nome e e-mail) na base de dados.

No form colocamos duas caixas de texto, uma para o nome (txtNome) e outra para o e-mail (txtMail) e um botão que terá a ação de inserir os dados na base de dados.

Vamos então definir, em primeiro lugar, o dataset e a string de conexão à base de dados.

private MySqlConnection bdConn; //MySQL
private MySqlDataAdapter bdAdapter;
private DataSet bdDataSet; //MySQL

Na ação do botão:

//Definição do dataset
bdDataSet = new DataSet();
 //Define string de conexão
bdConn = new MySqlConnection("Persist Security  Info=False;server=localhost;database=rfidapp;uid=root;server=localhost;database=rfidapp;uid=root;pwd=''");

Neste caso a base de dados não tem password.

//Abre conecção
 try{
        bdConn.Open();
}
catch{
 MessageBox.Show("Impossível estabelecer conexão");
}
//Verifica se a conexão está aberta
if (bdConn.State == ConnectionState.Open)
{
        //Se estiver aberta insere os dados na BD
MySqlCommand commS = new MySqlCommand("INSERT INTO regists VALUES('',\\'" + txtNome + "\\',\\'" + txtMail + "\\')", bdConn);
commS.BeginExecuteNonQuery();
}

Tome atenção na sintaxe do SQL para o MySQL (INSERT) que é um pouco diferente do C#/SQL Server.

Neste momento o formulário deverá inserir dados no BD.

Fonte: Imasters

Criem a base de dados com o nome lportal.

Poderão fazer isto utilizando o MySQL Administrator (a ferramenta de administração do MySQL) ou usando a seguinte linha de comando:

mysqladmin –default-character-set=utf8 create lportal

2. Configuração do acesso à base de dados com o eclipse

Abram o Data Source Explorer do eclipse (Window -> Show view -> Data Source Explorer).

Selecionem o ícone ‘New Connection Profile’ ou usem o botão direito do mouse sobre ‘Databases’ e depois selecionem ‘New’.

Na janela ‘New Connection Profile’ selecionem o tipo SQL Model-JDBC Connection.

No quadro seguinte, indiquem um nome para o perfil (ex: ‘Liferay – Mysql’).

No último quadro, usem o botão de procura (‘?’) na lista “Select a browser”.

Adicionem uma nova definição:

• Localizem o template para bases de dados MySQL na árvore (Database -> MySQL -> 5.0 -> MySQL JDBC Driver).

• Alterem as definições do driver:- Alterem o nome para ‘Liferay MySQL Driver’;

  - Removam o driver ‘default’ e adicionem um novo Jar correspondente ao arquivo $WORKSPACE/ext/lib/development/mysql.jar ($WORKSPACE corresponde à localização da pasta do seu workspace no sistema de arquivos);

  - Configurem o valor das propriedades de acesso (username, password, etc?) tendo em atenção que o valor do ‘Database Name’ e, por consequência, o final da linha do ‘Connection URL’ deverá ser ‘lportal’.

• Confirmem as alterações e selecionem agora este driver nas definições do driver (Database -> MySQL -> 5.0 -> Liferay MySQL Driver).

Voltem de novo à janela de criação do perfil e validem que todas as informações estão de acordo com a sua configuração (podem testar a ligação a partir desta janela).

3. Criação do modelo de dados

Editem o arquivo create-mysql.sql na pasta /sql/create do projecto ‘ext’. Caso não tenham memória para desperdiçar (é o meu caso), respondam afirmativamente quando o eclipse perguntar se pretendem desligar a validação de sintaxe do arquivo.

No topo da janela de edição do ficheiro está a configuração do ‘Connection profile’. Selecionem o tipo Generic JDBC_1.x, o driver ‘Liferay – Mysql’ e a base de dados lportal.

Nota: caso o status não seja ‘Connected’ , vocês não vão conseguir ver o nome da base de dados.
Neste caso devem acessar o Data Source Explorer ( Window -> Show View -> Data Source Explorer), selecionar a Database ‘Liferay – MySQL’ e fazer connect (botão direito do mouse)

Comentem as três primeiras linhas do ficheiro, uma vez que a base de dados já foi criada

• drop database if exists lportal;
• create database lportal character set utf8;
• use lportal;

Gravem e executem o sql (ctrl+alt+X ou Execute All no menu contextual).

4. Configuração do datasource no tomcat

Editem o arquivo Root.xml localizado na pasta servers/tomcat/conf/Catalina/localhost do projeto ‘ext’.

Comentem o datasource do Hypersonic e descomentem o datasource do MySQL.

Preencham os atributos username e password e, caso não estejam usando os valores default do MySQL, editem também o valor do atributo url, de acordo com a sua configuração.

Gravem as alterações.

5. Deploy da configuração para o servidor

Copiem o arquivo Root.xml para a pasta conf/Catalina/localhost do tomcat.

Copiem e o arquivo mysql.jar para para a pasta lib/ext do tomcat.

Fonte: Imasters

A partir do diagrama mostrado no artigo anterior precisamos fazer uma instalação nova do MySQL no servidor 192.168.1.35. O servidor 192.168.1.15 conterá as ferramentas administrativas do cluster e não precisa do MySQL instalado. Contudo, as ferramentas administrativas do cluster são distribuídas junto com os arquivos do MySQL.

A instalação do MySQL no servidor 192.168.1.35 deve ser feita da mesma maneira que o servidor já existente, isto é, o MySQL no servidor 192.168.1.35 deve conter todas as opções e configurações do servidor 192.168.25, pois a idéia é que o cluster funcione de forma transparente para a aplicação. Além disso, também é preciso transferir os usuários, objetos e permissões, pois o banco de dados será criado posteriormente. Em resumo, é preciso primeiro duplicar o ambiente do servidor 192.168.1.25 para o servidor 192.168.1.35, tomando cuidado com as configurações.

Uma vez que os dois servidores MySQL estiverem configurados e sendo executados nos servidores 192.168.1.25 e 192.168.1.35 podemos começar a configuração do cluster. O primeiro passo é configurar o serviço que fará a administração do cluster chamado mgmd (management deamon) no servidor 192.168.1.15. Antes de iniciar este serviço é preciso cadastrar os endereços I.P. dos nós do cluster no arquivo de configurações chamado config.ini, que está no mesmo diretório dos binários do mysql.

O arquivo config.ini possui várias sessões e chaves de configuração. De acordo com a arquitetura do exemplo, precisamos indicar neste arquivo que o servidor 192.168.1.15 conterá as ferramentas administrativas do cluster e que os servidores 192.168.1.25 e 192.168.1.35 serão os nós do cluster. Fazemos isso modificando a chave HostName da sessão [NDB_MGMD] de modo a colocar o endereço do servidor que conterá as ferramentas administrativas. Para cada nó do cluster devemos colocar o seu endereço na chave HostName da sua respectiva sessão [NDBD]. A Figura 1 mostra como ficará o arquivo config.ini do servidor que contém as ferramentas administrativas do cluster após a modificação de seu conteúdo em um simples editor de texto. As mudanças na seção [NDB_MGMD] são destacadas pelo retângulo amarelo e as modificações nas duas seções [NDBD] são destacadas pelo retângulo branco.

Figura 1. Modificações no arquivo de configuração config.ini

Após acertar os endereços IP dos servidores no arquivo de configuração config.ini é preciso iniciar o serviço mgmd (management deamon). Antes de iniciá-lo é preciso ter certeza que os MySQL dos servidores indicados como nós do cluster não estão sendo executados. Para iniciar o serviço mgmd no servidor 192.168.1.15 basta executar o deamon pelo comando ndb_mgmd, como as últimas linhas da Figura 2 mostram. Para verificar se o serviço foi iniciado sem problemas podemos utilizar o seguinte comando que verifica os processos do servidor: ps -A | grep mgm.

Figura 2. Iniciando o servidor ndb_mgmd.

Após iniciar o serviço podemos nos conectar localmente ou remotamente na ferramenta de administração do cluster. Esta ferramenta chama-se Management Client e é executada pelo comando ndb_mgm. Após iniciar a ferramenta devemos enviar o comando SHOW para verificar o estado do cluster, como mostra a Figura 3.

Figura 3. Executando o Management Client do cluster MySQL.

A ferramenta Management Client é um console para a administração do cluster MySQL no Linux. Após a execução do comando SHOW ela mostra os nós que estão conectados ao cluster. Pode-se notar pela Figura 3 que o cluster colocou o id 2 para o servidor 192.168.1.25 e o id 3 para o servidor 192.168.1.35. A ferramenta também mostra que o id 1 corresponde ao servidor 192.168.1.5, pois ele contém o serviço de administração do cluster (ndb_mdmd). É possível modificar as configurações do cluster, inclusive adicionar ou remover nós, por meio de comandos enviados ao Management Client.

Agora que já configuramos o serviço de administração do cluster é preciso modificar as configurações em cada um dos nós. Estas configurações são armazenadas no arquivo de configuração do MySQL chamado my.cnf. Não devemos nos esquecer de parar o serviço do MySQL antes de alterar o arquivo my.cnf. No exemplo este arquivo estava localizado no diretório /etc/mysql, porém esta localização pode variar de acordo com a instalação do MySQL.

Para configurar um nó de modo que ele faça parte de um cluster MySQL é preciso alterar três chaves em duas sessões do arquivo my.cnf. As duas primeiras chaves são a ndbcluster e a ndb-connectstring, sendo que esta última deve receber o endereço 192.168.1.15, que é o servidor onde o serviço de administração do cluster está instalado. Por padrão, estas chaves estão comentadas com o símbolo cerquilha (#) e estão dentro da sessão [MYSQLD]. Basta retirar os comentários e colocar o valor o endereço IP 192.168.1.15, como mostrado na parte esquerda da Figura 4 e destacada pelo retângulo vermelho.

Também é preciso alterar a chave ndb-connectionstring da sessão [MYSQL_CLUSTER], que também está comentada por padrão e se encontra abaixo da sessão [MYSQLD] no arquivo my.cnf. Da mesma forma que a chave anterior, é preciso colocar o endereço do servidor que contém o serviço de administração do cluster na chave ndb-connectionstring da sessão [MYSQLD]. Esta chave é mostrada à direita na Figura 4 e destacada pelo retângulo preto.

Figura 4. Chaves que devem ser modificadas no arquivo my.cnf

Após a modificação das chaves no arquivo my.cnf é preciso iniciar o serviço do MySQL. No exemplo iniciei o serviço utilizando o comando mysqld_safe -user=mysql &. Além disso também é preciso iniciar o serviço ndbd nos nós do cluster, pois ele é o responsável por gerenciar o acesso aos arquivos com os dados compartilhados. Os comandos que iniciam os serviços mysql e ndbd são mostrados na Figura 5.

Figura 5. Iniciando os serviços MySQL e ndbd em um dos nós do cluster

Nota importante:

é preciso repetir os passos anteriores para cada nó do cluster. Ou seja, tanto para o servidor 192.168.1.25 como para o servidor 192.168.1.35 é preciso alterar o arquivo de configuração my.cnf e iniciar os serviços MySQL e ndbd.

A partir deste momento o cluster já está sendo executado. Podemos enviar o comando SHOW na interface console do Management Client do cluster e verificar que os dois nós já são considerados parte do cluster, como mostra a Figura 6.

Figura 6. Verificando os nós do cluster.

Apesar de o cluster já estar configurado, a partir desde momento os dois servidores MySQL ainda estão trabalhando de forma independente. Para que possamos usufruir das funcionalidades do cluster é preciso criar manualmente um banco de dados com o mesmo nome em cada servidor e, dentro deste banco de dados, criar tabelas que utilizem o engine de banco de dados NDBCLUSTER. Mas atenção: o banco de dados deve ser criado manualmente nos dois nós com o comando CREATE DATABASE, porém as tabelas precisam ser criadas apenas uma vez em qualquer um dos nós do cluster. A Figura 7 mostra a criação do banco de dados chamado CLUSTER e da tabela TB_ONE em um dos nós do cluster e utilizando os comandos CREATE DATABASE e CREATE TABLE, respectivamente.

Figura 7. Criando o banco de dados CLUSTER e a tabela TB_ONE.

Como a tabela TB_ONE foi criada utilizando o engine de banco de dados NDBCLUSTER todas as modificações nos dados realizadas em qualquer um dos nós será replicada automaticamente para os demais. Podemos fazer um teste simples incluindo uma linha na tabela TB_ONE em um dos nós e verificar que esta linha foi automaticamente enviada para a tabela TB_ONE do outro nó.

Com o cluster conseguimos montar uma solução que atende a requisitos de alta disponibilidade, pois caso um nó do cluster não esteja operacional isso não será um problema para a aplicação, uma vez que os outros nós funcionaram de forma independente. Quando o nó que apresentou um problema foi iniciado novamente o próprio serviço NDBD irá procurar as informações perdidas e tentará sincronizar os dados da tabela.

Um detalhe importante de ser lembrando é que com o cluster os usuários podem se conectar tanto no servidor 192.168.1.25 (ubuntu02) como no servidor 192.168.1.35 (ubuntu03). Mas se eles tentarem se conectar ao servidor que possui as ferramentas administrativas, cujo endereço é 192.168.1.5 (ubuntu01), eles não conseguiram se conectar. Por isso é recomendável utilizar o serviço MySQLProxy, explicado anteriormente aqui, de modo que as aplicações possam se conectar em apenas um servidor que conterá tanto o software de balanceamento de carga como as ferramentas administrativas do cluster. Este é o cenário descrito na primeira parte do artigo, onde sugiro colocar o MySQL Proxy e as ferramentas administrativas do cluster no servidor 192.168.1.5 para montar uma solução completa de balanceamento de carga, tolerância a falhas e replicação dos dados por meio do cluster.

Com isso terminamos a segunda parte do artigo que explica como montar um cluster no MySQL. Nas próximas colunas veremos passo a passo como configurar o serviço de replicação do MySQL.

Fonte: Imasters

O MySQL possui recursos para implementar o cluster nativamente, ou seja, não é preciso instalar nenhum software adicional, além da versão do MySQL já preparada para receber o cluster. O nome utilizado para identificar o componente do MySQL que permite a criação de clusters é NDBCluster e funciona como um engine do banco de dados. Neste artigo utilizarei o MySQL versão 5.0.51 sendo executado em servidores Linux com a distribuição Ubuntu 8.04 (Hard Heron).

O conceito de engine pode confundir alguns usuários que estão acostumados com o SQL Server ou mesmo o Oracle, pois estes produtos não permitem que o usuário escolha o engine do banco de dados. A idéia é que cada engine proporcione características próprias que tragam algum benefício. Por exemplo, no MySQL temos um engine que permite a utilização de transações. Para criar o cluster é preciso indicar que as tabelas que apresentaram a replicação automática utilizam o engine NDBCLUSTER. Notem que não é preciso nenhum hardware específico para a criação de um cluster MySQL.

O cluster do MySQL age de forma transparente, ou seja, a aplicação cliente não precisa saber que o cluster do MySQL está sendo utilizado. Esta característica facilita a utilização desta ferramenta e expande o leque de possibilidades tanto para o desenvolvedor como para quem administra o MySQL. Do ponto de vista de desenvolvimento, não há nenhuma mudança significativa: basta apenas continuar conectando em um endereço IP normalmente. Já para quem administra é preciso cuidados especiais, pois algumas configurações não são replicadas pelo cluster. Por exemplo, os logins e as permissões devem ser configuras nos servidores de forma independente.

É possível utilizar o cluster do MySQL em conjunto com o MySQL Proxy, apresentado em uma coluna anterior aqui no iMasters. Como o cluster apenas replica as instruções para todos os nós ele não distribui a carga entre os servidores. A utilização do MySQL Proxy com o cluster fornece a consistência ao ambiente, pois desta maneira o cluster garante que as bases de dados ficaram iguais. Já o MySQL Proxy permite dividir a carga entre os servidores de acordo com alguma regra específica. Porém cabe aqui dizer que o MySQL Proxy possui recursos para programar como será feita a distribuição de carga por meio da programação na linguagem LUA.

Os principais componentes de um cluster MySQL são os nós, ou seja, servidores MySQL já instalados. Também é preciso dispor de um servidor que receberá o serviço de administração do cluster. Este servidor que administrará o cluster não requer um MySQL instalado, pois apenas os arquivos binários do servidor NDBCluster precisam ser executados. É possível realizar a manutenção e checar o status do cluster conectando-se ao servidor NDBCluster, remotamente ou não.

Para entender o exemplo que será apresentado vamos observar o diagrama da Figura 1, que traz um cenário onde um sistema qualquer é utilizado por vários usuários. Neste cenário os clientes utilizam a aplicação normalmente se conectando no servidor Linux chamado ubuntu02 cujo endereço I.P é 192.168.1.25. Este cenário não contém nenhum tipo de replicação, balanceamento de carga ou tolerância a falhas. Caso aconteça alguma indisponibilidade do banco de dados do servidor ubuntu02 o uso da aplicação ficará comprometido.

Figura 1. Ambiente sem balanceamento de carga, replicação e tolerância a falhas.

A partir do ambiente apresentado na Figura 1 vamos montar um cluster com três servidores: um que conterá as ferramentas de administração do cluster e dois servidores MySQL com o mesmo banco de dados que está sendo utilizado pela aplicação. Notem que poderíamos utilizar mais de dois servidores de bancos de dados de acordo com a necessidade. A idéia aqui é que o servidor que conterá as ferramentas administrativas do cluster replique as instruções enviando igualmente os dados entre os dois servidores de bancos de dados de forma simultânea. Desta maneira o cenário contará com a tolerância a falhas, pois se um servidor não estiver disponível o cluster permite que a aplicação ainda continue sendo utilizada, uma vez que um servidor ainda está disponível. A Figura 2 apresenta o cenário com a configuração do cluster.

Figura 2. Ambiente com um cluster MySQL composto de dois nós.

Do ponto de vista da aplicação a única mudança que deve ser feita é a mudança da conexão com o banco de dados: antes a conexão era feita diretamente para o servidor 192.168.1.25 e agora a conexão será para o servidor 192.168.1.15. Novamente, o cluster não requer que o MySQL seja instalado no servidor na qual as aplicações vão se conectar, ou seja, o servidor 192.168.1.15 não precisar ter o MySQL instalado. É preciso apenas contar com os arquivos binários que compõem o serviço do cluster. Estes arquivos binários são encontrados junto com os arquivos de instalação do MySQL.

O funcionamento do cluster evita a falta de sincronia entre os dois servidores. Por exemplo, se um usuário A se conectar ao cluster e fizer uma instrução UPDATE nos dados de uma tabela este UPDATE será automaticamente enviado para os servidores 192.168.1.25 e 192.168.1.35, deixando os bancos de dados em sincronia. Caso algum dos servidores não possa executar a instrução UPDATE por algum motivo um erro é gerado e automaticamente a instrução é cancelada nos dois servidores.

Outra questão a ser considerada é o ponto de falha representado pelo servidor ubuntu01. Se ele ficar off-line a aplicação não poderá se conectar a nenhum dos bancos de dados. Para isso existe como configurar a tolerância de falha para o serviço de cluster em outro servidor de modo que ele detecte esta falha. Porém no exemplo não apresentarei como fazer isso, pois se trata de um tópico mais avançado.

Existem várias formas de se trabalhar com tolerância a falhas nos servidores Linux. Para quem desejar se aprofundar recomendo soluções que envolvem a configuração de endereços I.P virtuais diretamente no kernel. Apenas para referência, uma dessas aplicações que fazem a criação de endereços I.P. virtuais no Linux é o Ultra Monkey com os módulos do kernal IPVS. Outra alternativa mais fácil de se configurar é o pacote do HeartBet + PerlBal

Com isso terminamos a primeira parte do artigo que explicará como montar um cluster no MySQL. Na próxima coluna veremos passo a passo como configurar o MySQL e o serviço de cluster, além da criação do banco de dados e do teste de instruções.

Referência: HOWTO set up a MySQL Cluster for two servers (three servers required for true redundancy):

http://dev.mysql.com/tech-resources/articles/mysql-cluster-for-two-servers.html

Fonte: Imasters

MySQL Administrator

Console de administração gráfica para banco de dados MySQL
Integre as tarefas de gestão de banco de addos MySQL com as de manutenção através de uma interface de trabalho mais visual e intuitiva chamada MySQL Administrator, o administrador oficial de banco de dados MySQL.
As operações em linha de comando se executam em um entorno gráfico que ameniza as tarefas de configuração de servidores, administração de usuário e monitorização de bancos de dados MySQL, junto a tarefas de comprovação de um bom estado da replicação, backup e restauração, visualização de logs…
Possui uma interface bastante funcional, facilitando o acesso a todas as opções, como autenticação de usuários, criação de cópias de segurança, otimização através de toda uma série de parâmetros ajustáveis e facilmente acessíveis.
Tudo isso em uma interface mais segura que reduz a possibilidade de haver erros de manobras.

MySQL Query Browser

O MySQL Query Browser é uma ferramenta gráfica fornecida pela MySQL AB para criar, executar e otimizar solicitações SQL em um ambiente gráfico. Assim como o MySQL Administrator foi criado para administrar um servidor MySQL, o MySQL Query Browser foi criado para auxiliar você a selecionar e analisar dados armazenados dentro de um Banco de Dados MySQL.
Enquanto todas as solicitações executadas no MySQL Query Browser também podem ser executadas pela linha de comando utilizando-se o utilitário mysql, o MySQL Query Browser permite a execução e edição dos dados de maneira gráfica, que é mais intuitiva para o usuário.
MySQL Query Browser foi projetado para trabalhar com versões 4.0 ou superiores do servidor MySQL.

MySQL Migration Toolkit

O conversor da base de dados é uma ferramenta poderosa que faça a conversão do usuário do MS SQL a MySQL fácil e de confiança. Você pode mesmo converter sua base de dados grande que contem milhares dos registros em uma matéria de alguns segundos mesmo se sua base de dados funde tabelas múltiplas ou fileiras. O software do conversor da base de dados é inteiramente capaz converter fàcilmente e eficientemente a base de dados inteira ou registros selecionados dos table`s. MSSql ao migrator da base de dados de MySql suporta todos os tipos de dados de usuário do MS SQL e de arquitetura de Unicode. Dependendo dos privilégios no usuário de MySQL do alvo você pode exportar dados de Microsoft SQL na base de dados nova ou overwrite os índices de uma base de dados existente. A ferramenta do conversor de MySQL suporta todos os tipos de dados, chave preliminar dos atributos, chave original e chave extrangeira.

Download aqui

Já que criamos nossa base e compreendemos um pouco mais sobre o MySQL, vamos criar algumas tabelas:

Carregue a base:

mysql> USE minha_base;

Vamos criar uma tabela com os campos NOME, EMAIL, DATA:

mysql> create table tabela1 (nome VARCHAR(20), email VARCHAR(20), data DATE);

Vejamos se a mesma foi criada:

mysql> SHOW TABLES;

+-------------------------------+
| Tables_in_minha_base  |
+-------------------------------+
| tabela1                              |
+-------------------------------+

E vejamos os campos que ela possui:

mysql> DESC tabela1;

+-------+----------------+------+-----+---------+-------+
| Field  | Type               | Null  | Key | Default | Extra |
+-------+----------------+------+-----+---------+-------+
| nome | varchar(20) | YES  |         | NULL    |          |
| email | varchar(20) | YES  |         | NULL    |           |
| data   | date              | YES  |         | NULL    |           |
+-------+----------------+------+-----+---------+-------+

E vamos inserir dados nessa tabela:

mysql>  INSERT INTO tabela1 VALUES ('Marcos Miras' , 'marcosmiras@atmsystem.com.br' , '2008-09-19');
mysql> SELECT * FROM tabela1;

+-----------------+-------------------------------------+---------------+
| nome               | email                                       | data              |
+-----------------+-------------------------------------+----------------+
| Marcos Miras | marcosmiras@atmsyste     | 2008-09-19 |
+-----------------+-------------------------------------+----------------+

Vamos atualizar esse valor do campo “email”:

mysql> UPDATE tabela1 SET email='marcos@atmsystem.com';
mysql> SELECT * FROM tabela1;

+-----------------+------------------------------------+----------------+
| nome               | email                                       | data             |
+-----------------+------------------------------------+----------------+
| Marcos Miras | marcos@atmsystem.com | 2008-09-19 |
+-----------------+------------------------------------+----------------+

Excluindo a entrada de registro:

mysql> DELETE FROM tabela1;
mysql> SELECT * FROM tabela1;
Empty set (0.00 sec)

Porém, percebe-se que o comando insert atualiza o campo determinado de todos os registros da tabela e o comando “delete” exclui todos os dados da tabela, para resolver esse problema conheceremos a cláusula “where”. Para testar vamos fazer várias inserções na tabela:

mysql> INSERT INTO tabela1 VALUES ('Joao Silva' , 'joao@dominio' , '2008-09-19');
mysql> INSERT INTO tabela1 VALUES ('Jose Pereira' , 'ze@dominio' , '2008-09-19');
mysql> INSERT INTO tabela1 VALUES ('Maria' , 'maria@dominio' , '2008-09-19');
mysql> INSERT INTO tabela1 VALUES ('Pedro' , 'pedro@dominio' , '2008-09-19');
mysql> SELECT * FROM tabela1;

+---------------+----------------------+----------------+
| nome            | email                    | data              |
+---------------+----------------------+----------------+
| Joao Silva    | joao@dominio    | 2008-09-19 |
| Jose Pereira | ze@dominio        | 2008-09-19  |
| Maria            | maria@dominio | 2008-09-19 |
| Pedro            | pedro@dominio  | 2008-09-19 |
+---------------+----------------------+----------------+

Utilizando o “where” vamos selecionar os registros da tabela1 que contenham “Pedro”:

mysql> SELECT * FROM tabela1 WHERE nome="Pedro";

+--------+----------------------+----------------+
| nome  | email                     | data             |
+--------+----------------------+----------------+
| Pedro   | pedro@dominio | 2008-09-19 |
+--------+----------------------+----------------+

Sendo assim podemos excluir e atualizar os dados que queremos:

mysql> UPDATE tabela1 SET email='pd@dominio2' where nome="Pedro";
mysql> UPDATE tabela1 SET nome='Maria Souza' where nome='Maria';
mysql> DELETE FROM tabela1 where nome='Joao Silva';

Verifique suas alterações com o “select”.

O “delete” exclui os dados da tabela, agora se você deseja excluir a tabela você pode usar o “drop”, assim como na exclusão do base (vista na página anterior).

mysql> DROP TABLE tabela1;

Os bloqueios se fazem importantes a partir do momento em que se pretende trabalhar de forma isolada com algumas tabelas dos bancos de dados para que não haja nenhum interferência em uma determinada manipulação, evitando concorrências, seja através do mysql client, conforme mostraremos aqui, seja em meio a operações de uma aplicação que utiliza o MySQL como back-end.

Após ler este artigo, você estará apto a:

• Conceituar os bloqueios ou LOCKing;
• Tipos de bloqueios ou LOCKing;
• Utilizar bloqueios explícitos;

Conceitos de Locking ou Bloqueio em Tabelas

O servidor de bancos de dados MySQL utiliza sua arquitetura multi-threaded para garantir conexões com ele a todos os usuários simultaneamente. Para cada cliente que se conecta ao servidor de bancos de dados MySQL, este alocará uma thread como um controlador. Caso um usuário, conectado através de um cliente qualquer, acessa várias tabelas ao mesmo tempo que outros usuários, provenientes de outros clientes, uma conexão não interfere na outra, ou seja, cada conexão tem a sua vez de leitura ou escrita em uma mesma tabela.

Nesse acesso simultâneo, alguns problemas podem acontecer quando dois clientes têm usuários manipulando o mesmo dado. Para o primeiro cliente, um bloqueio é adquirido para que este, ao terminar de fazer suas manipulações nos dados, tenha seu bloqueio cancelado, passando a vez para uma outra manipulação nos mesmos dados. Em outras palavras, os bloqueios serializam os acessos ao mesmo dado. Enquanto uma dada operação A adquire um LOCK em uma tabela X, para que B manipule dados nessa mesma tabela, terá que esperar, dependendo do tipo de LOCK adquirido por A na tabela X e, também, de qual operação B fará sobre a tabela X.

Note que alguns conflitos são percebidos em situações em que dois comandos ou grupo manipulem a mesma linha ao mesmo tempo. Para garantir que não haja conflitos, podemos enviar ao SGBD um pedido de bloqueios em tabelas, tanto um bloqueio de leitura quanto um bloqueio de escrita.

Tipos Bloqueios ou LOCKing

Bloqueios sobre dados podem ser adquiridos de maneira implícita, explícita ou com advisory locks:

Para clientes que trabalham com configurações do modo autocommit habilitado (padrão do MySQL), o servidor MySQL adquire bloqueios implicitamente para cada comando que chega ao servidor e cancela o bloqueio logo que este finaliza. Por exemplo, o servidor MySQL adquire um LOCK de leitura para um comando SELECT e um LOCK de escrita para o comando INSERT. Após finalizadas as operações, o LOCK é desfeito com um UNLOCK TABLES interno;

Caso um bloqueio implícito seja insuficiente, podemos bloquear as tabelas através do comando LOCK TABLES e soltar esse bloqueio através do comando UNLOCK TABLES, de maneira explícita. Bloqueios explícitos normalmente são adquiridos quando se deseja trabalhar com múltiplos comandos sem interferência de outras operações de outros clientes conectados no mesmo banco de dados. Um exemplo é quando precisamos trabalhar vários comandos utilizando a função LAST_INSERT_ID(), caso não travemos novas inserções na tabela que originou o valor retornado pela função LAST_INSERT_ID(), pode ser que no meio das operações com o banco dados, LAST_INSERT_ID() tenha outro valor, pois uma nova inserção concorrente poderá acontecer;

Outro tipo de bloqueio é o bloqueio denominado Advisory Locking. Diferentemente dos bloqueios implícitos e explícitos, Advisory Locks não são gerenciados pelo servidor MySQL, os próprios clientes gerenciam os bloqueios usando um conjunto de funções que eles próprios podem utilizar.

Utilizando Bloqueios Explícitos

Clientes gerenciam explicitamente o bloqueio de tabelas com duas declarações: LOCK TABLES para adquirir bloqueio em uma ou mais tabelas e UNLOCK TABLES para cancelar os mesmos. A declaração LOCK TABLES fornece os nomes das tabelas que desejamos efetuar o bloqueio e também o tipo de bloqueio que precisamos que seja efetuado.

Utilizando o banco de dados world (disponível em http://downloads.mysql.com/docs/world.sql.zip) para nossos exemplos práticos, abaixo utilizamos LOCK TABLES para adquirir dois bloqueios ao mesmo tempo, o primeiro de leitura – READ – na tabela Country e outro de escrita – WRITE – para a tabela City.

mysql> LOCK TABLES Country READ, City WRITE;
Query OK, 0 rows affected (0.39 sec)

Caso as tabelas de uma declaração LOCK TABLES estejam em uso exatamente no momento em que um bloqueio explícito é solicitado, tal pedido aguardará até que possa adquiri-lo. Podemos ver no teste feito na Figura 01 que, caso um usuário B solicite um bloqueio em uma tabela já bloqueada por outro usuário A, em conexões simultâneas, esta solicitação aguardará até que o bloqueio A seja cancelado, liberando a tabela.

Demonstração de bloqueio para a tabela City:

Perceba na imagem acima que quando o usuário B se conecta ao servidor MySQL e solicita um bloqueio de escrita – WRITE – o prompt fica aguardando até que A libere seu bloqueio na tabela para que B adquira o seu bloqueio.

Um bloquieio do tipo WRITE é também conhecido como bloqueio exclusivo, ou seja, se uma determinada conexão bloquear uma tabela com essa opção, nenhuma outra conexão poderá ler e escrever nesta tabela, enquanto que um bloqueio READ é um bloqueio adquirido em uma tabela de forma compartilhada, ou seja, outras conexões somente poderão ler a tabela, não escrever.

Para que você utilize a declaração LOCK TABLES para adquirir bloqueios em tabelas de um banco de dados no servidor de bancos de dados MySQL, é necessário que o seu usuário tenha privilégios LOCK TABLES e SELECT para cada tabela que se deseja adquirir o bloqueio.

No próximo artigo trabalharemos um estudo de caso em parceria com a linguagem PHP para ilustrarmos um exemplo com LOCK TABLES. Tenho recebido muitos e-mails solicitando exemplos com TRIGGERS, recurso que é muito útil em várias situações e também publicarei um estudo de caso, aplicando tal recurso.