mount error(): Host is down

Standard

Hi, if you try mount samba (CIFS) on console:

sudo mount -a

mount: mount error(): Host is down (or similar error)
Dont worry :), enter in FSTAB and fix to version 1:

//IP/sharefolder /mnt/destination cifs username=windowslogin,password=passthislogin,iocharset=utf8,vers=1.0,sec=ntlm  0  0

vers=1.0 has added after error.

Change /etc/fstab (this trick) run:
sudo mount -a
ORRRRR
mount -a (like a root)

MySQL server has gone away

Standard

Seu mysql anda estranho quando você está tentando fazer upload de um arquivo enorme via console (na verdade o restore, ou seja, mysql -u usuario -p nomedobdprarestaurar < arquivo.sql)???

Bem, se a mensagem de erro for esta -> MySQL server has gone away NÃO precisa entrar em pânico, só existem 2 coisas que são feitas e sanam tranquilamente o erro:

1 – entre no /etc/my.cnf (ou arquivo de configuração do mysql) e informe set-variable = max_connections=1500

Isto vai liberar para 1500 conexões concorrentes no mysql.

2 – Se o erro persistir, no mesmo arquivo informe:

max_allowed_packet = 5000000000

Você estará liberando uploads/restore/dumps de 1gb de tamanho.

Depois disso, reinicie o mysql (normalmente service mysql restart) e corra para o abraço.

 

Ah, se quiser ver qual valor ficou setado (só para conferir depois do restart use):

mysql> SHOW VARIABLES LIKE ‘max_allowed_packet’;

'xterm-256color': unknown terminal type no mac os x Lion, Mac os x mountain ou mac os x snow leopard

Standard

Se este erro ocorre com você na tentativa de acesso ao terminal de um servidor Ubuntu, Debian, Mint ou qualquer outro Debian Based usando Mac os X e recebe o erro ‘xterm-256color’: unknown terminal type, entre no servidor de destino aonde o terminal conecta e use o seguinte comando:

apt-get install ncurses-term -y

Isso vai instalar o pacote que faltava.

