Debugando.com » Banco de Dados

Rússia aprova fusão da Oracle a Sun, mas com ressalvas

Lincoln César — Fri, 19 Mar 2010 22:43:11 +0000

Comissão Europeia já havia aprovado fusão anteriormente.
Oracle prometeu continuar desenvolvendo MySQL; criador duvida.

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

Operações básica de acesso a dados

Lincoln César — Tue, 23 Feb 2010 20:19:24 +0000

Como realizar as operações básicas de acesso e manutenção de dados com C#? Tarefas simples como inserir, atualizar e excluir dados usando a ADO.NET e C# são mais simples do que você pode pensar. Abaixo um resumo básico destas operações com C#:

As operações serão feitas na tabela Clientes do banco de dados Access teste.mdb presente na pasta c:\teste. A seguir o código relacionado a cada operação:

1- Inserindo dados em uma base de dados Access.

// definir a string de conexão
string sDBstr = “Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\test.mdb”;

//definir a string SQL
string sSQL = “SELECT * from Name”;

//criar o objeto connection
OleDbConnection oCn = new OleDbConnection(sDBstr); //abrir a conexão
oCn.Open();

//criar o data adapter e executar a consulta
OleDbDataAdapter oDA = new OleDbDataAdapter(sSQL,oCn);

//criar o DataSet
DataSet oDs = new DataSet();

//Preencher o dataset coom o data adapter
oDA.Fill(oDs,”Name”);

//criar um objeto Data Row
DataRow oDR = oDs.Tables["Name"].NewRow();

//Preencher o datarow com valores
oDR["Name"] = “Yateen”

oDR["Id"] = “10″;

//Incluir um datarow ao dataset
oDs.Tables["Name"].Rows.Add(oDR);

//Usar o objeto Command Bulder para gerar o Comandop Insert
OleDbCommandBuilder oCB = new OleDbCommandBuilder(oDA);

//Atualizar o BD com valores do Dataset
oDA.Update(oDs,”Name”);

//liberar o data adapter , o dataset , o comandbuilder e a conexao
oDA.Dispose();

oDs.Dispose();

oCB.Dispose();

oCn.Dispose();

2- Atualizar dados em uma base de dados Access.

// definir a string de conexão
string sDBstr = “Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\test.mdb”;

//definir a string SQL
string sSQL = “SELECT * from Name”;

//criar o objeto connection
OleDbConnection oCn = new OleDbConnection(sDBstr); //abrir a conexão
oCn.Open();

//criar o data adapter e executar a consulta
OleDbDataAdapter oDA = new OleDbDataAdapter(sSQL,oCn);

//criar o DataSet
DataSet oDs = new DataSet();

//Preencher o dataset coom o data adapter
oDA.Fill(oDs,”Name”);

//cria o DataSet atribuindo ao DataRow o valor da linha que desejamos atualizar
DataRow oDR = oDs.Tables["Name"] .Rows[3];

//Preenche o datarow with valores
oDR["Name"] = “Macoratti”

//Usar o objeto Command Bulder para gerar o Comando Update
OleDbCommandBuilder oCB = new OleDbCommandBuilder(oDA);

//Atualizar o BD com valores do Dataset
oDA.Update(oDs,”Name”);

//liberar o data adapter , o dataset , o comandbuilder e a conexao
oDA.Dispose();

oDs.Dispose();

oCB.Dispose();

oCn.Dispose();

3- Excluir dados de uma base de dados Access.

// definir a string de conexão
string sDBstr = “Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\test.mdb”;

//definir a string SQL
string sSQL = “SELECT * from Name”;

//criar o objeto connection
OleDbConnection oCn = new OleDbConnection(sDBstr); //abrir a conexão
oCn.Open();

//criar o data adapter e executar a consulta
OleDbDataAdapter oDA = new OleDbDataAdapter(sSQL,oCn);

//criar o DataSet
DataSet oDs = new DataSet();

//Preencher o dataset coom o data adapter
oDA.Fill(oDs,”Name”);

//Exclui a linha desejada
oDs.Tables["Name"].Rows[3].Delete();

/Usar o objeto Command Bulder para gerar o Comandop Delete
OleDbCommandBuilder oCB = new OleDbCommandBuilder(oDA);

//Atualizar o BD com valores do Dataset
oDA.Update(oDs,”Name”);

//liberar o data adapter , o dataset , o comandbuilder e a conexao
oDA.Dispose();

oDs.Dispose();

oCB.Dispose();

oCn.Dispose();

Sao operaçoes simples, mais muito valiosas!

