Início / user-4786

KajMagnus's questions

Martin Hope
KajMagnus
Asked: 2014-04-11 07:33:22 +0800 CST
  • 2

Temos um cluster MySQL (v5.1.61) com dois mestres (e dois escravos). Temos uma tabela logscom uma coluna de chave primária logID. Esta tabela de log cresce bastante e gostaríamos de excluir os dados dela. Então eu escrevi um script que faz isso. — É seguro executar este script em ambos os mestres? Ele exclui apenas os dados. O que estou querendo saber é o que o módulo de replicação do MySQL fará, se a linha que está prestes a excluir já tiver sido excluída? A replicação será interrompida ou é seguro excluir linhas em ambos os mestres? Importa se usamos replicação baseada em linha ou baseada em instrução?

Exemplo: O script de exclusão de dados de log exclui a linha 123 no mestre A. Ao mesmo tempo, o script exclui a mesma linha no mestre B. Então o mestre B lê seu log de retransmissão e vê: "Devo excluir a linha 123, porque foi apagado no Mestre A e eu sou seu escravo. Vamos deletá-lo... ... ...mas já foi!" — agora o que o Mestre B fará? Ele interromperá a replicação, como se houvesse um erro de chave duplicada? Ou vai pensar "Tudo bem, não preciso fazer nada" e está tudo bem.

mysql replication
Martin Hope
KajMagnus
Asked: 2012-01-29 19:39:25 +0800 CST
  • 0

Nos meus logs do PostgreSQL, encontro esta mensagem:

LOG:  invalid magic number 0000 in log file 0, segment 1, offset 16121856

Qual arquivo é o arquivo de log 0? Aqui está o meu diretório pg_xlog:

-bash-4.1$ ll pg_xlog/
total 49160
-rw------- 1 postgres postgres 16777216 Dec  6 06:27 000000010000000000000001
-rw------- 1 postgres postgres 16777216 Jan 21 09:10 000000020000000000000001
-rw------- 1 postgres postgres 16777216 Dec 21 05:29 000000020000000000000002
-rw------- 1 postgres postgres       56 Dec  6 06:30 00000002.history
drwx------ 2 postgres postgres     4096 Dec  6 06:30 archive_status
-bash-4.1$ ll pg_xlog/archive_status/
total 0
-rw------- 1 postgres postgres 0 Dec  6 06:30 00000002.history.ready
postgresql
Martin Hope
KajMagnus
Asked: 2012-01-22 01:27:22 +0800 CST
  • 6

Por algum motivo, meu escravo PostgreSQL não replica mais as alterações no mestre. Ele estava funcionando antes, por um tempo, mas recentemente notei que o conteúdo do banco de dados do escravo é antigo e há erros nos arquivos de log do escravo, ou seja, " número mágico inválido 0000 " e " ID 1 da linha do tempo fora de sequência (após 2) ".

Você tem alguma ideia de como posso resolver isso? Ou por que isso acontece?

Os detalhes seguem.

Mensagens de erro do arquivo de log : (no escravo, pg_log/postgresql-Sat.log)

LOG:  entering standby mode
LOG:  redo starts at 0/1C78848
LOG:  consistent recovery state reached at 0/1C7FA30
LOG:  database system is ready to accept read only connections
LOG:  invalid magic number 0000 in log file 0, segment 1, offset 14942208
LOG:  streaming replication successfully connected to primary
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
FATAL:  terminating walreceiver process due to administrator command
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
...

Logs de transação: (no escravo -- estranho, arquivo de log 0...2... 1 é de janeiro de 2012 , mas 0...2... 2 é de dezembro de 2011 !?)

-bash-4.1$ tree -D pg_xlog/
pg_xlog/
├── [Dec  6  6:27]  000000010000000000000001
├── [Jan 20 21:33]  000000020000000000000001
├── [Dec 21  5:29]  000000020000000000000002
├── [Dec  6  6:30]  00000002.history
└── [Dec  6  6:30]  archive_status
    └── [Dec  6  6:30]  00000002.history.ready

1 directory, 5 files
-bash-4.1$ cat pg_xlog/00000002.history 
1       000000010000000000000001        no recovery target specified

Logs de transação : (no mestre )

-bash-4.1$ tree -D pg_xlog/
pg_xlog/
├── [Dec  6  6:27]  000000010000000000000001
├── [Jan 21  8:55]  000000020000000000000001
├── [Dec 21  5:31]  000000020000000000000002
├── [Dec  6  6:30]  00000002.history
└── [Dec  6  6:30]  archive_status
    └── [Dec  6  6:30]  00000002.history.ready

-bash-4.1$ cat pg_xlog/00000002.history 
1       000000010000000000000001        no recovery target specified

Arquivos de configuração: (no escravo)

---postgresql.conf---
wal_level = hot_standby
...
hot_standby = on
...

---recovery.conf---
standby_mode = 'on'
primary_conninfo = 'host=dw0azewdbpv11danny user=replicator password=...'
recovery_target_timeline = 'latest'

Por fim, sobre o escravo, ps auxmostra que:

Jan20 0:01 postgres: startup process waiting for 000000020000000000000001

Atualização uma semana depois:

Parece haver um bug de replicação para compilações do PostgreSQL com gcc 4.6.0.
http://archives.postgresql.org/pgsql-general/2011-07/msg00686.php
e
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=45d792f70272ed57b932816562f31c2f79426c2a
No entanto, eu adivinharia que esse bug não afetaria o 9.1?

As versões do PostgreSQL devem ser idênticas no mestre e no escravo, e SELECT version() se parece com isso no mestre e no escravo:

-bash-4.1$ psql
psql (9.1.1)
Type "help" for help.

postgres=# SELECT version();
                                                   version                                                    
--------------------------------------------------------------------------------------------------------------
 PostgreSQL 9.1.1 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.5 20110214 (Red Hat 4.4.5-6), 64-bit
(1 row)

Talvez eu também deva mencionar que o mestre atual era um escravo, originalmente, e o escravo atual era o mestre, originalmente. -- Fiz um failover, para testar se funcionou bem.

(Farei essa pergunta nas listas de discussão do Postgres.)

postgresql replication
Martin Hope
KajMagnus
Asked: 2011-12-07 14:43:10 +0800 CST
  • 2

Configurei a replicação master slave no PostgreSQL, seguindo este tutorial:
http://wiki.postgresql.org/wiki/Binary_Replication_Tutorial#Binary_Replication_in_6_Steps

Funcionou bem. Agora promovi o escravo e configurei o mestre original para ser um escravo do novo mestre, novamente seguindo o tutorial no link acima.

No entanto, a replicação não funciona mais. O novo escravo (ou seja, o antigo mestre) registra erros como:

FATAL:  terminating walreceiver process due to administrator command
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0

ou como:

LOG:  unexpected timeline ID 1 in log file 0, segment 1, offset 0

O que estou fazendo errado?

Detalhes a seguir

Quando promovi o ex-escravo, parece que começou uma nova linha do tempo, nº 2:

LOG:  received promote request
FATAL:  terminating walreceiver process due to administrator command
LOG:  record with zero length at 0/18B5148
LOG:  redo done at 0/18B50F0
LOG:  last completed transaction was at log time 2011-12-05 08:39:43.872041+00
LOG:  selected new timeline ID: 2
LOG:  archive recovery complete
LOG:  database system is ready to accept connections

Existem 2 linhas de tempo no pg_xlogdiretório do novo mestre (ou seja, o antigo escravo):

new-master$ tree pg_xlog
    pg_xlog
    ├── 000000010000000000000001
    ├── 000000020000000000000001
    ├── 00000002.history
    └── archive_status
        └── 00000002.history.ready

Desligo o novo master e o novo slave. No novo escravo, eu faço isso:

new-slave$ cd /var/lib/pgsql/9.1/data/
new-slave$ rm *
new-slave$ mkdir pg_xlog ; chmod 700 pg_xlog
new-slave$ rsync -a  --exclude pg_xlog --exclude postgresql.conf --exclude recovery.conf --exclude recovery.done --exclude postmaster.pid --exclude 'server.*'  \
     dw0azewdbpv11danny:/var/lib/pgsql/9.1/data/*  .
new-slave$ ... restore postgresql.conf etcetera from backup,
             ... change settings following instructions in tutorial

Eu começo o novo mestre e o novo escravo. Mas o escravo diz FATAL: encerrando o processo walreceiver :

LOG:  database system was interrupted; last known up at 2011-12-06 21:49:49 UTC
LOG:  creating missing WAL directory "pg_xlog/archive_status"
LOG:  entering standby mode
LOG:  streaming replication successfully connected to primary
LOG:  unexpected timeline ID 1 in log file 0, segment 1, offset 0
FATAL:  terminating walreceiver process due to administrator command
LOG:  unexpected timeline ID 1 in log file 0, segment 1, offset 0
LOG:  unexpected timeline ID 1 in log file 0, segment 1, offset 0
...

O pg_xlog no novo escravo:

new-slave$ tree pg_xlog/
pg_xlog/
├── 000000020000000000000001
└── archive_status

Eu deveria ter rsync pg_xlogtambém? Eu fiz isso: desligar mestre e escravo, rsync pg_xlog, iniciar escravo, iniciar mestre. Então a replicação parece funcionar: o novo escravo diz:

LOG:  database system was shut down at 2011-12-06 22:10:14 UTC
LOG:  entering standby mode
LOG:  consistent recovery state reached at 0/19A4420
LOG:  database system is ready to accept read only connections
LOG:  record with zero length at 0/19A4420
FATAL:  could not connect to the primary server: could not connect to server: Connection refused
                Is the server running on host "dw0azewdbpv11danny" (46.137.XX.YY) and accepting
                TCP/IP connections on port 5432?

LOG:  streaming replication successfully connected to primary

Mas quando faço qualquer coisa no novo mestre:

insert into moo (mää) values (23);

Em seguida, a replicação falha. O novo escravo diz:

LOG:  could not receive data from client: Connection reset by peer
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
FATAL:  terminating walreceiver process due to administrator command
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0

O mestre diz:

LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
LOG:  could not receive data from client: Connection reset by peer

Mas eu não reiniciei nenhuma conexão!

Se eu reiniciar o escravo, ele falha instantaneamente: FATAL: encerrando o processo do walreceiver :

LOG:  database system was shut down in recovery at 2011-12-06 22:24:37 UTC
LOG:  entering standby mode
LOG:  consistent recovery state reached at 0/19A4420
LOG:  database system is ready to accept read only connections
LOG:  redo starts at 0/19A4420
LOG:  record with zero length at 0/19A4510
LOG:  streaming replication successfully connected to primary
LOG:  out-of-sequence timeline ID 1 (after 2) in log file 0, segment 1, offset 0
FATAL:  terminating walreceiver process due to administrator command

Arquivos de configuração:

---- new master & slave: ----
wal_level = hot_standby
#archive_mode = off   (default)

---- new master: ----
max_wal_senders = 5
wal_keep_segments = 100

---- new slave: ----
hot_standby = on

---- recovery.conf, on the new slave: ----
standby_mode = 'on'
primary_conninfo = 'host=dw0azewdbpv11danny user=... password=...'

O que estou fazendo errado? Como posso transformar o antigo mestre em escravo?

(É melhor se eu não deletar todos os arquivos no novo escravo antes de mim rsync?
Ou devo executar initdbno novo escravo antes de mim rsync?
Você sabe se existe algum tutorial sobre como converter um mestre em um escravo? )

Atenciosamente, KajMagnus

postgresql replication
Martin Hope
KajMagnus
Asked: 2011-11-30 19:59:20 +0800 CST
  • 44

Eu configurei ssl = on( postgresql.confe instalei um certificado etcetera). Isso garante que todos os clientes sempre se conectarão por SSL?

(Ou seja ssl = on, torna impossível conectar-se sem criptografia SSL?)

Existem outras maneiras de garantir que todos os clientes sempre se conectem por SSL/TLS?

postgresql