Interessante que se o erro não for corrigido, por exemplo, um comando inportante como top ou screen não funcionam :(.

Em plataformas Red Hat não rola isto.

Use of uninitialized value in string ne at /usr/sbin/ddclient line 1973.

Standard

Se você está usando DEBIAN-BASED (mind/debian/ubuntu) e toda vez que roda o comando ddclient ele apresenta erro SEUS PROBLEMAS “SE ACABARAM-SE”!

Para sanar, como root faça o seguinte:

rm -rf /var/cache/ddclient/ddclient.cache

Depois rode o comando ddclient, a saída vai ser algo semelhante a:
SUCCESS:  updating SEUHOST.ALGUMACOISAg: good: IP address set to IPDASUAINTERFACEWEB

 

Abraços galera

Como fazer QoS de banda (controle de banda) no Ubuntu Server, Debian, Fedora, Centos, RedHat e etc

Standard

Vamos perceber o seguinte.
Esse how to serve para TODAS as distribuições que rodam como um gateway de internet, sendo somente um caso de particularidade a questão de paths de configurações, como por exemplo, para instalar o CBQ no ubuntu basta usar apt-get install shaper -y.
Isto instalará ele e basta você localizar o path aonde o script shaper está (/etc/init.d/shaper) e seus respectivos confs (/etc/shaper).
No caso das outras distribuições (red hat based -> Centos, Fedora e Red Hat) podemos ver que seu path fica em /etc/sysconfig/cbq. No caso de red hat já existe um arquivo de exemplo que serve para mostrar como as coisas são configuradas no padrão, seu nome é cbq-0000.example e existe outro mas é um caso de utilização do próprio CBQ, o avpkt.
Neste caso iremos criar tudo na mão.
Antes de por a mão na massa temos de entender algumas regras PRIMÁRIAS do CBQ.
Abaixo seguem as mesmas:

O nome dos arquivos de download

cbq-0002-download.in

Todos os arquivos de download devem obedecer a algumas regras na hora de serem nomeados. A primeira delas é que todos os arquivos de download devem começar com cbq-

cbq-0002-download.in

A numeração sempre deve começar a partir do 0002;

cbq-0002-download.in

Todos os arquivos devem terminar com .in

cbq-0002-download.in

O conteúdo dos arquivos de download

DEVICE=eth1,10Mbit,1Mbit
RATE=64Kbit
WEIGHT=6Kbit
PRIO=5
RULE=10.0.0.2
BOUNDED=yes
ISOLATED=yes

DEVICE=eth1,10Mbit,1Mbit – Esta linha contém a interface que sai para os clientes da rede.
RATE=64Kbit – Quantidade de banda destinada ao cliente. Aqui coloca-se qualquer valor que se deseje separar para o IP do cliente.
WEIGHT=6Kbit – Taxa máxima de download que o cliente pode alcançar (com pequenas variações para mais ou para menos).
PRIO=5 – Prioridade com que o IP do cliente deve ser vigiado. O normal é deixar 5.
RULE=10.0.0.2 – IP do cliente a ser vigiado.
BOUNDED=yes – Se setado para yes o usuário estará limitado mesmo que o link esteja com folga.
ISOLATED=yes – Se setado para yes indica que o cliente não poderá emprestar banda pra ninguem.

Arquivos de upload
O nome dos arquivos de upload

cbq-0002-upload.out

Todos os arquivos de upload devem obedecer a algumas regras na hora de serem nomeados. A primeira delas é que todos os arquivos de upload devem começar com cbq-

cbq-0002-upload.out

A numeração sempre deve começar a partir do 0002;

cbq-0002-upload.out

Todos os arquivos devem terminar com .out

cbq-0002-upload.out

O conteúdo dos arquivos de upload

DEVICE=eth1,10Mbit,1Mbit
RATE=64Kbit
WEIGHT=6Kbit
PRIO=5
RULE=10.0.0.2,
BOUNDED=yes
ISOLATED=yes

DEVICE=eth1,10Mbit,1Mbit – Esta linha contém a interface que sai para os clientes da rede.
RATE=64Kbit – Quantidade de banda destinada ao cliente. Aqui coloca-se qualquer valor que se deseje separar para o IP do cliente.
WEIGHT=6Kbit – Taxa máxima de download que o cliente pode alcançar (com pequenas variações para mais ou para menos).
PRIO=5 – Prioridade com que o IP do cliente deve ser vigiado. O normal é deixar 5.
RULE=10.0.0.2, – IP do cliente a ser vigiado. Observe que no arquivo de upload, o IP termina com uma vírgula (,).
BOUNDED=yes – Se setado para yes o usuário estará limitado mesmo que o link esteja com folga.
ISOLATED=yes – Se setado para yes indica que o cliente não poderá emprestar banda pra ninguem.

Iniciando o CBQ

Depois de criadas todas as regras, é preciso compilá-las, com o comando (isto em fedora, redhat e centos):

root@appunixlabs~# cbq compile

No caso do Debian, Ubuntu, Mint e similares:

root@appunixlabs~# /etc/init.d/shaper compile

Basta, depois da compilação, iniciar o CBQ com o comando (isto em fedora, redhat e centos):

root@appunixlabs~# cbq start

No caso do Debian, Ubuntu, Mint e similares:

root@appunixlabs~# /etc/init.d/shaper start

Ou se desejar pará-lo (isto em fedora, redhat e centos):

root@appunixlabs~# cbq stop

No caso do Debian, Ubuntu, Mint e similares:

root@appunixlabs~# /etc/init.d/shaper stop

CBQ na inicialização

Adicione o comando cbq start ao rc.local para que carregue sozinho no ato do boot
(isto em fedora, redhat e centos):

root@appunixlabs~# echo "cbq start" >> /etc/rc.local

No caso do Debian, Ubuntu, Mint e similares:

root@appunixlabs~# echo "/etc/init.d/shaper start" >> /etc/rc.local

Fontes:

http://www.ubuntu.com/ubuntu (ubuntu)
http://www.debian.org/ (debian)
http://centos.org/ (centos)
http://www.projetofedora.org/ (fedora)
http://sourceforge.net/projects/cbqinit/ (cbq)
http://migre.me/5gcMr (cbq sob fedora)

Como fazer upgrade do Debian Etch para o Debian Lenny

Standard

A perfeição com que o Debian e o Ubuntu operam no momento de upgrades de suas versões é impressionante (coisa que sistemas como o poderoso Rhel não recomendam), causando o mínimo de falhas possíveis/imaginárias no sistema que recebeu a atualização.

Neste artigo iremos mostrar como fazer upgrade do Debian Etch para o Debian Lenny. Vamos seguir os passos abaixo:

1 – Atualizar as listas do APT

Primeira coisa que iremos fazer é o backup das listas de repositórios, depois iremos modificar de etch para lenny os valores descritos da versão na lista de Repositórios, veja a versão antes da modificação:

deb http://ftp.us.debian.org/debian/ etch main contrib non-free
deb-src http://ftp.us.debian.org/debian/ etch main contrib non-free
deb http://security.debian.org/ etch/updates main contrib non-free

Agora veja a versão depois modificação:

deb http://ftp.us.debian.org/debian/ lenny main contrib non-free
deb-src http://ftp.us.debian.org/debian/ lenny main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free

2 – Fazendo update dos pacotes

aptitude update
depois
aptitude install apt dpkg aptitude

Se for desktop use isto como adicional
dpkg -l libfam0c102 | grep ^ii
aptitude install libfam0
por fim
aptitude full-upgrade
isto pode também ser usado via apt-get com o comando:
apt-get dist-upgrade

Depois disto reinicie seu servidor/desktop e prepare-se para rodar o Debian em sua versão mais amigável, estável e flexível possível.

Abraços a todos.

Mudando encoding do Postgres para poder usar banco de dados latin1 ou outro e mudar o encoding do Ubuntu ou Debian

Standard

Algo simples que desejamos e a trabalheira grandiosa :(. O que queremos? Mudar o encoding default para Latin1 (se bem que o mundo hoje gira em torno de utf8), assim como mudar locales para PT_BR.

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

###### SE HOUVER ERRO USE:
localedef pt_BR -i pt_BR -f UTF-8
localedef pt_BR -i pt_BR -f LATIN1

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@appunixlabs:~] # su – postgres

[postgres@appunixlabs:~] $ 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@appunixlabs:~] $ 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

 