Fonte: Macoratti.NET

Dica: Migrando MySQL para PostgreSQL

Lincoln César — Sat, 30 Jan 2010 12:08:32 +0000

Migrando MySQL para PostgreSQL

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

Colocando para funcionar: importando para o PostgreSQL

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

Com isso você migrou sua estrutura de Dados de MySQL para PostgreSQL.

Fonte: iMasters

Oracle acalma clientes da Sun, mas descontinua Projeto Kenai

Lincoln César — Thu, 28 Jan 2010 15:28:25 +0000

Segundo o presidente da Oracle, Charles Phillips, a compra da Sun pela Oracle, que foi concluída esta semana e cujo valor foi de US$ 7,4 bilhões, não deve preocupar os clientes da companhia adquirida.

Em evento transmitido ontem para a imprensa mundial via webcast, o executivo afirmou que não haverá demissões em massa, nem perda de produtos em uso, e sim um upgrade das soluções e serviços.

O CEO da Oracle, Larry Ellison, disse ao Wall Street Journal que a ideia da empresa é contratar, nos próximos meses, mais dois mil funcionários, nos setores de vendas e engenharia.

O porém fica por conta do Projeto Kenai, que, de acordo com a Oracle, será descontinuado. Em um FAQ voltado à aquisição da Sun, a Oracle afirmou que continuará utilizando o projeto apenas internamente e vai buscar meios para que seus clientes possam tirar algum proveito disso. O cronograma para que usuários retirem dados e projetos do Kenai será disponibilizado no site do projeto.

Com a tecnologia da Sun, a Oracle lança o Exadata Database Machine 2, uma solução de hardware e software capaz de processar em até dez vezes menos tempo do que os equipamentos tradicionais. O objetivo da Oracle é concorrer em pé de igualdade com concorrentes como IBM e EMC.

Fonte: iMasters

Os maiores bancos de dados do mundo

Lincoln César — Tue, 19 Jan 2010 21:09:32 +0000

Quem trabalha com banco de dados ja deve ter tido a curiosidade de saber qual o maior banco de dados do mundo, para ter noção do tamanho, da grandeza da administração e do tempo que deve executar uma instrução SQL, rebuild de índice e tudo mais.

Entao, achei alguns materiais na internet que falam justamente desses bancos de dados, que podem ser de diferentes fabricantes, tanto Oracle, IBM, Microsoft, PostGreSQL e etc. O mais interessante são os números ou métricas que chegaram nessas conclusões e relatam um pouco da infra-estrutura utilizada para cada ambiente de banco de dados.

È importante também é saber que esses artigos e documentos não são de fontes oficiais das empresas ou de alguma organização responsável e séria sobre esse específico tipo de assunto. Como hoje em dia temos o TPC.ORG, que corresponde aos benchmarks sobre Performance vs Custo, esses documentos são meramente para matarmos algumas curiosidades, mas nada confirmado pelas empresas ou estabelecimentos que utilizam esses bancos de dados.

O documento que está abaixo relata o TOP 10 dos maiores bancos de dados do Mundo, e o mais interessante do documento são os números que os tornam gigantescos. O documento pode ser lido aqui: Top Largest Databases in the World We all collected

Porém, se continuar navegando um pouco mais na internet, irá se deparar com um artigo da ComputerWorld falando que o maior banco de dados do mundo é do Yahoo!, que possui um banco de dados na casa dos 2 PB (PetaBytes). Veja:

Yahoo! The database 2 PetaBytes.

Mas, como é um artigo do ano de 2008, talvez esses números já estejam bem maiores. E sou da opinião que devem existir bancos de dados bem maiores dos que os divulgados e analisados. Um exemplo para ampliar a curiosidade são as bases de dados de organizações como:

* Organizações que cuidam do clima (Cálculos e Imagens);
* Empresas que trabalham com tecnologia GIS (Mapeamento – GPS);
* Empresas de Media Center.

E por último o DETRAN-SP, se o estado tem a terceira maior frota de automóveis do mundo e a cidade tem radar para tudo que é lado, imagina a quantidade de transações diárias (com imagem da placa do seu carro) que é gerada por hora para cada multa? Fico curioso para saber o tamanho dessa base.

Fonte: iMasters

Uma solução para problemas de charset com Oracle e Rails

admin — Sat, 16 Jan 2010 16:08:34 +0000

Ontem comentei o meu problema com charset entre Oracle e uma aplicação web que estou fazendo. O problema era o seguinte: ao preencher campos de texto de um formulário com caracteres acentuados, os mesmos eram inseridos como se fossem dois caracteres de interrogação (??).

