A primeira opção é a escolha típica numa aplicação stand-alone, mas a opção de utilizar uma datasource JNDI é a que faz mais sentido para application servers. Portanto, o ficheiro de configuração do Hibernate há-de ter, parcialmente, este aspecto:

<hibernate-configuration>
<session-factory>
<property name="hibernate.connection.datasource">
java:my_app_name
</property>
<property name="hibernate.setup">true</property>
<property name="hibernate.dialect">
org.hibernate.dialect.MySQLInnoDBDialect
</property>
<property name="transaction.factory_class">
org.hibernate.transaction.JDBCTransactionFactory
</property>
<property name="current_session_context_class">
thread
</property>
</session-factory>
</hibernate-configuration>

Depois basta definir a datasource com o nome JNDI correspondente, por exemplo assim:

<datasources>
<local-tx-datasource>
<jndi-name>my_app_name</jndi-name>
<connection-url>jdbc:mysql://host_or_ip/db_name</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
<user-name>username</user-name>
<password>password</password>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</local-tx-datasource>
</datasources>

Agora que está tudo montado como manda a documentação, sugiro uma experiência:

1. Ligar servidor BD.
2. Ligar application server.
3. Testar aplicação que se liga à base de dados (funciona)
4. Reiniciar servidor BD (ou esperar 8 horas).
5. Testar aplicação que se liga à base de dados (não funciona!)

Então… tanto trabalho para abstrair a ligação a base de dados e um simples restart da base de dados deixa as ligações geridas pelo Hibernate todas inválidas? E, pior, não há recuperação automática?

Pois… parece que não. E acrescentar o parâmetro autoReconnect=true ao URL JDBC também não resolve, aliás, a utilização desse parâmetro até é desaconselhada, como se pode ver pelo que diz no manual:

Should the driver try to re-establish stale and/or dead connections? If enabled the driver will throw an exception for a queries issued on a stale or dead connection, which belong to the current transaction, but will attempt reconnect before the next query issued on the connection in a new transaction. The use of this feature is not recommended, because it has side effects related to session state and data consistency when applications don’t handle SQLExceptions properly, and is only designed to be used when you are unable to configure your application to handle SQLExceptions resulting from dead and stale connections properly. — MySQL 5.0 Reference Manual

A solução que encontrei para MySQL (e que também funciona para MS SQL Server), é acrescentar a seguinte linha ao ficheiro de configuração da datasource:

<check-valid-connection-sql>SELECT 1</check-valid-connection-sql>

Esta opção faz mesmo aquilo que parece fazer, ou seja, antes de usar uma ligação, a query ali especificada é executada como forma de verificar se a ligação é usável. Se não ocorrer nenhum erro, a instrução SQL que realmente se pretende executar é enviada pela mesma ligação, se houver um erro, a ligação é descartada e é criada uma nova.

Claro que isto tem um impacto sério na performance uma vez que se está a duplicar o número de queries, o que pode ser particularmente grave se o acesso à base de dados for feito através de um canal de elevada latência (rede, por exemplo).

Aparentemente existem soluções melhores para outras bases de dados, como o seguinte comentário parece sugerir:

Whilst you can use the old “select 1 from dual” trick, the downside with this is that it issues an extra query each and every time you borrow a connection from the pool. For high volumes, this is wasteful.

JBoss provides a special connection validator which should be used for Oracle:

org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker

This makes use of the proprietary ping() method on the Oracle JDBC Connection class, and uses the driver’s underlying networking code to determine if the connection is still alive. — stackoverflow.com

Alguém conhece uma alternativa semelhante para MySQL?

Partilhar

 No TDS_RET_STATUS was found

ao inserir dados numa tabela em SQL Server. Ficam a saber que a causa pode ser esta:

Microsoft® SQL Server™ 2000 retains the 900-byte limit for the maximum size of an index key (…)

De facto a criação de um índice com um chave que exceda os 900 bytes em comprimento já resulta num aviso, mas sucede se os dados existentes na tabela no momento da criação do índice não ultrapassarem o tal limite dos 900 bytes.

