Arquivo

Archive for junho \28\UTC 2011

Quanto vale um profissional de T.I. certificado?

Certificações nada mais são do que uma prova, ou um conjunto delas que são requisitos para se obter um título. Muita gente pensa que as certificações são a salvação da lavoura e que assim, seus salários vão alavancar. O que não deixa de ser verdade, mas, não é bem assim. O valor de uma certificação, está baseado em varios fatores, entre eles, os que eu julgo como principais:

  • A relevância que o título tem para o mercado;
  • A relevância que o título tem para seu cargo atual;
  • A relevância que o título tem para a empresa em que trabalha.

Enfim, não vá esperando ganhar aquele desejado aumento de 10% de salário por conta de uma certificação LPIC-1, sendo que você trabalha em um ambiente Microsoft. Existem também outros fatores como sua escolaridade, sim, muita gente pensa que as certificações pesam mais do que a escolaridade, o que é irreal: o canudo sempre ira valer mais.

Então, que certificação eu devo obter?

Depende. Mas sempre dê preferência aos títulos que você e a empresa em que trabalha tenham interesse em conjunto, principalmente, se a empresa estiver bancando parte ou 100% de cursos, provas, etc. Não espere aumento imediato de salário, salvo sob raríssimas excessões, isso não irá acontecer, aguarde alguns meses para que a empresa recupere o investimento feito em você, entre 3 e 6 meses, ou mais, caso os custos com cursos e provas tenham sido bancados pela empresa; passado essa época, converse com seu gestor e tente conseguir algum aumento, mas com argumentos claros, nada de “chorar” muito, ok? Lembre-se, certificações são interessantes tanto para você, quanto para a empresa, mas se um dia você sair da empresa, você leva junto o título com você, por isso, cautela.

E se não houver aumento…

Não se sinta desestimulado. Pense positivo: se a empresa lhe bancou cursos e provas de certificação, já significa que você é um profissional que vale a pena investir. Continue fazendo seu trabalho, sugerindo novas soluções, se aprimorando, que um dia, você conquistará o que deseja.

Categorias:Posts Genéricos

Como configurar replicação no MySQL.

junho 24, 2011 6 comentários

Este artigo foi baseado no seguinte ambiente:

Tipo de Host: físico
Quantidade de hosts: 2
Distribuição Linux: Red Hat Enterprise Linux 6.1
Versão do MySQL: 5.1.52 (community)
IP do Host1: 10.1.1.1
IP do Host2: 10.1.1.2

O artigo a seguir, descreve a replicação baseada em ativo / passivo, ou seja, master -> slave. O host principal, que será o master, irá receber todas as atualizações no banco especificado para a replicação, e irá replicar para outro MySQL localizado em outro host, que será o slave. A principal utilidade nisso na rápida recuperação em caso de desastres físicos e também para balanceamento de carga de consulta, entre outras utilidades. Vale lembrar, que este tipo de replicação não é considerado seguro para recuperação de falhas lógicas como por exemplo, inserções ou deleções por engano, porque os dados serão replicados exatamente como são na base master para a slave.

1 – Configurando o Master.

Tenha em mente que o master é o banco que irá receber toda a carga de inserts, updates e deletes, só ele poderá sofrer alterações, enquanto o slave estará em modo read-only (somente leitura). Para este artigo, considere que o banco a ser replicado será o fictício ‘testdb‘.

Primeiramente, teremos de adicionar algumas linhas no arquivo /etc/my.cnf :

log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db=testdb
server-id=1

Uma vez feito, iremos reiniciar o SGDB para aplicar as novas configurações:

# /etc/init.d/mysqld restart

Considerando que você já criou um usuário para a replicação, iremos chamá-lo de slave_user, e iremos também aplicar o privilégio necessário para usá-lo durante a replicação. Para tal, executamos o SQL:

GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'alguma_senha';
FLUSH PRIVILEGES;

Feito, o master encontra-se configurado.

2 – Preparando o ambiente para a replicação e configurando o Slave.

Agora que temos um master, necessitamos de mais alguns passos para que possamos replicá-lo em outro host.

Primeiro, precisamos fazer um dump do banco que iremos replicar, mas com a devida precaução para que o mesmo não seja alterado antes de o master e o slave  estejam devidamente conectados e sincronizados. Esse trabalho é manual e pode tomar algum tempo dependendo do tamanho da base de dados bem como de sua infraestrutura. Para tal, precisamos executar o comando SQL para “travar” todas as tabelas do master:

USE testdb;
FLUSH TABLES WITH READ LOCK;

Uma vez  feito isso, devemos, em linha de comando, executar o binário mysqldump para jogar toda a base de dados em um arquivo de texto plano, para que assim possamos transportá-lo para o outro host que será o slave. Note que durante todo este processo, as tabelas do banco ‘testdb‘ estarão travadas. O exemplo abaixo considera que o usuário do master é  root e a senha é 123456. Execute no shell do Linux o seguinte comando:

# mysqldump -u root -p123456 –database testdb > testdb.sql

Uma vez que temos o banco inteiramente “dumpado” em um arquivo, agora você deve enviar da forma que mais lhe for conveniente para o outro host,  que será o slave.

Agora, devidamente conectado ao slave. Editaremos o arquivo /etc/my.cnf do mesmo, é incluiremos algumas linhas:

server-id=2
replicate-do-db=testdb

Então, devemos criar o banco para receber nosso dump que foi transferido do servidor master, para isso executaremos o comando SQL e criaremos o banco testdb no slave:

CREATE DATABASE testdb;

Deveremos então importar todos os dados do master, neste que será o slave, e logo após iremos reiniciar o SGDB slave. Para tal, execute na shell do Linux no host do slave o comando:

# mysql -uroot -p123456 testdb < testdb.sql
# /etc/init.d/mysqld restart

Após reiniciá-lo, iremos ativar a replicação, para tal devemos coletar algumas informações ainda o master como arquivo de log e posição do log. Para tal, execute o comando SQL no master:

SHOW MASTER STATUS;

Este comando deverá mostrar uma saída parecida com essa:

+---------------+----------+--------------+------------------+
| File          | Position | Binlog_do_db | Binlog_ignore_db |
+---------------+----------+--------------+------------------+
| mysql-bin.006 | 134      | testdb       |                  |
+---------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Isso significa que o nome do arquivo de log para esta replicação é mysql-bin.006 e encontra-se na posição 134. Agora iremos executar no slave o seguinte comando SQL:

USE testdb;
CHANGE MASTER TO MASTER_HOST=10.1.1.1', MASTER_USER='slave_user', MASTER_PASSWORD='alguma_senha', MASTER_LOG_FILE='mysql-bin.006', MASTER_LOG_POS=134;
SLAVE START;

Caso encontre algum erro, confira se o suporte a networking está habilitado no master já que a replicação é feita através de TCP/IP e não de UNIX Sockets. Caso esteja habilitado e você continuar recebendo mensagens de erro ao executar tal comando, favor repetir os passos e / ou consultar este artigo novamente para saber se houve algum erro durante a implementação.

Para conferir que está tudo OK, você deve executar o comando:

SHOW SLAVE STATUS\G

Esse comando irá lhe reportar o status do cluster de replicação. Caso esteja tudo OK, é hora de “destravar” as tabelas no master, executando no master o comando SQL:

UNLOCK TABLES;

Pronto, a replicação do banco testdb está feita. Para certificar-se se está funcionando de maneira correta, faça alterações no master e veja se as mesmas são replicadas no slave.

3 – Finalizando o artigo.

Espero que este artigo tenha lhe sido útil. Caso encontre erros aqui e/ou deseja sugerir mudanças ou adicionar mais informações ao artigo, escreva nos comentários e as devidas alterações serão feitas dando os devidos créditos aos autores.