Essa aplicação tem como pré-requisito o uso de UTF-8, pois é feita com o framework Ruby on Rails. Minhas buscas pelo Google tinham me colocado apenas em uma direção: modificar o charset do banco de dados a partir de um penoso procedimento de backup/restore. Mas, conversando com o meu colega de trabalho Luiz (que não tem blog, infelizmente) descobri que ele já havia tido o mesmo problema antes e a solução, aparentemente, era bem mais simples (e mágica).

O Rails interage com o Oracle por intermédio da biblioteca Ruby oci8. A solução mágica consiste em definir a variável de ambiente NLS_LANG com o valor BRAZILIAN PORTUGUESE_BRAZIL.UTF8 antes que o código da biblioteca seja carregado. Mais informações oficiais sobre a variável aqui e aqui.

De acordo com a documentação oficial, essa variável não especifica apenas 1, mas 3 valores: LINGUAGEM_TERRITÓRIO.CHARSET. No meu caso, portanto, foram especificados:

LINGUAGEM: BRAZILIAN PORTUGUESE
TERRITÓRIO: BRAZIL
CHARSET: UTF8

Note que, para a minha aplicação web, apenas o CHARSET é relevante. Até onde li na documentação, LINGUAGEM e TERRITÓRIO servem mais para indicar ao Oracle como ele deve exibir mensagens de erro ou formatar datas para apresentação. CHARSET parece indicar ao Oracle que faça uma conversão entre o charset real do banco de dados e o valor do charset especificado em NLS_LANG no momento da leitura de dados. Portanto, os dados continuam sendo armazenados com o charset original, mas quando o Rails solicita esses dados a partir da biblioteca oci8, o Oracle os converte para UTF-8 (neste caso) e depois os entrega. Essa parece ser uma boa explicação para o correto funcionamento da aplicação após a definição dessa variável, mas o problema que relato ao fim do artigo mostra que, na prática, a teoria é outra.

Testei duas maneiras de definir essa variável. A primeira é colocar a seguinte linha no arquivo ~/.bashrc do usuário no qual o servidor de aplicação roda:

export NLS_LANG='BRAZILIAN PORTUGUESE_BRAZIL.UTF8'

Mas acho mais interessante embutir essa declaração dentro do próprio código da aplicação. Não sei qual o local mais apropriado para isso, mas inserir esta linha no início do arquivo config/environment.rb funcionou:

ENV['NLS_LANG']='BRAZILIAN PORTUGUESE_BRAZIL.UTF8'

Essa solução resolveu o problema completamente? Não. Para textos inseridos a partir da aplicação web, caracteres acentuados são gravados no banco de dados e lidos da forma correta (não são substituídos por um ou dois sinais de interrogação). Mas essa solução estava simples demais para ser verdade, certo?

Como estou desenvolvendo a aplicação web sobre um banco de dados já existente, e que já possui dados, rodei o servidor de aplicação em modo de produção para ver se os dados já existentes eram apresentados corretamente também. Resultado: problemas de acentuação novamente. Os caracteres acentuados lidos do banco de dados são trocados por pontos de interrogação.

Conectando C# ao MySQL

admin — Wed, 29 Jul 2009 20:42:52 +0000

Quem está habituado a programar C# normalmente utiliza SQL Server como banco de dados, uma vez que ela está integrada no Visual Studio e, por isso mesmo, existe grande facilidade em trabalhar com as duas ferramentas.

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

Liferay Portal – Configuração da ligação a uma base de dados MySQL

admin — Tue, 14 Apr 2009 21:36:30 +0000

1. Criação da Base de Dados MySQL

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

Cluster no MySQL – Parte 2

admin — Wed, 01 Apr 2009 14:14:03 +0000

Antes de entrar nos detalhes técnicos, recomendo a todos que estiverem lendo esta coluna que confiram a primeira parte da configuração do cluster, onde mostro qual é a arquitetura da solução e discuto alguns aspectos de um cluster MySQL. A primeira parte pode ser encontrada aqui.

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

Cluster no MySQL – Parte 01

admin — Wed, 01 Apr 2009 14:11:37 +0000

A necessidade de se montar um cluster no MySQL está relacionada à alta disponibilidade das informações e à tolerância a falhas. Com dois ou mais servidores MySQL sendo executados em cluster os dados são automaticamente replicados entre os servidores e cada nó que pertence ao cluster pode ser removido sem afetar a disponibilidade da aplicação.

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