No entanto, quando tentarem inserir dados que façam ultrapassar este limite podem ter um erro que, do outro lado de um ligação ODBC, pode ser tão pouco elucidativo como este

Partilhar

CREATE TABLE newtable LIKE mytable;

Pensei que devia existir algo equivalente para copiar as definições de uma base de dados inteira, mas aparentemente não existe.
A forma mais fácil de conseguir o mesmo resultado é provavelmente usar o mysqldump com a seguinte opção:

--no-data

No entanto, já há bastante tempo que queria experimentar os stored procedures do MySQL, por isso aproveitei a oportunidade para escrever o meu primeiro:

delimiter //
DROP PROCEDURE IF EXISTS copySchema //
CREATE PROCEDURE copySchema(IN schemaname CHAR(64))
BEGIN
DECLARE done INT DEFAULT 0;
DECLARE table_a CHAR(64) default 'testing';
DECLARE cur1 CURSOR FOR SELECT TABLE_NAME FROM information_schema.tables WHERE TABLE_SCHEMA = schemaname;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
OPEN cur1;
REPEAT
FETCH cur1 INTO table_a;
IF NOT done THEN
SELECT CONCAT('CREATE TABLE ', table_a, ' LIKE ', schemaname, '.', table_a) into @sqlstr;
PREPARE stmt FROM @sqlstr;
EXECUTE stmt;
END IF;
UNTIL done END REPEAT;
CLOSE cur1;
END
//
delimiter ;

CALL mydb.copySchema('mysql');

Referências:

• Create Procedure
• Cursors
• Prepared Statements

Partilhar

if not exists(select * from sys.databases where name = ‘Testing’)
    create database testing

better:

if db_id(’dbname’) is null
    create database testing

best?…

Source: Microsoft Forums

Partilhar

• Guardar todos os logs durante pelo menos 5 anos.
• Manter os últimos meses rapidamente acessíveis e passíveis de serem consultados de forma flexível e rápida.
• Garantir que em caso de avaria grave não se perdem mais do que 1 ou dois dias de logs.

Noutro post falei da possibilidade de usar o Archive storage engine como forma de reduzir o espaço ocupado e, simultaneamente, dificultar o encobrimento de acções ilegítimas através da eliminação de logs. 

Os problemas
Ao tentar usar o Archive storage engine como repositório de todos os logs, tentanto tirar partido da compresão e da durabilidade inerentes, surgem alguns problemas, nomeadamente:

• A compressão/descompressão de dados, associada à inexistência de índices torna as consultas com critérios complexos muito mais demoradas do que em MyISAM.
• O recurso a partições para acelerar as consultas (que são sempre limitadas a um determinado intervalo de tempo, e por isso prestam-se a partition pruning) é uma boa ideia, mas há limites…

A solução
A conjugação dos requisitos anteriores aponta quase directamente para uma solução heterogénea que combine o melhor de dois mundos: a rapidez de acesso e a flexibilidade do storage engine MyISAM, com a durabilidade e compressão do Archive.
A solução final tem os seguintes componentes:

• Uma base de dados em que os logs são guardados em tabelas MyISAM. As tabelas são particionadas por intervalo, usando a data do evento como chave de particionamento. Cada partição irá conter um dia dados, ou seja uma média de 300.000 registos. As tabelas são criadas vazias com duas partições, uma para o dia actual e outra para o dia seguinte.
• Uma base de dados em que os logs são guardados em tabelas Archive, sem recurso a partições, porque são conhecidos vários problemas com essa combinação, e já tive oportunidade de experimentar alguns deles. As tabelas são criadas vazias.
• Um script executado diariamente que verifica a existência de dados na base de dados MyISAM com mais de 60 dias e, caso existam, os copia para a base de dados Archive, eliminando de seguida a partição correspondente (e os dados nela contidos) da base de dados MyISAM.

Desta forma mantém-se sempre 2 meses de logs que são muito rápidos de consultar, graças ao uso de partições e do storage engine MyISAM é fácil e rápido fazer backup, e assegura-se o armazenamento a longo prazo com taxas de ocupação adequadas.

Partilhar