Obs: Se estiver usando Debian 4 mude o path para aceitar corretamente todas as mudanças

PATH=”/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games”

 

 

Caso seus locales estejam 100% ajustados antes mesmo deste How To você pode usar outros meios, uma vez criado um banco com uma encoding (LATIN1, SQL_ASCII, UTF8), só é possível mudá-lo fazendo um backup e recriando o banco. Embora a documentação do PostgreSQL informe sobre a opção -E no pg_dump, falta um “pulo do gato”, que é o que vai ser apresentado neste passo a passo.

1. Se for migração de servidor, altere o arquivo pg_hba.conf (geralmente em /etc/postgresql/8.x/main/pg_hba.conf) do servidor antigo para incluir a linha:

hostnossl all postgres ipnovoservidor/32 trust

2. Reinicie o PostgreSQL no servidor antigo:

# service postgresql-8.3 restart

3. Faça um “su” para o usuário postgres no servidor novo:

# su postgres

4. Gere o backup no servidor novo (se for o mesmo servidor, a opção h é desnecessária) . UTF8 é um exemplo de encoding, mas de qualquer forma é recomendado como padrão):

$ pg_dump -h hostanti -C -E UTF8 -U postgres bancodedados > bancodedados.sql

5. O pulo do gato: a opção -E do pg_dump gera o ARQUIVO no encoding desejado. Mas a opção -C (que copia a estrutura original), copia fielmente, a ponto de gerar a linha:

CREATE DATABASE foh WITH TEMPLATE = template0 ENCODING = ‘LATIN1’;

com o encoding original, o que gera erro na importação.

O MACETE É TROCAR O ENCODING PARA O CORRETO:

CREATE DATABASE foh WITH TEMPLATE = template0 ENCODING = ‘UTF8’;

Obs.: Se o arquivo for grande, o “mcedit” (que uso muito), não dá conta de abrir, mas o “joe” não reclama.

6. Agora é só rodar:

$ psql -f bancodedados.sql

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: