O que é FailOver, Failback e SwitchOver

Standard

O Que significa Failover, Failback e Switchover nos tutoriais em inglês?

Quem instala sistemas com grande quantidade de usuários é indispensável implementar mecanismo que garanta alta disponibilidade dos serviços. O pacote Heartbeat é um dos mais populares para implementar tais mecanismos no mundo Linux. Quem instala sistemas Asterisk, OpenSER, servidor web, banco de dados, entre outros sistemas se depara na documentação do Heartbeat com os termos de failover, failback e switchover. Para que não está familiarizado com essa termologia, como uma colher de chá e também como forma de documentar na língua pátria, segue uma definição extraída da Wikipedia, http://en.wikipedia.org/wiki/Failover e http://en.wikipedia.org/wiki/Switchover:

Failover

O failover é a capacidade de determinado sistema/serviço migrar automaticamente para um outro servidor, sistema ou rede redundante ou que está em standby quando da ocorrência de falha ou término anormal do servidor, do sistema ou da rede que estava ativo até aquele instante. O Failover acontece sem intervenção humana e geralmente sem aviso prévio, diferente de switchover.

Os projetistas de sistemas normalmente fornecem capacidade de failover em servidores, sistemas ou redes que exigem continua disponibilidade e um alto grau de confiabilidade.

A automação é feita usando um cabo “Heartbeat” que é conectado aos dois servidores. Tão longo exista um “Pulso ou mensagem heartbeat” do servidor principal para o servidor secundário, o servidor secundário não iniciará seus sistemas. Pode haver também um terceiro servidor “Spare parts” que possui rodando componentes de reserva para comutação “no fogo” para evitar a interrupção durante o lapso de tempo da comutação.

O segundo servidor imediatamente assumirá o trabalho do primeiro tão logo ele detecte alguma alteração na mensagem “heartbeat” da primeira máquina. Alguns sistemas possuem a habilidade de mandar uma mensagem via page ou enviar uma mensagem para um técnico pré-designado ou centro de monitoração.

Em alguns sistemas, o failover é intencionalmente não automático por completo, que exige a intervenção humana. Isso é chamado “automatizado com aprovação manual“, porque a atividade fica automática uma vez que seja dada a aprovação.

Reciprocamente, o Failback é o processo de restauração de um sistema/componente/serviço que se encontra em um estado de failover (ou seja, aquela máquina onde estava rodando o serviço que apresentou problrmas) de volta a seu estado original que estava antes da falha.

Switchover

O switchover é a capacidade de um sistema de comutar manualmente para um computador servidor, sistema ou rede redundante ou em standby quando da ocorrência de falha ou término anormal do servidor, sistema, ou rede ativo anteriormente. Switchover acontece com a intervenção humana, diferentemente do Failover.

Um switchover normalmente seria iniciado a fim de executar manutenção do sistema, como instalação de patches, atualização para uma nova release ou atualização do seu sistema. Em outros casos, o sistema inteiro é suficientemente complexo em que fazer o failover automático não é possível.

 

Fonte: http://www.noticiaria.com.br/item/id/127389/title/Que_e_Failover__Failback_e_Switchover

O que é e como funciona a Alta Disponibilidade

Standard

Definição

Para que se entenda a Alta Disponibilidade faz-se necessário, antes de mais nada, perceber que a Alta Disponibilidade não é apenas um produto ou uma aplicação que se instale, e sim uma característica de um sistema computacional. Existem mecanismos e técnicas, blocos básicos, que podem ser utilizados para aumentar a disponibilidade de um sistema. A simples utilização destes blocos, entretanto, não garante este aumento se não for acompanhado de um completo estudo e projeto de configuração.

A Disponibilidade de um sistema computacional, indicada por A(t), é a probabilidade de que este sistema esteja funcionando e pronto para uso em um dado instante de tempo t. Esta disponibilidade pode ser enquadrada em três classes, de acordo com a faixa de valores desta probabilidade. As três classes são: Disponibilidade Básica, Alta Disponibilidade e Disponibilidade Contínua.

Disponibilidade Básica

A Disponibilidade Básica é aquela encontrada em máquinas comuns, sem nenhum mecanismo especial, em software ou hardware, que vise de alguma forma mascarar as eventuais falhas destas máquinas. Costuma-se dizer que máquinas nesta classe apresentam uma disponibilidade de 99% a 99,9%. Isto equivale a dizer que em um ano de operação a máquina pode ficar indisponível por um período de 9 horas a quatro dias. Estes dados são empíricos e os tempos não levam em consideração a possibilidade de paradas planejadas (que serão abordadas mais adiante), porém são aceitas como o senso comum na literatura da área.

Alta Disponibilidade

Adicionando-se mecanismos especializados de detecção, recuperação e mascaramento de falhas, pode-se aumentar a disponibilidade do sistema, de forma que este venha a se enquadrar na classe de Alta Disponibilidade. Nesta classe as máquinas tipicamente apresentam disponibilidade na faixa de 99,99% a 99,999%, podendo ficar indisponíveis por um período de pouco mais de 5 minutos até uma hora em um ano de operação. Aqui se encaixam grande parte das aplicações comerciais de Alta Disponibilidade, como centrais telefônicas.

Disponibilidade Contínua

Com a adição de noves se obtém uma disponibilidade cada vez mais próxima de 100%, diminuindo o tempo de inoperância do sistema de forma que este venha a ser desprezível ou mesmo inexistente. Chega-se então na Disponibilidade Contínua, o que significa que todas as paradas planejadas e não planejadas são mascaradas, e o sistema está sempre disponível.

Objetivos

Como já pode ser percebido de sua definição, o principal objetivo da Alta Disponibilidade é buscar uma forma de manter os serviços prestados por um sistema a outros elementos, mesmo que o sistema em si venha a se modificar internamente por causa de uma falha. Aí está implícito o conceito de mascaramento de falhas, através de redundância ou replicação (termos que serão conceituados mais tarde). Um determinado serviço, que se quer altamente disponível, é colocado por trás de uma camada de abstração, que permita mudanças em seus mecanismos internos mantendo intacta a interação com elementos externos.

Este é o coração da Alta Disponibilidade, uma sub-área da Tolerância a Falhas, que visa manter a disponibilidade dos serviços prestados por um sistema computacional, através da redundância de hardware e reconfiguração de software. Vários computadores juntos agindo como um só, cada um monitorando os outros e assumindo seus serviços caso perceba que algum deles falhou.

Outra possibilidade importante da Alta Disponibilidade é fazer isto com computadores simples, como os que se pode comprar até num supermercado. A complexidade pode estar apenas no software. Mais fácil de desenvolver que o hardware, o software de Alta Disponibilidade é quem se preocupa em monitorar outras máquinas de uma rede, saber que serviços estão sendo prestados, quem os está prestando, e o que fazer quando uma falha é percebida.

Cálculo da Disponibilidade

Em um sistema real, se um componente falha, ele é reparado ou substituído por um novo componente. Se este novo componente falha, é substituído por outro e assim por diante. O componente reparado é tido como no mesmo estado que um componente novo. Durante sua vida útil, um componente pode ser considerado como estando em um destes estados: funcionando ou em reparo. O estado funcionando indica que o componente está operacional e o estado em reparo significa que ele falhou e ainda não foi substituído por um novo componente.

Em caso de defeitos, o sistema vai de funcionando para em reparo, e quando a substituição é feita ele volta para o estado funcionando. Sendo assim, pode-se dizer que o sistema apresenta ao longo de sua vida um tempo médio até apresentar falha (MTTF) e um tempo médio de reparo (MTTR). Seu tempo de vida é uma sucessão de MTTFs e MTTRs, à medida que vai falhando e sendo reparado. O tempo de vida útil do sistema é a soma dos MTTFs nos ciclos MTTF+MTTR já vividos.

De forma simplificada, diz-se que a disponibilidade de um sistema é a relação entre o tempo de vida útil deste sistema e seu tempo total de vida. Isto pode ser representado pela fórmula abaixo:

Disponibilidade = MTTF / (MTTF + MTTR)

Ao avaliar uma solução de Alta Disponibilidade, é importante levar em consideração se na medição do MTTF são observadas como falhas as possíveis paradas planejadas. Mais considerações sobre este assunto serão tecidas em seções posteriores.

Conceitos

Para se entender corretamente do que se está falando quando se discute uma solução de Alta Disponibilidade, deve-se conhecer os conceitos envolvidos. Não são muitos, porém estes termos são muitas vezes utilizados de forma errônea em literatura não especializada. Antes de mais nada, deve-se entender o que é falha, erro e defeito. Estas palavras, que parecem tão próximas, na verdade designam a ocorrência de algo anormal em três universos diferentes de um sistema computacional.

Falha

Uma falha acontece no universo físico, ou seja, no nível mais baixo do hardware. Uma flutuação da fonte de alimentação, por exemplo, é uma falha. Uma interferência eletromagnética também. Estes são dois eventos indesejados, que acontecem no universo físico e afetam o funcionamento de um computador ou de partes dele.

Erro

A ocorrência de uma falha pode acarretar um erro, que é a representação da falha no universo informacional. Um computador trabalha com bits, cada um podendo conter 0 ou 1. Uma falha pode fazer com que um (ou mais de um) bit troque de valor inesperadamente, o que certamente afetará o funcionamento normal do computador. Uma falha, portanto, pode gerar um erro em alguma informação.

Defeito

Já esta informação errônea, se não for percebida e tratada, poderá gerar o que se conhece por defeito. O sistema simplesmente trava, mostra uma mensagem de erro, ou ainda perde os dados do usuário sem maiores avisos. Isto é percebido no universo do usuário.

Recapitulando, uma falha no universo físico pode causar um erro no universo informacional, que por sua vez pode causar um defeito percebido no universo do usuário. A Tolerância a Falhas visa exatamente acabar com as falhas, ou tratá-las enquanto ainda são erros. Já a Alta Disponibilidade permite que máquinas travem ou errem, contanto que exista outra máquina para assumir seu lugar.

Para que uma máquina assuma o lugar de outra, é necessário que descubra de alguma forma que a outra falhou. Isso é feito através de testes periódicos, cujo período deve ser configurável, nos quais a máquina secundária testa não apenas se a outra está ativa, mas também fornecendo respostas adequadas a requisições de serviço. Um mecanismo de detecção equivocado pode causar instabilidade no sistema. Por serem periódicos, nota-se que existe um intervalo de tempo durante o qual o sistema pode estar indisponível sem que a outra máquina o perceba.

Failover

O processo no qual uma máquina assume os serviços de outra, quando esta última apresenta falha, é chamado failover. O failover pode ser automático ou manual, sendo o automático o que normalmente se espera de uma solução de Alta Disponibilidade. Ainda assim, algumas aplicações não críticas podem suportar um tempo maior até a recuperação do serviço, e portanto podem utilizar failover manual[1]. Além do tempo entre a falha e a sua detecção, existe também o tempo entre a detecção e o reestabelecimento do serviço. Grandes bancos de dados, por exemplo, podem exigir um considerável período de tempo até que atualizem os índices de suas tabelas e, durante este tempo, o serviço ainda estará indisponível.

Para se executar o failover de um serviço, é necessário que as duas máquinas envolvidas possuam recursos equivalentes. Um recurso pode ser uma placa de rede, um disco rígido, os dados neste disco, e todo e qualquer elemento necessário à prestação de um determinado serviço. É vital que uma solução de Alta Disponibilidade mantenha recursos redundantes com o mesmo estado, de forma que o serviço possa ser retomado sem perdas.

Dependendo da natureza do serviço, executar um failover significa interromper as transações em andamento, perdendo-as, sendo necessário reiniciá-las após o failover. Em outros casos, significa apenas um retardo até que o serviço esteja novamente disponível. Nota-se que o failover pode ou não ser um processo transparente, dependendo da aplicação envolvida.