Para encerrar este tema, a solução final passou por replicar duas partições de alguns GBs usando DRBD 0.7, e montar o /var/lib/mysql lá em cima.

Como storage engine ficou o InnoDB, mas com tablespaces individuais por cada tabela, para ser mais fácil gerir o espaço em disco (e também dá jeito para backup/restore binário).

Ainda não simulei desastres com o sistema em carga, mas conto fazê-los em breve, se houver novidades dignas de registo, avisarei.

Só mais uma nota, durante o setup foi necessário sincronizar a partição entre duas localizações remotas e fiquei agradavelmente surpreendido com o desempenho de rede do DRBD.

PS: A história das maçãs serve apenas para facilitar a escrita e evitar mencionar o objectivo real da aplicação que está em cima desta infra-estrutura. Como é ortogonal em relação aos temas discutidos, julgo que ninguém sai lesado.

Partilhar

A grande sedução do modelo da lista de adjacências vem da facilidade com que se implementam as operações de inserção de nós (por onde normalmente se começa) e só se perde quando se chega ao ponto de precisar de alguma recursividade para percorrer convenientemente uma árvore com profundidade arbitrária.

Por oposição, o modelo dos “conjuntos encaixados” torna a operação de inserção bem mais difícil de escrever, mas, em contrapartida, facilita muito a tarefa de percorrer a árvore.

Em aplicações OLTP convencionais do tipo loja on-line, a árvore (de produtos e categorias) é criada uma vez e depois raramente é mexida. Mesmo que surjam novos produtos, estes irão usualmente encaixar em categorias pré-existentes, portanto a necessidade de criar novos nós intermédios na árvore é realmente baixa. Pelo contrário, a necessidade de apresentar uma lista de categorias com vários níveis de indentação que possam ser progressivamente expandidos até se chegarem aos produtos é crucial. Todos os clientes da loja on-line terão que passar por lá várias vezes durante a sua visita.

Nesta perspectiva, é bem mais compensador recorrer ao modelo dos conjuntos encaixados. Como também é normal, provavelmente o inverso é verdade se estivermos a falar de aplicações OLAP…

Partilhar

Encriptação
Encriptar a transmissão dos logs para garantir confidencialidade dos dados transmitidos. Como a transmissão é feita sobre UDP, não basta usar um túnel de SSH. Uma possibilidade é usar a funcionalidade de Datagram TLS (DTLS) que o openssl também fornece, mas ainda não consegui pôr isso a funcionar em Windows…

Host-based Auth
Neste momento qualquer host que tenha acesso ao servidor onde corre o rsyslogd pode enviar logs para lá. Já com a escrita dos logs para ficheiros isto podia ser usado para ataques DoS, mas com o overhead adicional da escrita para base de dados, começa a ser preocupante. Se não houver uma alternativa mais application-level, posso usar o iptables para limitar os hosts que têm acesso à porta 514/udp.

Storage Engine Archive
Na versão 5.0 o MySQL suporta um novo tipo de storage engine, o Archive. Descrição abreviada retirada do site:

In addition to its compression and ease-of-use capabilities, the Archive storage engine is ideal for data auditing uses. Archive tables only support SELECT and INSERT operations, which should cause every data security officer or auditor to smile. Why? Because auditing restrictions require that, once created, audit data should not be manipulated in any way. Archive tables support just these types of restrictions since data cannot be updated or selectively removed - in other words, no tampering allowed.

Para este tipo de aplicação isto é ouro sobre azul… Só é preciso ter cuidado com a versão do servidor MySQL que se usa, até à 5.0.15 havia um bug na Zlib que impedia que os ORDER BY funcionassem devidamente.

Partilhar

Syslogd
O syslogd vem de base com tudo o que é distro Linux e também se encontra para Unix. A consola do VMware ESX, sendo baseada em RHEL 3, também usa obviamente syslog.
Basta acrescentar ao /etc/syslog.conf (ou substitui-lo por inteiro) a seguinte linha para se conseguir enviar todas as mensagens para um servidor syslog central:

*.* @endereço-ip

