O suporte para a prova de conceito Tungsten para MongoDB chegou em maio, quando eu falei sobre nosso hackathon para replicar o MySQL para o MongoDB. Esse código ficou inativo por alguns meses enquanto a gente trabalhou em outras coisas como a replicação paralela, mas o período de ociosidade acabou. Em setembro, eu verifiquei as correções feitas ao Tungsten Replicator para adicionar o suporte de instalação em uma linha para MongoDB slaves.

A replicação do MySQL para MongoDB já é oficialmente suportada pelo Tungsten Replicator 2.0.5. No entanto, aqui está um rápido guia sobre como usar meus lab hosts logos1 para o MySQL master e logos2 para o MongoDB slave.

1. Faça o download da última construção de desenvolvimento do Tungsten Replicator. Veja a página de nightly builds para URLs S3.

$ cd /tmp
$ wget --no-check-certificate https://s3.amazonaws.com/files.continuent.com/builds/nightly/tungsten-2.0-snapshots/tungsten-replicator-2.0.5-332.tar.gz

2. Descompactar o arquivo tar e entrar na pasta descompactada.

$ tar -xzf tungsten-replicator-2.0.5-332.tar.gz
$ cd tungsten-replicator-2.0.5-332

3. Instale o replicador MySQL em um host que tenha o MySQL instalado e que esteja configurado para usar a repliacacao de linhas, por exemplo binlog_format=row. Note que você precisa habilitar os colnames e filtros pkey. Eles adicionam nomes de colunas para atualizações de linhas e eliminam a atualização e deletam as colunas de consulta que não correspondem à chave primária, respectivamente.

Por último, mas não menos importante, certifique-se de que as strings sejam convertidas para o Unicode ao invés de serem transportadas como bytes puros, o que temos que fazer na replicação do MySQL homogêneo para definir questões sutis do conjunto de caracteres.

$ tools/tungsten-installer --master-slave -a \
  --datasource-type=mysql \
  --master-host=logos1  \
  --datasource-user=tungsten  \
  --datasource-password=secret  \
  --service-name=mongodb \
  --home-directory=/opt/continuent \
  --cluster-hosts=logos1 \
  --mysql-use-bytes-for-string=false \
  --svc-extractor-filters=colnames,pkey \
  --svc-parallelization-type=disk --start-and-report

4. Finalmente, instale o MongoDB slave. Antes de fazer isso, certifique-se de que o mongod 1.8.x está rodando no host como descrito no artigo original sobre replicação de MySQL para MongoDB. Meu mongod está rodando na porta padrão, 27017, então não existe uma opção de –slave-port necessária.

$ tools/tungsten-installer --master-slave -a \
  --datasource-type=mongodb \
  --master-host=logos1  \
  --datasource-user=tungsten  \
  --datasource-password=secret  \
  --service-name=mongodb \
  --home-directory=/opt/continuent \
  --cluster-hosts=logos2 \
  --skip-validation-check=InstallerMasterSlaveCheck \
  --svc-parallelization-type=disk --start-and-report

É isso aí. Você testa a replicação ao fazer o login no MySQL no master, adicionando uma linha à tabela, e confirmando que ele chega ao slave. Primeiro, seguem os comandos do SQL:

$ mysql -utungsten -psecret -hlogos1 test
Welcome to the MySQL monitor.  Commands end with ; or \g.
...
mysql> create table bar(id1 int primary key, data varchar(30));
Query OK, 0 rows affected (0.15 sec)

mysql> insert into bar values(1, 'hello from mysql');
Query OK, 1 row affected (0.00 sec)

Agora cheque os conteúdos do MongoDB:

$ mongo logos2:27017/test
MongoDB shell version: 1.8.3
connecting to: logos2:27017/test
system.indexes
> db.bar.find()
{ "_id" : ObjectId("4e85269484aef8fcae4b0010"), "id1" : "1", "data" : "hello from mysql" }

Voila! Ainda podemos ter bugs, mas pelo menos minha replicação do MySQL para MongoDB está fácil de ser instalada.

Falando em bugs, eu tenho corrigido problemas à medida que eles surgem nos testes. A melhoria mais significativa é um recurso que chamo de autoindexação nos MongoDB slaves. O MongoDB materializa coleções automaticamente quando você insere a primeira atualização, mas ele não faz nada a respeito dos índices.

Minhas primeiras execuções do TPC-B processaram menos de 100 transações por segundo no MongoDB slave, o que é bastante patético. O gargalo é devido às operações de atualização do MongoDB da forma ‘db.account.findAndModify(myquery,mydoc)’. Você deve indexar as propriedades usadas na consulta ou as coisas ficarão muito lentas.

A autoindexação resolve o problema do gargalo ao certificar-se de que existe um índice correspondente à chave primária do SQL para qualquer tabela que atualizemos. O  MongoDB faz com que essa lógica seja muito simples de implementar – você pode emitir um comando como ‘db.account.ensureIndex({account_id:1})’ para criar um índice.

O que é muito legal é que o MongoDB fará isso mesmo se a coleção ainda não estiver materializada – por exemplo, antes de você carregar seus dados. Parece ser um outro exemplo de como as coleções do MongoDB se materializam sempre que você se refere a elas, o que é um recurso bastante útil.

As atualizações do TPC-B no MongoDB agora estão rodando a mais de 1000 transações por segundo nos meus hosts de teste. Planejo corrigir mais bugs e aumentar ainda mais o desempenho nas próximas semanas. Através do MongoDB estamos desaprendendo presunções dentro do Tungsten que são necessárias para funcionar com bancos de dados não-relacionais. É uma ótima preparação para o grande jogo no ano que vem: a replicação para HBase e Cassandra. 

?

Texto original disponível em http://scale-out-blog.blogspot.com/2011/09/quick-installation-of-replication-from.html