Failback

Ao ser percebida a falha de um servidor, além do failover é obviamente necessário que se faça manutenção no servidor falho. Ao ser recuperado de uma falha, este servidor será recolocado em serviço, e então se tem a opção de realizar o processo inverso do failover, que se chama failback. O failback é portanto o processo de retorno de um determinado serviço de uma outra máquina para sua máquina de origem. Também pode ser automático, manual ou até mesmo indesejado. Em alguns casos, em função da possível nova interrupção na prestação de serviços, o failback pode não ser atraente.

Missão

Quando se calcula a disponibilidade de um sistema, é importante que se observe o conceito de missão. Missão de um sistema é o período de tempo no qual ele deve desempenhar suas funções sem interrupção. Por exemplo, uma farmácia, que funcione das 8h às 20h, não pode ter seu sistema fora do ar durante este período de tempo. Se este sistema vier a apresentar defeitos fora deste período, ainda que indesejados, estes defeitos não atrapalham em nada o andamento correto do sistema quando ele é necessário. Uma farmácia 24h obviamente tem uma missão contínua, de forma que qualquer tipo de parada deve ser mascarada.

A Alta Disponibilidade visa eliminar as paradas não planejadas. Porém, no caso da primeira farmácia, as paradas planejadas não devem acontecer dentro do período de missão. Paradas não planejadas decorrem de defeitos, já paradas planejadas são aquelas que se devem a atualizações, manutenção preventiva e atividades correlatas. Desta forma, toda parada dentro do período de missão pode ser considerada uma falha no cálculo da disponibilidade.

Uma aplicação de Alta Disponibilidade pode ser projetada inclusive para suportar paradas planejadas, o que pode ser importante, por exemplo, para permitir a atualização de programas por problemas de segurança, sem que o serviço deixe de ser prestado.

Monitoração de nodos

A monitoração de nodos é realizada pelo heartbeat. Ele é o responsável por testar periodicamente os nodos do cluster, coordenando as ações de failover e failback. As soluções que utilizam reativação automática de serviços serão baseadas neste pacote.

Replicação de disco

A replicação de disco é de responsabilidade do DRBD, um driver de bloco para o kernel que cria um dispositivo de bloco[2] virtual, consistindo tanto de um disco real local quanto de uma conexão de rede, que terá na outra ponta outro driver DRBD atuando como secundário. Tudo aquilo que é escrito no dispositivo virtual é escrito no disco local e também enviado para o outro driver, que fará a mesma operação em seu disco local. Com isto se obtém dois nodos com discos exatamente iguais, até o instante da falha. As aplicações que trabalham com dados dinâmicos ou atualizados com muita freqüência se beneficiam deste driver.

Atenção
Configurações com centenas de gigabytes e/ou muito volumes gerenciados pelo DRBD devem ser bem testadas antes de serem colocadas em produção, pois o DRBD ainda está em desenvolvimento e algumas situações extremas podem não ter sido testadas.

Sistema de arquivos

Dados replicados ou não, é importante que o sistema de arquivos esteja consistente. Nem todos os sistemas de arquivos garantem isso, portanto para esta solução se escolheu trabalhar com o Ext3 Filesystem. Este sistema de arquivos trabalha com journal, o que significa que todas as alterações de dados são antes registradas no disco para que, caso o sistema venha a falhar durante este processo, a transação possa ser recuperada quando o sistema voltar. Isto confere agilidade ao processo de recuperação de falhas, bem como aumenta muito a confiabilidade das informações armazenadas.

Monitoração de serviços

A monitoração de serviços é feita através do Mon, um super- escalonador de testes que pode verificar centenas de máquinas e serviços de forma rápida e ágil, enviando alertas para endereços de correio eletrônico, pagers ou telefones celulares, garantindo que os administradores dos serviços estejam sempre bem informados sobre seu estado de operação. Suporta dependências entre testes, portanto não perde tempo verificando se um servidor de HTTP está respondendo em uma máquina que sabe estar inoperante. Um alerta pode até mesmo tentar recuperar a situação automaticamente ou reiniciar uma máquina, caso a falha ocorra em um horário de difícil manutenção.

Procure saber mais sobre HEARTBEATS e DRDBS.

Replicação de dados no Mysql sob SSL no Debian Squeeze

Standard

Esse how to tem 2 pontos chave:

1 – inibir o man in the middle

2 – replicar dados entre bases de dados para que, em uma eventual falha de hardware possamos estar beeeeem providos :).

 

Considerações iniciais:

master.appunixlabs.com.br -> 10.0.0.1

slave.appunixlabs.com.br -> 10.0.0.2

 

Nos 2 servers, como root devemos rodar o seguinte comando:

apt-get install mysql-server mysql-client -y

Assim que rodarmos o comando acima será solicitada confirmação de senha do root do banco de dados:

New password for the MySQL “root” user: <—– Devemos colocar a senha de root
Repeat password for the MySQL “root” user: <– Devemos repetir a senha de root

 

O que iremos fazer agora é verificar os recursos de ssl do server mysql, veja que devemos logar antes como root do banco de dados mysql:

mysql -u root -p

No mysql console devemos exibir as variáveis de SSL:

mysql> show variables like ‘%ssl%’;
Saída que mais interessa -> have_openssl e have_ssl:

+—————+———-+
| Variable_name | Value    |
+—————+———-+
| have_openssl  | DISABLED |
| have_ssl      | DISABLED |
| ssl_ca        |          |
| ssl_capath    |          |
| ssl_cert      |          |
| ssl_cipher    |          |
| ssl_key       |          |
+—————+———-+
7 rows in set (0.00 sec)

mysql>

Vamos sair do mysql:

quit;

 

Precisamos editar os confs do mysql para dar suporte ao SSL:

vim /etc/mysql/my.cnf

Na sessão * Security Features devemos acrescentar SSL, pode ser usado da seguinte forma:

 

# * Security Features
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
ssl
# ssl-ca=/etc/mysql/cacert.pem

Devemos validar nossa alteração, para isto vamos reiniciar o mysql com o seguinte comando:


/etc/init.d/mysql restart

Para confirmarmos o suporte o SSL em ambos os servers (presumindo que você está seguindo até aqui o passo-a-passo nos 2 servidores) devemos logar no mysql como root e verificar as variáveis de ssl:

mysql -u root -p

Logando-se como root devemos usar:

mysql> show variables like ‘%ssl%’;

A saída deste comando deve assemelhar-se com:

+—————+——-+
| Variable_name | Value |
+—————+——-+
| have_openssl  | YES   |
| have_ssl      | YES   |
| ssl_ca        |       |
| ssl_capath    |       |
| ssl_cert      |       |
| ssl_cipher    |       |
| ssl_key       |       |
+—————+——-+
7 rows in set (0.00 sec)

mysql>

Pule fora do mysql:

mysql> quit;

No servidor MASTER devemos colocar o suporte a acesso remoto ao mysql, do contrário não teremos a replicação de dados em tempo real em hipótese alguma :P, para isto devemos fazer o seguinte, no conf do mysql temos de editar a parte de bind-address:

vim /etc/mysql/my.cnf

# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address           = 127.0.0.1

somente comentando bind-address estamos evitando que o acesso remoto só ocorra por lookup.

Ainda no server master temos de validar nossa alteração:

/etc/init.d/mysql restart

Vamos ver os sockets abertos do mysql na porta com suporte a SSL:

netstat -tap | grep mysql

A saída deve assemelhar-se com:

tcp        0      0 *:mysql                 *:*                     LISTEN      2792/mysqld

Devemos criar agora os certificados para dar suporte a camada segura, tanto no main server como no slave, para isso iremos rodar o seguinte comando:

mkdir /etc/mysql/newcerts && cd /etc/mysql/newcerts

Em paralelo iremos instalar também o openssl:

apt-get install openssl

Vamos criar os certificados agora com chave beeeeeeeem gorda para CA:

openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem

Vamos criar os certificados do servidor master:

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout master-key.pem > master-req.pem
openssl x509 -req -in master-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > master-cert.pem

Agora vamos criar o ceritificado do server slave:

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout slave-key.pem > slave-req.pem
openssl x509 -req -in slave-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > slave-cert.pem

Agora que criamos os certificados no servidor Master, deveremos enviar os certificados para o servidor SLAVE, os quais lhe pertencem -> ca-cert.pem, slave-cert.pem e slave-key.pem.

No servidor Slave, como root criaremos a pasta dos certificados:

mkdir /etc/mysql/newcerts

Agora no Servidor Master devemos enviar os certificados para pasta de certificados do servidor Slave:

scp /etc/mysql/newcerts/ca-cert.pem root@10.0.0.2:/etc/mysql/newcerts

scp /etc/mysql/newcerts/slave-cert.pem root@10.0.0.2:/etc/mysql/newcerts

scp /etc/mysql/newcerts/slave-key.pem root@10.0.0.2:/etc/mysql/newcerts

 

No servidor MASTER temos de ativar o suporte aos certificados recém criados, para isto iremos editar novamente o conf do mysql na sessão de Segurança (aonde colocamos a linha SSL):

vim /etc/mysql/my.cnf

Seu conf deverá ficar parecido com este:

# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
ssl
ssl-ca=/etc/mysql/newcerts/ca-cert.pem
ssl-cert=/etc/mysql/newcerts/master-cert.pem
ssl-key=/etc/mysql/newcerts/master-key.pem

Agora iremos reiniciar o mysql para validar os certificados:

/etc/init.d/mysql restart

Agora, ainda no Master Server temos de dar permissão de replicação ao server Slave dentro do Mysql:

mysql -u root -p

No console do mysql rode:

mysql>GRANT REPLICATION SLAVE ON *.* TO ‘LOGINdoSLAVEserver’@’%’ IDENTIFIED BY ‘Senha_Slave’ REQUIRE SSL;

Para forçar um usuário que você criou para conectar-se somente por SSL, neste caso LOGINdoSLAVEserver devemos fazer o seguinte:

mysql>GRANT USAGE ON *.* TO ‘LOGINdoSLAVEserver‘@’%’ REQUIRE SSL;

mysql> FLUSH PRIVILEGES;

mysql> quit;

Os dois comandos acima dizem: Atualize os privilégios (no caso logins e senhas, ou mudanças de permissões de banco de dados para usuários) e saia fora ;).

Agora precisamos setar a base de dados de logs e dizer quem é o master. Faremos isto assim:

vim /etc/mysql/my.cnf

# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
binlog_do_db            = basedelogsdb

Chamamos nossa base de dados de logs que iremos compartilhar de basedelogsdb e para validar a mudança do servidor Master temos de reiniciar o mysql:

/etc/init.d/mysql restart

Teremos agora de fazer um dump da base de dados de logs para deixar o slave correndo no mesmo embalo do master, para isto faremos o seguinte:

mysql -u root -p

Depois de logar-se no Mysql:

mysql>USE exampledb;
mysql>FLUSH TABLES WITH READ LOCK;
mysql>SHOW MASTER STATUS;

O último comando deve exibir:

+——————+———-+————–+——————+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000001 |      106 | exampledb    |                  |
+——————+———-+————–+——————+
1 row in set (0.00 sec)

mysql>
Neste ponto não devemos dar quit, é muito importante isto, pois, no server Master ainda, iremos abrir outro terminal (se estiver direto no shell use CTRL + ALT + F2), abrindo uma nova shell logue-se como root e vamos continuar nosso how to. Como root rode os comandos:

cd /tmp

mysqldump -u root -p aSENHAdoMysql –opt basedelogsdb > cluster.sql

scp snapshot.sql root@10.0.0.2:/tmp

Nos passos acima entramos na pasta temporária, como root do banco de dados geramos um dump da base de dados de logs do main server e enviamos para o /tmp do servidor SLAVE.

Agora você pode sair da segunda tela, voltar para a primeira (CTRL + ALT+ F1, caso esteja 100% na shell) e rodar:

mysql> UNLOCK TABLES;

mysql> quit;

 

No servidor SLAVE iremos editar o conf do mysql na sessão [mysqld] e inserir as strings:

vim /etc/mysql/my.cnf

server-id=2
master-connect-retry=60
replicate-do-db=basedelogsdb

Este ID que estamos vendo JAMAIS poderá ser igual em servers que estão replicando dados.

Para validar nossas mudanças rode:

/etc/init.d/mysql restart

Agora iremos criar a base de dados de logs dentro do servidor SLAVE:

mysql -u root -p

mysql> CREATE DATABASE exampledb;
mysql> quit;

Ainda no servidor SLAVE iremos restaurar o dump chamado cluster.sql:

/usr/bin/mysqladmin –user=root –password=SenhaROOTmysql stop-slave
cd /tmp
mysql -u root -p SenhaROOTmysql basedelogsdb < cluster.sql

Agora iremos logar-nos como root no SLAVE server para poder ativar as variáveis de Show Master exibidas no main server, ou seja, o que foi exibido lá deverá ser ativado aqui, por isso tome muito cuidado:

mysql -u root -p

mysql> CHANGE MASTER TO MASTER_HOST=’10.0.0.1′, MASTER_USER=’LOGINdoSLAVEserver‘, MASTER_PASSWORD=’Senha_Slave‘, MASTER_LOG_FILE=’mysql-bin.000001’, MASTER_LOG_POS=106, MASTER_SSL=1, MASTER_SSL_CA = ‘/etc/mysql/newcerts/ca-cert.pem’, MASTER_SSL_CERT = ‘/etc/mysql/newcerts/slave-cert.pem’, MASTER_SSL_KEY = ‘/etc/mysql/newcerts/slave-key.pem’;

mysql> START SLAVE;

Para confirmarmos se tudo ficou filé:

mysql> SHOW SLAVE STATUS G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.1
Master_User: LOGINdoSLAVEserver
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 106
Relay_Log_File: mysqld-relay-bin.000002
Relay_Log_Pos: 251
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB: basedelogsdb
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 106
Relay_Log_Space: 407
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: Yes
Master_SSL_CA_File: /etc/mysql/newcerts/ca-cert.pem
Master_SSL_CA_Path:
Master_SSL_Cert: /etc/mysql/newcerts/slave-cert.pem
Master_SSL_Cipher:
Master_SSL_Key: /etc/mysql/newcerts/slave-key.pem
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
1 row in set (0.00 sec)

mysql>

 

Com isto todas as mudanças que ocorrerem em basedelogsdb no master server estarão replicadas no Slave Server.

 

Abraços a todos e bons estudos.
Equipe AppUnix.

Fontes:

Corrigindo Maldito encoding do Postgres para poder usar banco de dados latin1 ou outro e mudar o encoding do Sistema operacional Ubuntu ou Debian

Standard

Se você está como estive tempos atrás: irado, revolto, sem esclarecimento de como as coisas funcionam em um excelente (talvez o melhor) SGDB – Postgres e está sofrendo com os males:

1 – Encoding do Sistema Operacional Debian/Ubuntu Ferrados (sim, você brasileiro e a droga do locale te mostrando coisas de americanos, pode uma coisa destas?)

2 – Mudar o Encoding do Postgres.

Vamos ao ataque

Antemão você precisa saber que o seu sistema foi configurado por algum bestão, isto mesmo, o cara instalou o sistema americano sendo brasileiro.

Ter um porstgres que não aceita nem a pau um encoding diferente (padrão dessa tosquisse sempre é UTF8).

Locale do Sistema

Mãos-a-Obra

Todas as configurações e comandos foram executados como usuário root.

Existem vários arquivos que fazem a configuração do locale, precisamos configurar todos eles e depois executar alguns comandos, vamos lá.

Edite o arquivo /etc/environment e altere os campos LANG e LANGUAGE de forma que fiquem iguais ao abaixo, se não existir, acrescente:

LANG="pt_BR"
LANGUAGE="pt_BR:pt:en"

O arquivo /etc/default/locale também deve ser editado e seu conteúdo deve ser:

LANG="pt_BR"
LANGUAGE="pt_BR:pt:en"

Execute o seguinte comando:

# echo "pt_BR pt_BR.ISO-8859-1" >> /etc/locale.alias

Este arquivo grava os aliases para os locales, isso é para facilitar as configurações.

No diretório /var/lib/locales/supported.d alguns arquivos que configuram os locales que serão gerados, por padrão existem três arquivos “en”, “pt” e “local”. Para nosso caso, pode apagar o “en” e o “pt” deixando apenas o “local”.

Feito isso, edite o arquivo local e deixe seu conteúdo como abaixo:

pt_BR.ISO-8859-1 ISO-8859-1
en_US.ISO-8859-1 ISO-8859-1

Muito bem, configuramos os arquivos necessários para a geração dos locales, agora vamos reconfigurar.

Os comandos abaixo fazem o serviço:

# localedef pt_BR -i pt_BR -f ISO-8859-1
# localedef pt_BR.ISO-8859-1 -i pt_BR -f ISO-8859-1
# localedef pt_BR.ISO8859-1 -i pt_BR -f ISO-8859-1
# dpkg-reconfigure locales
# locale-gen --purge
# locale-gen

Acredito que apenas um desses três comandos fariam o serviço, mas como eu executei os três quando estava configurando o sistema não vou tirar algum deles, é melhor executar a mais e funcionar do que executar a menos e não funcionar.

Reinicie o sistema e execute o comando abaixo para termos certeza que está tudo conforme o desejado.

# locale
LANG=pt_BR
LANGUAGE=pt_BR:pt:en
LC_CTYPE="pt_BR"
LC_NUMERIC="pt_BR"
LC_TIME="pt_BR"
LC_COLLATE="pt_BR"
LC_MONETARY="pt_BR"
LC_MESSAGES="pt_BR"
LC_PAPER="pt_BR"
LC_NAME="pt_BR"
LC_ADDRESS="pt_BR"
LC_TELEPHONE="pt_BR"
LC_MEASUREMENT="pt_BR"
LC_IDENTIFICATION="pt_BR"
LC_ALL=

# locale -a
C
en_US.iso88591
POSIX
pt_BR.iso88591

Agora sim, está tudo como deveria estar. Nosso sistema já está usando ISO-8859-1.

(ISO-8859-1é LATIN1)

Corrigindo o Encoding do Postgres

Bem, esta é a hora do quebra-quebra, vamos lá:

1 – Crie uma nova instância (cluster) de gestão do Postgres:

sudo pg_createcluster -e LATIN1 -d /caminho/do/novoSGDB 8.3
cluster-8.3-2

Feito isto, a porta que o postgres vai operar neste novo SGDB será 5433

Criando SuperUser para administrar o Postgres

[root@srv:~] # su – postgres

[postgres@srv:~] $ createuser -P

Digite o nome da role a ser adicionada: pglinux
Digite a senha para a nova role:
Digite-a novamente:
A nova role poderá criar um super-usuário? (s/n) s
CREATE ROLE

Quer ver os users?

[postgres@srv:~] $ psql
postgres=# \du
Lista de roles
Nome da role | Super-usuário | Cria role | Cria BD | Conexões  | Membro de
————–+—————+———–+———+———–+———–
pglinux       | sim                    | sim            | sim         | ilimitado    |
postgres         | sim                    | sim            | sim         | ilimitado    |
(2 registros)

postgres=# \q

Informações complementares:

http://www.forumdebian.com.br/topico-1583-15.html&sid=64f758c828b395f96e7ae61b4d55897a

http://under-linux.org/7954-configurando-locale-iso-8859-1-no-kubunt-710-gutsy-gibbon.html