Winlogd
O winlogd é um executável que se adiciona aos serviços do Windows e que envia, com as prioridades adequadas, todos os eventos que apareçam no Event Viewer para um syslog server remoto. A parametrização do endereço IP é feita no sítio do costume:

HKLM\System\CurrentControlSet\Services\Winlogd

Snmptrapd + snmptt
É vulgar encontrar UPS’s, unidades de A/C, geradores e demais equipamentos periféricos que enviam alertas através de TRAPs SNMP. As mensagens reportadas por um TRAP não são muito informativas se não forem traduzidas a partir de uma MIB. Uma boa forma de o fazer automaticamente e ainda guardar as mensagens num syslog é usar o SNMPTT.

Logs Domino
Os servidores Lotus Domino guardam os seus logs numa base de dados… adivinhem… Domino! Felizmente, se estiverem a correr em Linux, também enviam os logs para a consola. Se se acrescentar o seguinte pipe à invocação do servidor, consegue-se ter a consola disponível numa tty e, simultaneamente, enviar todos os logs para o syslog local:

$domino_server | tee /dev/tty8 | logger -p local3.info

É pena perder-se o conceito de priority, mas como o Domino não o suporta internamente, não há nada a fazer…

Rsyslogd
Em vez de syslog-ng como concentrador de logs, resolvi usar o rsyslogd. Na altura foi uma escolha do momento, mas veio a revelar-se oportuna, essencialmente porque o Phplogcon é melhorzinho que o php-syslog-ng.
O ficheiro de configuração é compatível com o do syslog, o que torna a migração muito fácil e rápida. Tal como o syslog-ng, a configuração é feita através de templates, e há vários exemplos no site que tornam o setup inicial coisa de segundos…
Com uma linha (grandita, é verdade…) define-se o template para inserir registos na base de dados:

$template dbFormat,"insert into SystemEvents (Message, Facility,FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg%', %syslogfacility%, '%HOSTNAME%',%syslogpriority%, '%timereported:::date-mysql%', '%timegenerated:::date-mysql%', %iut%, '%syslogtag%')",sql

E com outra linha, diz-se que se quer tudo lá dentro

*.* >localhost,rsyslog,rsyslog,rsyslog;dbFormat

Phplogcon
Finalmente, o Phplogcon é uma aplicação web para explorar os dados que o rsyslog guarda na base de dados. Não é o supra-sumo das ferramentas de exploração de dados, mas é bem rápida e suficientemente flexível para aquilo que normalmente se pretende destas ferramentas.
Para análises mais elaboradas, há uma ferramenta proprietária feita pela Adiscon (a empresa que faz o rsyslog e o phplogcon, já agora). Não cheguei a experimentá-la, mas parece valer a pena…

MySQL
Não há muito a dizer aqui. Usei um servidor MySQL completamente vanilla, com tabelas MyISAM, que para o caso servem perfeitamente.

Partilhar

O problema da dispersão geográfica pode ser resolvido em várias camadas.

1. Pode ser a própria aplicação a assumir a necessidade de manter toda a informação em bases de dados distintas.
2. Pode ser o servidor de base de dados a manter repositórios distintos para a mesma base de dados.
3. Por fim, podemos ter algum tipo de storage inteligente que seja capaz de manter discos em sítios diferentes sincronizados.

A primeira abordagem é muito pouco elegante do ponto de vista da Arquitectura. Porque é que uma aplicação que lida com maçãs há-de ter que se preocupar com o facto de eu dar muita importância às minhas maçãs e querer tê-las guardadas em dois sítios diferentes? Para além disso, é frequente que as aplicações sejam consideradas off-premises no que a estes problemas diz respeito… Vou esquecer esta hipótese.

A segunda abordagem faz mais sentido. Há várias bases de dados (proprietárias ou open-source) que lidam com o problema através de mecanismos de replicação e clustering. Umas fazem-no de forma síncrona, outras de forma assíncrona, há muitas alternativas por onde escolher e é um mundo bem conhecido de muita gente.

A terceira hipótese é, na minha opinião, aquela que faz mais sentido de todas. O problema que descrevi não me obriga, por si só, a ter duas bases de dados, não me obriga a balancear carga, nem sequer me impõe requisitos de alta disponibilidade. A única coisa que está em causa é mesmo a recuperação de um desastre. Para conseguir fazer isso basta-me, de facto, ter uma cópia permanentemente actualizada dos discos onde guardo a base de dados num sítio longínquo.

Sabendo isto, que alternativas tenho?

Replicação de Base de Dados
Se me quiser manter dentro das soluções open-source (é sempre uma preferência), a opção clara é pelo MySQL. Ora o MySQL oferece duas formas de manter uma ou mais cópias da informação de uma base de dados em dois ou mais sítios. Uma é através dos mecanismos normais de replicação, a outra é através de um produto mais ou menos autónomo, que é o MySQL Cluster.

A replicação do MySQL é sempre assíncrona e é feita através da replicação de um binary log serializado de todas as transacções executadas sobre a base de dados. Isto não serve. Como a replicação é assíncrona, um desastre na localização que tivesse a cópia master da base de dados fazia-me perder as maçãs que estivessem in flight. Isto não é aceitável, vou ter que descartar esta opção.

O MySQL Cluster é síncrono! É verdade que faz muito mais do que aquilo do que preciso, mas pelo menos é síncrono. Tem no entanto um problema inesperado: pelo menos na versão actual obriga a que toda a base de dados caiba em memória! Alguns testes feitos com a aplicação levaram-me a ter bases de dados de maçãs com vários gigabytes, e estavamos apenas em testes. É verdade que podia comprar servidores com muita memória, transformar todo o disco em swap space, mas a verdade é que me pareceu que estava a tentar resolver o problema com a ferramenta errada. Se não houvesse alternativas até podia ser, mas…

Não seria justo não falar das alternativas proprietárias. A Microsoft lançou com o SQL Server 2005 uma nova tecnologia denominada database mirroring, que faz precisamente o que se pretende. O downside desta hipótese são as duas licenças de Windows 2003 + duas licenças de SQL Server 2005, que levam a solução para cerca de 12 K€… Ouch!
Claro que Oracle e DB2 também têm respostas para este problema, mas o preço é ainda superior.

Replicação de Storage
No capítulo da replicação de storage, as soluções mais badaladas são todas proprietárias. As que conheço melhor são as da IBM, mas outros vendors têm soluções semelhantes. Copiando directamente de um PDF da IBM, existem as seguintes opções:

Enhanced Remote Mirroring consists of Global Mirror, Global Copy, and Metro Mirror and is designed to provide the ability to mirror data from one storage system to another over extended distances. It is
designed to control synchronization from within the storage system so that it is nearly transparent to the host application servers. Unlike FlashCopy, Enhanced Remote Mirroring is designed to provide continuous updates from the primary logical drive to the secondary. This is designed to provide data availability, and is a key technology for implementing Disaster Recovery and Business Continuity plans. The Metro Mirror mode is designed to provide synchronous mirroring for logical drives. Global Mirror mode is designed to provide asynchronous mirroring and includes the write-order consistency option.

O grande problema desta solução é que obriga a ter não uma, mas duas SAN IBM, pelo menos da gama 4000 e, dependendo dos modelos, pode ser ainda necessária uma licença específica para activar a feature de Enhanced Remote Mirroring. Usando preços de equipamentos usados disponíveis para encomendar na net, a brincadeira dificilmente ficaria por menos de 50K€… way too much!

Mas a ideia é boa e felizmente o mundo open-source tem uma palavra a dizer. Um dos componentes mais usados para construir clusters linux, logo a seguir ao heartbeat, é o DRBD - Distributed Remote Block Device. Simplificando muito, pode pensar-se no DRBD como uma espécie de RAID 1 entre dois discos que estão em servidores diferentes, e em que o meio usado para sincronização dos discos é uma rede IP em fez de um backplane SCSI.
Felizmente o DRBD tem um modo de funcionamento em que a replicação é síncrona, isto é, uma escrita em disco só é ack’ed depois de a escrita no disco remoto o ter sido: exactamente o pretendido!

Parece ter sido identificado o melhor candidato. Como o post vai longo, reservo para a próxima a apresentação da solução completa.

Partilhar