Usando Recuperação de Desastre de Alta Disponibilidade do DB2 com Tecnologia Tivoli Systems Automation e Reliable Scalable Cluster

Resolução de problemas da solução de alta disponibilidade do DB2

O recurso Alta Disponibilidade (HA) do IBM DB2 , introduzido no IBM DB2 9.5 para Linux, UNIX e Windows possibilita um novo nível de integração entre o servidor de dados e o software de gerenciamento de cluster, fornecendo uma estrutura de automação unificada de Recuperação de Desastre de Alta Disponibilidade (HADR). Neste tutorial, obtenha uma introdução a esta solução integrada e aprenda sobre ferramentas de diagnóstico úteis para trabalhar com o DB2 e o Tivoli Systems Automation, uma parte fundamental da solução. Alcance o nível mais alto possível de desempenho e confiabilidade para os seus dados, ao entender como resolver problemas e tratar de algumas questões.

Este tutorial se destina a leitores que têm conhecimento de HADR, mas podem ser iniciantes na solução integrada—DB2 com IBM Tivoli® Systems Automation (TSA) e IBM Reliable Scalable Cluster Technology (RSCT).

Dipali Kapadia, Software Developer, IBM

Photo of Dipali KapadiaDipali Kapadia está na IBM há quatro anos. Atualmente, atua na DB2 Continuing Engineering for High Availability (HA), trabalhando nos problemas de produção e aprimoramentos dos componentes de HA. Dipali possui bacharelado em engenharia, com especialização em Design de Software pela Universidade de McMaster. Dipali já escreveu um artigo para o developerWorks.



Michelle Chiu, DB2 Continuing Engineering Software Developer, IBM

Michelle ChiuMichelle Chiu faz parte da equipe de HA do DB2 Continuing Engineering desde a introdução da solução integrada no release DB2 9.5. Ela vem ajudando os clientes na adoção dessa solução e impulsionou várias melhorias em funcionalidade e capacidade de manutenção. Michelle possui bacharel com distinção em matemática pela Universidade de Waterloo, com especialização em Ciência da Computação - Bioinformática.



26/Out/2010

Introdução ao recurso de alta disponibilidade do DB2

No mundo atual, em ritmo acelerado, tempo é dinheiro. E o mais importante: tempo de inatividade é dinheiro perdido. Por isso, a alta disponibilidade é tão importante para todos os negócios, grandes e pequenos. Um banco de dados altamente disponível garante que, em caso de falha de qualquer parte da solução de banco de dados, o sistema passe automaticamente para um backup. Entretanto, sem um gerenciador do cluster, esse "failover" não é automático. É necessário contatar o administrador de banco de dados e ele tem que ir até o servidor de banco de dados e emitir manualmente um comando takeover. É aí que entra o poder da solução integrada de HA.

A solução integrada de HA, chamada de recurso de alta disponibilidade do DB2, foi introduzida no DB2 9.5. Nessa solução, um gerenciador do cluster, o Tivoli Systems Automation/Reliable Scalable Cluster Technology (TSA/RSCT), vem no pacote do DB2 para Linux, UNIX e Windows Workgroup Edition e Enterprise Edition. É responsável por monitorar os recursos integrais de banco de dados e, em caso de falha, realizar a ação adequada. As principais vantagens da solução integrada são:

  • É simples: o DBA não precisa aprender um novo conjunto de comandos de gerenciador do cluster para gerenciar os recursos.
  • É integrado: usando a ferramenta db2haicu, o DB2 interage de forma totalmente integrada com o TSA, acionando as ações corretas. O DB2 vem com o TSA/RSCT no pacote. À medida que você aplica fix packs ao DB2, os fix packs atualizam automaticamente o nível do TSA/RSCT para obter correções críticas do TSA/RSCT, se necessário.

Em uma configuração típica de solução integrada de HA, o TSA/RSCT é instalado nos dois hosts. É responsável pelo monitoramento de entidades como interfaces de rede, instâncias do DB2 e bancos de dados de HADR. O cliente se conecta ao banco de dados primário usando a rede pública, por meio de um endereço de IP virtual. Em caso de falha do host primário, esse endereço de IP virtual passa para o host de espera. Do ponto de vista do cliente, não há tempo de inatividade, já que a transição é automática. Se há duas interfaces de rede em cada host, pode-se configurar uma rede privada exclusivamente para a replicação de HADR.

Figura 1. Solução integrada de HA
Solução integrada de HA

Pré-requisitos

A solução integrada de HA usando o TSA/RSCT como gerenciador do cluster está disponível para uso em Linux e AIX no DB2 9.5 para Linux, UNIX e Windows e versões posteriores e no Solaris na V9.7 e posteriores.


Ferramentas de diagnóstico no DB2 e no TSA/RSCT

Esta seção identifica as ferramentas disponíveis no DB2 e no TSA/RSCT que podem ser usadas para identificar e resolver questões de resolução de problemas que podem surgir em um ambiente integrado de HA. É possível que DBAs com experiência ou usuários experientes do TSA/RSCT já estejam familiarizados com várias dessas ferramentas. Entretanto, só é possível limitar e identificar os problemas subjacentes usando esses utilitários em conjunto. Esta seção descreve o papel de cada ferramenta na arquitetura de HA.

Ferramentas do DB2

Parâmetros de configuração do banco de dados

Para obter parâmetros relacionados à HADR referentes aos pares de bancos de dados (o servidor principal e o servidor em espera), execute o comando a seguir em cada host:

db2 get db cfg for <dbname> | grep HADR

A Listagem 1 mostra um exemplo da saída.

Listagem 1. Saída referente aos parâmetros de configuração relacionados à HADR
(db2inst1@host1) /home/db2inst1 $ db2 get db cfg for HADRDB | grep HADR            
 HADR database role                                      = STANDARD
 HADR local host name                  (HADR_LOCAL_HOST) = host1
 HADR local service name                (HADR_LOCAL_SVC) = 50001
 HADR remote host name                (HADR_REMOTE_HOST) = host2
 HADR remote service name              (HADR_REMOTE_SVC) = 50002
 HADR instance name of remote server  (HADR_REMOTE_INST) = db2inst1
 HADR timeout value                       (HADR_TIMEOUT) = 120
 HADR log write synchronization mode     (HADR_SYNCMODE) = SYNC
 HADR peer window duration (seconds)  (HADR_PEER_WINDOW) = 300

A função do banco de dados de HADR é a função verdadeira do banco de dados. Seus possíveis valores são PRIMARY, STANDBY e STANDARD. Sempre é recomendável comparar isso com a saída de lssam (um comando do TSA/RSCT) para se certificar de que esses dados sejam consistentes. A Tabela 1 mostra a correspondência entre a saída de lssam e a função do banco de dados de HADR.

Tabela 1. Relação entre a função de HADR e o OpState
Função do banco de dados de HADRRecurso de HADR OpState do lssam
PrimaryOnline
StandbyOffline
StandardOffline

O utilitário db2haicu usa esses valores de parâmetro para gerar o nome do recurso de cluster. De forma semelhante, pode usar esses valores ao verificar se um recurso já existe no cluster. Preste muita atenção nessas configurações ao resolver problemas de configuração.

A ferramenta db2haicu impõe certos requisitos de nomenclatura em relação aos parâmetros de HADR. A Tabela 2 resume esses requisitos de nomenclatura.

Tabela 2. Limitações de nomenclatura
Parâmetro de banco de dadosHADRdb2haicu
HADR_LOCAL_HOSTQualquer nome que possa ser resolvido em relação ao nome do host (por exemplo: nome abreviado, nome completo do domínio, endereço de IP, alias)Nome abreviado; nome completo do domínio (LI74662 em V95FP5, IC62233 em V97FP1)
HADR_REMOTE_HOSTQualquer nome que possa ser resolvido em relação ao nome do host (por exemplo: nome abreviado, nome completo do domínio, endereço de IP, alias)Nome abreviado; nome completo do domínio (LI74662 em V95FP5, IC62233 em V97FP1)
HADR_REMOTE_INSTNão faz distinção entre maiúsculas e minúsculasFaz distinção entre maiúsculas e minúsculas
HADR_PEER_WINDOW0 ou maisMaior que 0

Utilitário db2pd

Esse utilitário pode ser executado da seguinte forma:

db2pd hadr db <nome>

A Listagem 2 mostra um exemplo da saída.

Listagem 2. Saída de db2pd
(db2inst1@host2) /home/db2inst1$ db2pd hadr db hadrdb

Database Partition 0 -- Database HADRDB -- Standby -- Up 0 days 00:16:44 -- 
Date 08/04/2010 17:08:05

HADR Information:
Role    State                SyncMode HeartBeatsMissed   LogGapRunAvg (bytes)
Standby RemoteCatchup        Sync     0                  365349536

ConnectStatus ConnectTime                           Timeout
Connected     Wed Aug  4 16:51:22 2010 (1280955082) 120

PeerWindowEnd                         PeerWindow
Null (0)                              300

LocalHost                                LocalService
host2                                    50002

RemoteHost                               RemoteService      RemoteInstance
host1                               	 50001              db2inst1

PrimaryFile  PrimaryPg  PrimaryLSN
S0029674.LOG 0          0x000000001F060B7B

StandByFile  StandByPg  StandByLSN         StandByRcvBufUsed
S0008608.LOG 0          0x000000000A8D3EE1 2%

O utilitário db2pd acessa diretamente o estado de memória de sistema do DB2. Esta é a função correta do banco de dados. Em certos casos de erro ou cenários sensíveis ao tempo, pode haver uma discrepância entre a forma que o gerenciador do cluster vê o banco de dados e a forma que o banco de dados se vê. Verificar o estado verdadeiro com essa ferramenta é uma boa prática.

db2diag.log

Normalmente esse log se encontra em ~/sqllib/db2dump/db2diag.log. O local pode ser configurado usando o parâmetro de configuração do gerenciador de banco de dados DIAGPATH .

Esse log é o principal log de diagnóstico referente à instância e ao banco de dados do DB2. Registra as mensagens de diagnóstico em níveis diferentes de notificação (info/warning/error/severe). O nível padrão para esse log é 3 (warning). O nível de registro pode ser definido por meio da configuração DIAGLEVEL . Ao resolver um problema reproduzível, é uma boa prática mudar o DIAGLEVEL para 4, para obter uma captura máxima de dados.

db2 update dbm cfg using DIAGLEVEL 4

Examinando o db2diag.log, é possível ver um histórico de funções de HADR, chamadas de interação do db2haicu com o gerenciador do cluster e algumas mensagens de erro do gerenciador do cluster. Executedb2diag h para obter opções para filtrar e formatar esse log.

As mensagens relacionadas ao db2haicu e ao código de HA integrado têm o prefixo "sqlha". Já que a solução integrada chama implicitamente as chamadas do TSA/RSCT de forma "oculta", alguns erros são passados diretamente do gerenciador do cluster. Esses erros são lançados no db2diag.log com uma sintaxe especial (### --- ####-###). O ####-### é um código de erro do RSCT. É possível procurar esses erros no centro de informações do RSCT (consulte Recursos).

Se você conseguir distinguir a origem do erro, essa informação ajudará o suporte IBM a focar o componente correto.

A Listagem 3 mostra um exemplo da saída de db2diag.log.

Listagem 3. Saída de db2diag.log
2010-07-28-09.54.04.342244-240 E1753286A844       LEVEL: Error
PID     : 589910               TID  : 1           PROC : db2haicu
INSTANCE: db2inst1             NODE : 000
EDUID   : 1
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure, sqlhaDeleteResourceGroup, pro
be:300
MESSAGE : ECF=0x90000548=-1879046840=ECF_SQLHA_DELETE_GROUP_FAILED
          Delete group failed
DATA #1 : String, 35 bytes
Error during vendor call invocation
DATA #2 : unsigned integer, 4 bytes
30
DATA #3 : String, 29 bytes
db2_db2inst1_db2inst1_HADRDB-rg
DATA #4 : unsigned integer, 8 bytes
1
DATA #5 : signed integer, 4 bytes
8
DATA #6 : String, 101 bytes
Line # : 7650---2621-008 Failed to update resource because of configuration 
data replication errors.
DATA #7 : Object [PD_TYPE_STRING] not dumped
Address: 0x00000001100A90FD Size: 0 Reason: Zero-length data

Para ver rapidamente a sequência das mudanças de função de HADR, emita o seguinte comando:

cat db2diag.log | grep i "hadr state"

As Listagens 4 e 5 mostram a saída dos dois servidores.

Listagem 4. Saída do estado de HADR em db2diag.log no servidor principal
CHANGE  : HADR state set to None (was None)
CHANGE  : HADR state set to P-Boot (was None)
CHANGE  : HADR state set to P-RemoteCatchupPending (was P-Boot)
CHANGE  : HADR state set to P-RemoteCatchup (was P-RemoteCatchupPending)
CHANGE  : HADR state set to P-NearlyPeer (was P-RemoteCatchup)
CHANGE  : HADR state set to P-Peer (was P-NearlyPeer)
CHANGE  : HADR state set to P-RemoteCatchupPending (was P-Peer)
CHANGE  : HADR state set to P-RemoteCatchup (was P-RemoteCatchupPending)
CHANGE  : HADR state set to P-NearlyPeer (was P-RemoteCatchup)
CHANGE  : HADR state set to P-Peer (was P-NearlyPeer)
Listagem 5. Saída do estado de HADR em db2diag.log no servidor em espera
CHANGE  : HADR state set to None (was None)
CHANGE  : HADR state set to S-Boot (was None)
CHANGE  : HADR state set to S-LocalCatchup (was S-Boot)
CHANGE  : HADR state set to S-RemoteCatchupPending (was S-LocalCatchup)
CHANGE  : HADR state set to S-RemoteCatchupPending (was S-RemoteCatchupPending)
CHANGE  : HADR state set to S-RemoteCatchup (was S-RemoteCatchupPending)
CHANGE  : HADR state set to S-NearlyPeer (was S-RemoteCatchup)
CHANGE  : HADR state set to S-Peer (was S-NearlyPeer)

Utilitário db2support

Esse utilitário coleta informações detalhadas provenientes do ambiente de instância do DB2 e do sistema operacional. Em caso de problemas de HADR, normalmente você deve executar db2support com a tag -d para coletar informações relacionadas ao banco de dados. A equipe do suporte IBM o orientará durante o uso do utilitário quando necessário.

Ferramentas de TSA/RSCT

A maioria dos dados coletados pelo usuário estará relacionada ao DB2, ao passo que os dados necessários do TSA/RSCT estarão faltando. Esta seção descreve como obter informações relevantes sobre o TSA/RSCT para ajudar a descobrir por que o gerenciador do cluster se comporta de uma determinada forma.

Comando lssam

O comando lssam é usado para obter a captura instantânea do estado dos recursos de cluster. A Figura 2 (lssam explicado) disseca e explica um exemplo típico de saída desse comando. Cada grupo de recursos tem um estado nominal —o estado desejado. Um grupo de recursos pode conter um membro de grupo de recursos ou mais, e cada grupo de recursos contém um recurso ou mais. A Figura 2 mostra três grupos de recursos — um para a instância local, um para a instância remota e um para o banco de dados de HADR. O recurso OpState é o estado real do recurso, e a classe de recurso é a classe de TSA à qual ele pertence. O nome do recurso também contém um nome de host, que é o nó onde o recurso pode executar.

Figura 2. lssam explicado
lssam explicado

O TSA/RSCT monitora a instância do DB2 e o comportamento do banco de dados executando vários scripts de DB2 em um intervalo especificado. Os scripts se encontram em /usr/sbin/rsct/sapolicies/db2 nos dois hosts de um par de HADR. Nesta solução, há seis scripts principais. Os scripts usam um utilitário do DB2 chamado db2gcf para interagir com a instância e o banco de dados de HADR. Consulte o centro de informações do DB2 para obter mais informações sobre o db2gcf (consulte Recursos para ver o link).

O nome de cada script contém a versão atual do DB2. Para os fins deste tutorial, usaremos a V9.7.

Script do monitor de instância (db2V97_monitor.ksh)

O script do monitor de instância é responsável pelo monitoramento do status da instância. Por padrão, o TSA/RSCT chama esse script em um intervalo especificado em ambos os nós do par de HADR. Com base nisso, o OpState dos recursos de instância é atualizado. Na Figura 2, os recursos de instância são db2_db2inst1_host1_0-rs e db2_db2inst1_host2_0-rs.

Tabela 3. Códigos de retorno do script de monitor de instância
OpStateCódigo de retorno do scriptSignificado (ponto de vista do DB2)
Online1A instância é iniciada.
Offline2A instância não é iniciada ou ocorreu um problema ao obter o status.

Script de início de instância (db2V97_start.ksh)

O script de início de instância é responsável pela inicialização da instância do DB2 e pela ativação dos bancos de dados. Se necessário, o script de início também pode fazer a reintegração.

Script de parada da instância (db2V97_stop.ksh)

O script de parada da instância é responsável por parar a instância. É usado para parar deliberadamente a instância quando acontece algo errado no respectivo host.

Script do monitor de HADR (hadrV97_monitor.ksh)

O script do monitor de HADR é responsável pelo monitoramento do status do banco de dados de HADR. Por padrão, o TSA/RSCT chama esse script a cada 29 segundos em ambos os hosts do par de HADR. Com base nisso, o OpState dos recursos de HADR é atualizado. NaFigura 2, o recurso de HADR é db2_db2inst1_db2inst1_HADRDB-rs.

Tabela 4. Códigos de retorno do script de monitor de HADR
OpStateCódigo de retorno do scriptSignificado (ponto de vista do DB2)
Online1O HADR é primário.
Offline2O HADR está em espera ou ocorreu um problema ao obter o status.

Script de início de HADR (hadrV97_start.ksh)

O script de início de HADR é responsável por iniciar o HADR em um banco de dados de espera já existente, para fazer com que assuma a função de primário.

Script de parada de HADR (hadrV97_stop.ksh)

O script de parada de HADR é responsável por parar o HADR. É usado para parar deliberadamente o HADR caso ocorra algo errado no respectivo host.

syslog

O syslog mostra um histórico do gerenciamento de recursos pelo TSA/RSCT. Também mostra certos tipos de erros do TSA/RSCT, caso existam. Uma análise combinada do syslog com db2diag.log pode mostrar a sequência de eventos que ocorreram durante um cenário de falha.

Em sistemas Linux, o syslog se encontra em /var/log/messages/syslog.out.

Em sistemas AIX, o syslog se encontra em /tmp/syslog.out.

Dependendo da forma de customização do seu sistema, o syslog pode estar em outro lugar. Para modificar isso, olhe no syslog.conf. Esse arquivo pode estar sob /etc.

Quando usado em combinação com db2diag.log, o syslog pode ser uma ferramenta de depuração poderosa. A comparação cruzada de registros chave de data e hora entre dois logs pode ajudar bastante na reconstrução da sequência de eventos em um cenário de failover.

Por exemplo: a Listagem 6 mostra uma instância eliminada por volta das 22:05:44.

Listagem 6. Instância eliminada
db2inst1@host1:~> date
Wed Aug  4 22:05:44 EDT 2010
db2inst1@host1:~> db2_kill
ipclean: Removing DB2 engine and client's IPC resources for db2inst1.

O TSA/RSCT deve chamar o script de início. Confira no syslog por volta das 22:05:44 para confirmar.

Listagem 7. Script de início
Aug  4 22:05:53 host1 db2V97_start.ksh[9540]: Entered /usr/sbin/rsct/sapolicies/db2
                      /db2V97_start.ksh, db2inst1, 0
Aug  4 22:05:53 host1 db2V97_start.ksh[9541]: Able to cd to /home/db2inst1/sqllib : 
                      /usr/sbin/rsct/sapolicies/db2/db2V97_start.ksh, db2inst1, 0
Aug  4 22:05:53 host1 db2V97_start.ksh[9551]: 1 partitions total: /usr/sbin/rsct
                      /sapolicies/db2/db2V97_start.ksh, db2inst1, 0
Aug  4 22:06:00 host1 db2V97_start.ksh[9774]: Returning 0 from /usr/sbin/rsct
                      /sapolicies/db2/db2V97_start.ksh ( db2inst1, 0)

A instância foi iniciada com êxito. Confira no db2diag.log por volta das 22:06:00 para confirmar.

Listagem 8. Instância iniciada
2010-08-04-22.05.57.453549-240 E10236E305          LEVEL: Event
PID     : 9620                 TID  : 47284539421760PROC : db2star2
INSTANCE: db2inst1             NODE : 000
FUNCTION: DB2 UDB, base sys utilities, DB2StartMain, probe:911
MESSAGE : ADM7513W  Database manager has started.
START   : DB2 DBM

O TSA/RSCT deve chamar o script de início de HADR. Confira no syslog por volta das 22:06:00 para confirmar.

Listagem 9. Script de início de HADR
Aug  4 22:06:14 host1 /usr/sbin/rsct/sapolicies/db2/hadrV97_start.ksh[9948]: ...returns 0
Aug  4 22:06:14 host1 /usr/sbin/rsct/sapolicies/db2/hadrV97_start.ksh[9949]: Returning 0
                      : db2inst1 db2inst1 HADRDB

Iniciado o HADR, ele tentará atingir o estado de PEER. Confira no db2diag.log por volta das 22:06:00, procurando a palavra-chave "HADR state."

Listagem 10. Verificar o estado HADR PEER
2010-08-04-22.06.01.254052-240 E11446E359          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to None (was None)

2010-08-04-22.06.01.256495-240 E12922E361          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to P-Boot (was None)

2010-08-04-22.06.01.964755-240 E14817E379          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to P-RemoteCatchupPending (was P-Boot)

2010-08-04-22.06.03.184782-240 E22305E388          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to P-RemoteCatchup (was P-RemoteCatchupPending)

2010-08-04-22.06.03.304770-240 E23429E378          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to P-NearlyPeer (was P-RemoteCatchup)

2010-08-04-22.06.03.317330-240 E23808E369          LEVEL: Event
PID     : 9634                 TID  : 47103946516800PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 27                   EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to P-Peer (was P-NearlyPeer)

lsrsrc

Não há outros comandos do TSA/RSCT que são usados para exibir atributos específicos de um recurso. lsrsc é um comando útil para entender o funcionamento interno de vários recursos que pertencem a uma classe de recurso específica. As classes mais comuns com as quais você trabalharia são IBM.Application, IBM.ServiceIP e IBM.Test. Essas classes são criadas pelo TSA/RSCT e agem como uma "porta" para que outros produtos interajam com o gerenciador do cluster.

Recurso de cluster

Mais frequentemente, os recursos de cluster pertencem à classe IBM.Application. Os recursos de cluster são criados para representar entidades como a instância do DB2 ou de HADR. Quando o db2haicu é executado, ele usa comandos do TSA/RSCT para criar esses recursos. Para cada recurso de cluster, há vários atributos. Os atributos dos comandos start, stop e monitor estão vinculados aos scripts do DB2 abordados na seção "comando lssam". É dessa forma que o TSA/RSCT sabe o que deve chamar para administrar um recurso.

Esse utilitário pode ser executado da seguinte forma:

lsrsrc -s "Name like 'db2_db2inst1%" IBM.Application
Listagem 11. Executando o utilitário
db2inst1@host1:~> lsrsrc -s "Name like 'db2_db2inst1_db2inst1_HADRDB-rs' AND 
                  NodeNameList={'host1'}" IBM.Application
Resource Persistent Attributes for IBM.Application
resource 1:
Name                  = "db2_db2inst1_db2inst1_HADRDB-rs"

ResourceType 	         = 0
AggregateResource     = "0x2028 0xffff 0xa5530134 0xe14e5051 0x91c6ee58 
                         0xa6a94e38"
StartCommand          = "/usr/sbin/rsct/sapolicies/db2/hadrV97_start.ksh 
                         db2inst1 db2inst1 HADRDB"               
StopCommand           = "/usr/sbin/rsct/sapolicies/db2/hadrV97_stop.ksh 
                         db2inst1 db2inst1 HADRDB"
MonitorCommand        = "/usr/sbin/rsct/sapolicies/db2/hadrV97_monitor.ksh 
                         db2inst1 db2inst1 HADRDB"
MonitorCommandPeriod  = 21
MonitorCommandTimeout = 29
StartCommandTimeout   = 330
StopCommandTimeout    = 140
UserName              = "root"
RunCommandsSync       = 1
ProtectionMode        = 1
HealthCommand         = ""
HealthCommandPeriod   = 10
HealthCommandTimeout  = 5
InstanceName          = ""
InstanceLocation      = ""
SetHealthState        = 0
MovePrepareCommand    = ""
MoveCompleteCommand   = ""
MoveCancelCommand     = ""
CleanupList           = {}
CleanupCommand        = ""
CleanupCommandTimeout = 10
ProcessCommandString  = ""
ResetState            = 0
ReRegistrationPeriod  = 0
CleanupNodeList       = {}
MonitorUserName       = ""
ActivePeerDomain      = "hadr_domain"
NodeNameList          = {"host1"}

Recurso de sinalizador

Os recursos de sinalizador pertencem à classe IBM.Test. Os recursos de sinalizador são temporários. São criados pelo código do DB2 e usados para comunicar ações em andamento ao TSA. Ao final da ação, devem ser limpos automaticamente. Se um sinalizador "sobra", isso indica que aconteceu algo errado. Esse sinalizador é criado pelo novo banco de dados primário como uma indicação para o antigo banco de dados primário de que ele deve se "reintegrar", ou seja, mudar a função para se tornar espera. Verificar os sinalizadores é um bom método de depuração; entretanto, em cenários normais, não é necessário monitorar isso.

Esse utilitário pode ser executado da seguinte forma:

lsrsrc IBM.Test
Listagem 12. Executando o utilitário
db2inst1@host2:~> lsrsrc IBM.Test
Resource Persistent Attributes for IBM.Test
resource 1:
        Name              = "db2_HADRDB_host1_Reintegrate_db2inst1_db2inst1"
        ResourceType      = 0
        AggregateResource = "0x3fff 0xffff 0x00000000 0x00000000 0x00000000    
                             0x00000000"
        ForceOpState      = 0
        TimeToStart       = 0
        TimeToStop        = 0
        WriteToSyslog     = 0
        MoveTime          = 0
        MoveFail          = 0
        ForceMoveState    = 0
        ActivePeerDomain  = "hadr_domain"
        NodeNameList      = {"host2"}

getsadata

É equivalente ao db2support do ponto de vista do TSA/RSCT. Para coletar o máximo de dados, execute o getsadata com o sinalizador "all". Esse utilitário deve ser executado como raiz. O suporte IBM pode orientá-lo em relação a isso.


Resolução de problemas

Frequentemente, um cliente encontra um problema, mas ao abrir um PMR, perde a oportunidade de coletar dados específicos em relação ao momento e ao cenário. O objetivo desta seção é ajudar a identificar a categoria do problema que você está tendo, para que possa coletar as informações de diagnóstico adequadas. Isso ajudará o suporte IBM a resolver o problema com mais eficiência. Em alguns casos, pode até mesmo ajudá-lo a resolver o problema sozinho.

Depois de estudar os problemas que o cliente teve nos últimos dois anos, determinamos quatro categorias principais de problemas:

As seções a seguir examinam cada uma dessas áreas.

Failover inesperado

Em um failover inesperado, ocorre um evento no primário que não deve fazer com que o banco de dados de espera assuma o controle. Entretanto, o failover ocorre, o que tem como resultado uma possível perda de dados e indisponibilidade.

Considerações:

  • A solução está se comportando como deveria?
    • Cenários nos quais se espera um failover:
      • A máquina primária fica inativa (por exemplo: é desligada)
      • Falha da rede pública da máquina primária
      • Falha da instância primária
  • Cenários nos quais o failover não deve ocorrer:
    • Eliminação da instância (por exemplo: db2_kill)
    • Perda da rede privada
  • Por que ocorreu um failover?
    • O estado original do recurso de banco de dados de HADR não é primário
    • O script de início da instância e do HADR não são chamados
    • O script de início da instância e do HADR não funcionam corretamente

Considere a função original do recurso de banco de dados de HADR

O TSA/RSCT garante que o recurso de banco de dados de HADR esteja on-line (primário) em um host e off-line (de espera) no outro. Se isso não acontece, aquilo que parece um failover pode ser, na verdade, uma tentativa do TSA de garantir que o recurso esteja on-line em um host disponível. Há várias formas de verificar a função do banco de dados de HADR:

  • Verifique o db2diag.log no primário original. (Consulte a seção "db2diag.log" para ver mais detalhes sobre isso.) Para começar: o estado do HADR é primário? Ele permanece dessa forma, levando ao evento de failover?
  • Verifique os parâmetros de configuração do banco de dados no primário original. (Consulte a seção "Parâmetros de configuração do banco de dados".). Qual é a função do banco de dados? Corresponde ao Opstate do recurso de banco de dados de lssam ?
  • Verifique a saída de db2pd no primário original. (Consulte a seção "Utilitário db2pd" para ver detalhes sobre isso.) Qual é a função do banco de dados? Corresponde ao Opstate do recurso de banco de dados de lssam ?

A função original era "primário". E agora?

A primeira e mais óbvia questão a considerar é: algum script de início foi iniciado? Lembre-se de que, se a instância "morreu", consequentemente o seu banco de dados de HADR também estaria indisponível. Assim sendo, o TSA/RSCT chamaria os scripts de início da instância e do HADR. Se somente o banco de dados de HADR fica indisponível, só o script de início de HADR seria chamado.

  • Abra o syslog no primário original.
  • Você está vendo chamadas de scripts?
    • Sim - Continue depurando.
    • Não - Isso é muito suspeito. Conforme o mencionado na seção " syslog", o syslog contém um histórico do gerenciamento de recursos realizado pelo TSA. Você deve ver o script de monitor sendo chamado em intervalos específicos. Pergunte a você mesmo: "O cluster está configurado corretamente? A criação de log está ativada e no nível correto?"
  • Você está vendo uma chamada de script de início? Procure o script de monitor de instância "Returning 2." Logo depois disso, você deve ver a chamada do script de início de instância.
    • Sim - Continue depurando.
    • Não - Provavelmente é um problema do TSA/RSCT. Entre em contato com o suporte IBM.
  • O script de início retornou corretamente (em outras palavras, "Returning 0")?
    • Sim - Isso significa que a instância iniciou corretamente. Entretanto, alguma coisa aconteceu logo depois desse ponto para provocar um failover. Confira no db2diag.log por volta desse período para ver se houve outros erros.

Falha na ativação do DB2

Uma vez iniciada a instância, o banco de dados deve ser ativado para que o HADR continue a replicação. A ativação de um banco de dados inconsistente falharia. O banco de dados ficaria inconsistente se a instância travasse (por exemplo: em caso de eliminação da instância com db2_kill). Se o banco de dados está com AUTORESTART ativado, uma reinicialização é acionada e a recuperação de falha é realizada, fazendo com que o banco de dados volte a um estado consistente.

  • Certifique-se de que AUTORESTART esteja ativado e tente ativar manualmente.
    db2 get db cfg for <database> | grep AUTORESTART
    db2 activate db <database>

Tempo limite do db2gcf

O script de início da instância usa o utilitário db2gcf para iniciar a instância. Se o db2gcf expira, você deve ver a mensagem no db2diag.log indicando isso.

Listagem 13. Mensagem no db2diag.log
2010-06-05-02.05.33.824563-240 I18731842A257      LEVEL: Error 
PID     : 1831554              TID : 1 
FUNCTION: DB2 Common, Generic Control Facility, GcfCaller::start, probe:40 
MESSAGE : ECF=0x9000028C Timeout occured while calling a GCF interface function

Tente iniciar a instância manualmente e veja quanto tempo isso leva (db2start).

Tente iniciar a instância usando o db2gcf sem especificar um tempo de espera e veja quanto tempo isso leva. O tempo de início varia de acordo com o número de partições do ambiente; entretanto, não deve passar de alguns segundos por partição.

db2gcf u i <instance>

Falha do db2start

Se a instância iniciou corretamente, com certeza há mensagens no db2diag.log indicando isso.

Listagem 14. Mensagem no db2diag.log
2010-08-04-22.05.57.453549-240 E10236E305          LEVEL: Event
PID     : 9620                 TID  : 47284539421760PROC : db2star2
INSTANCE: db2inst1             NODE : 000
FUNCTION: DB2 UDB, base sys utilities, DB2StartMain, probe:911
MESSAGE : ADM7513W  Database manager has started.
START   : DB2 DBM

Tente iniciar a instância manualmente para ver se dá certo.

Erros do TSA/RSCT

O DB2 interage com o gerenciador do cluster emitindo comandos do TSA/RSCT. Se esses comandos não funcionam corretamente, deve haver uma entrada de log com um identificador específico em db2diag.log. (Consulte a seção "db2diag.log" para ver detalhes sobre isso.)

A função não era de primário. E agora?

A principal questão nesse caso é: por que a função original não é de primário? Um problema maior está acontecendo?

Quando você faz um cluster de uma instância usando o db2haicu, os recursos do TSA/RSCT são criados, bem como as dependências entre eles. Para ver as dependências no seu cluster, pode-se usar o comando lsrel .

O utilitário pode ser executado da seguinte forma:

lsrel -Ab
Listagem 15. comando lsrel
db2inst1@host1:~> lsrel -Ab
Displaying Managed Relationship Information:
All Attributes

Managed Relationship 1:
        Class:Resource:Node[Source] = IBM.Application:db2_db2inst1_host1_0-rs
        Class:Resource:Node[Target] = {IBM.Equivalency:db2_public_network_0}
        Relationship                = DependsOn
        Conditional                 = NoCondition
        Name                        = db2_db2inst1_host1_0-
                                      rs_DependsOn_db2_public_network_0-rel
        ActivePeerDomain            = hadr_domain
        ConfigValidity              =

A dependência criada entre o recurso de instância e a rede pública é um exemplo disso. Se a rede pública fica inativa, os clientes não conseguem mais se conectar ao banco de dados; consequentemente, é necessário um failover. Verifique se a rede pública está ativa.

Próxima etapa

Se o problema não foi resolvido por meio das instruções desta seção, este seria o momento adequado para abrir um PMR. Inclua na sua descrição todas as coisas que detectou com base nas orientações acima. Além disso, informe o seguinte:

  • Saída de comandos executados manualmente
  • db2support
  • getsadata

Ausência de failover

Esta seção descreve a resolução de problemas em cenários nos quais se esperava um failover, mas ele não ocorreu. Antes de realizar as etapas mais aprofundadas de diagnóstico, você fazer algumas perguntas a você mesmo:

  • O failover deveria ocorrer?
    • Os cenários nos quais se espera um failover são:
      • A máquina primária fica inativa (por exemplo: é desligada)
      • Falha da rede pública da máquina primária
      • Falha da instância primária
  • Cenários nos quais o failover não deve ocorrer:
    • Eliminação da instância (por exemplo: db2_kill)
    • Perda da rede privada
  • Qual o motivo de não ocorrer um failover esperado?
    • A falha não foi detectada e, consequentemente, nenhuma ação foi realizada
    • A falha foi detectada, mas o failover não foi iniciado
    • Houve uma tentativa de failover, mas falhou

Para escolher a categoria correta, vamos revisar a ação que o TSA/RSCT realizaria em caso de falha.

É comum pensar que o failover deve ocorrer sempre que há uma falha, mas isso não está correto. Nem sempre isso é verdade. Em cenários nos quais o primário pode voltar à atividade rapidamente, talvez o failover não seja necessário. Primeiramente, o TSA/RSCT tentaria reiniciar a instância, o banco de dados de HADR (ou os dois) no mesmo host. Se isso falha, o programa tenta inicializar o banco de dados de HADR no host de espera.

Por exemplo: quando o processo db2sysc é eliminado, não haveria nenhum failover se o banco de dados primário de HADR conseguisse reiniciar no tempo designado. Entretanto, em um cenário de falha prolongada (por exemplo: a instância não consegue voltar a ficar ativa ou demora demais para reiniciar), espera-se um failover.

A falha foi detectada?

Um recurso em cluster é monitorado ao chamar o seu script de monitor e avaliar o seu código de retorno. Por volta do horário da falha, você deve ver uma mudança no código de retorno do script de monitor de recurso.

  • Abra o syslog no host primário original.
  • Você está vendo entradas de script de monitor de HADR?
    • Sim - Continue depurando.
    • Não - Em uma configuração correta, o script de monitor deve ser executado periodicamente para monitorar o estado do recurso de banco de dados de HADR. A criação de log está ativada e está no nível correto? Certifique-se de que o domínio do cluster esteja configurado corretamente.

Dica

É possível procurar o script de monitor de instância "Returning 2" para identificar o ponto no qual a falha da instância do DB2 foi detectada.

  • Verifique as entradas do script de monitor de HADR e procure um período no qual o código de retorno muda de "Returning 1" para "Returning 2." Está vendo essa mudança?
    • Sim - Esse é o momento no qual o TSA/RSCT detectou pela primeira vez que o banco de dados primário está inativo. A falha foi detectada corretamente. Vá para a pergunta: "Uma tentativa de failover foi iniciada?"
    • Não - Continue depurando.
  • Você está vendo erros de tempo limite?
    • Sim - O script de monitor está demorando demais para obter o status do recurso para o gerenciador do cluster. Execute o script no modo detalhado para ver onde ele está passando mais tempo ou se o script é interrompido.
      Listagem 16. Executando o script no modo detalhado
      root@host2:/usr/sbin/rsct/sapolicies/db2# 
      ./hadrV97_monitor.ksh db2inst1 db2inst1
      HADRDB verbose
      + CT_MANAGEMENT_SCOPE=2
      + export CT_MANAGEMENT_SCOPE
      + CLUSTER_APP_LABEL=db2_db2inst1_db2inst1_HADRDB
      + [[ verbose == verbose ]]
      + typeset +f
      + typeset -ft main monitorhadr set_candidate_P_instance
      + main db2inst1 db2inst1 HADRDB verbose
      + set_candidate_P_instance
      + candidate_P_instance=db2inst1
      + candidate_S_instance=db2inst1
      + + hostname
      + tr .
      + awk {print $1}
      localShorthost=host2
      + [[ db2inst1 != db2inst1 ]]
      + return 0
      + + lsrsrc -s Name = 'db2_HADRDB_host2_Reintegrate_db2inst1_db2inst1' 
      IBM.Test Name
      + grep -c Name
      nn=0
      + [[ 0 -eq 0 ]]
      + [[ db2inst1 != db2inst1 ]]
      + [[ 0 -ne 0 ]]
      + monitorhadr
    • Não - Se o script de monitor é sempre "Returning 1", o TSA/RSCT pensa que o recurso ainda está on-line e nenhuma ação é realizada.
      • Isso corresponde ao status do ponto de vista do DB2?
      • Verifique o db2diag.log e use o db2pd para obter pistas sobre o funcionamento da instância de banco de dados e as últimas mudanças de função.

Uma tentativa de failover foi iniciada?

Em um cenário no qual se espera um failover (por exemplo: não é possível reiniciar o recurso no host original), após a detecção da falha, deve ocorrer um failover. No caso do recurso de HADR do DB2, isso significa uma chamada do script de início de HADR no antigo host de espera.

  • Abra o syslog no host de espera original.
  • Atenha-se ao período relevante.
  • Você está vendo chamadas de scripts?
    • Sim - Continue depurando.
    • Não - Isso é muito suspeito. Você deveria ver o script de monitor sendo chamado em um determinado intervalo de tempo no syslog. Pergunte a você mesmo: "O cluster está configurado corretamente? A criação de log no syslog está ativada?"
  • Você está vendo chamadas do script de início de HADR?
    • Sim - Isso significa que o TSA/RSCT tentou iniciar o recurso no host de espera. Este é o comportamento correto até agora. Vá para a pergunta: "O failover teve êxito?"
    • Não - Provavelmente é um problema do TSA/RSCT. Entre em contato com o suporte IBM.

O failover teve êxito?

Dica

É possível verificar o estado do banco de dados de HADR examinando o db2diag.log. Procure a palavra-chave "HADR state" para ver a transição para o primário.

  • O script de início de HADR retornou corretamente (em outras palavras, "Returning 0")?
    • Sim - Isso significa que o banco de dados foi iniciado corretamente como primário neste servidor que originalmente era o de espera.

      Nesse momento, se você olhar a saída de lssam , verá uma mudança de função, na qual o recurso do banco de dados de HADR está on-line no antigo host de espera e falhou off-line no antigo host primário.

      Listagem 17. Saída do lssam
      root@host1:/# lssam
      Online IBM.ResourceGroup:db2_db2inst1_host1_0-rg Nominal=Online
              '- Online IBM.Application:db2_db2inst1_host1_0-rs
                      '- Online IBM.Application:db2_db2inst1_host1_0-rs:host1
      Failed offline IBM.ResourceGroup:db2_db2inst1_host2_0-rg Nominal=Online
              '- Failed offline IBM.Application:db2_db2inst1_host2_0-rs
                      '- Failed offline IBM.Application:db2_db2inst1_host2_0-rs:host2
      Online IBM.ResourceGroup:db2_db2inst1_db2inst1_HADRDB-rg 
      Control=MemberInProblemState 
      Nominal=Online
              '- Online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs 
                 Control=MemberInProblemState
                      |- Online IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:host1
                      '- Failed offline 
                      IBM.Application:db2_db2inst1_db2inst1_HADRDB-rs:host2
      Online IBM.Equivalency:db2_db2inst1_host1_0-rg_group-equ
              '- Online IBM.PeerNode:host1:host1
      Online IBM.Equivalency:db2_db2inst1_host2_0-rg_group-equ
              '- Online IBM.PeerNode:host2:host2
      Online IBM.Equivalency:db2_db2inst1_db2inst1_HADRDB-rg_group-equ
              |- Online IBM.PeerNode:host2:host2
              '- Online IBM.PeerNode:host1:host1

      Continue a resolução de problemas. Ocorreu um takeover; então, algo deve ter acontecido posteriormente, causando uma aparente ausência de failover. Examine as entradas do syslog para ver qual foi a sequência de eventos que aconteceram depois.

      Observação: observe os códigos de retorno do script de monitor de HADR. Eles inicialmente retornam 1 e depois retornam 2 ou expiram? Se o script de monitor de HADR retorna 2 posteriormente, é porque ocorreu uma segunda falha. Verifique isso no db2diag.log.

    • Não - Usando o script de início de HADR, o TSA/RSCT não consegue iniciar o banco de dados como primário no host de espera. Examine o db2diag.log para continuar o diagnóstico. Estabeleça sempre a correspondência entre os registros de data e hora no syslog e os registros de data e hora no arquivo db2diag.log file. Há mensagens de erro no db2diag.log aproximadamente no mesmo período de tempo em que ocorreu a falha do script de início de HADR? Vamos analisar algumas causas-raiz possíveis.

A janela do peer vence

Se o parâmetro de configuração HADR_PEER_WINDOW é baixo demais, ele pode vencer no momento em que o gerenciador do cluster tenta emitir um comando takeover a partir da espera. Na Listagem 18 abaixo, HADR_PEER_WINDOW está configurado como 5.

Listagem 18. db2diag.log da espera
2010-08-05-10.30.21.185557-240 I609665A427        LEVEL: Severe
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduAcceptEvent, probe:20215
RETCODE : ZRC=0x8280001B=-2105540581=HDR_ZRC_COMM_CLOSED
          "Communication with HADR partner was lost"

2010-08-05-10.30.21.185758-240 E610093A373        LEVEL: Event
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to S-DisconnectedPeer (was S-Peer)

2010-08-05-10.30.21.186057-240 I610467A356        LEVEL: Warning
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrCloseConn, probe:30595
MESSAGE : Peer window end time :1281018623



2010-08-05-10.30.24.198297-240 I612083A367        LEVEL: Warning
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduAcceptEvent, probe:20202
MESSAGE : Peer window ends. Peer window expired.

2010-08-05-10.30.24.198729-240 E612451A389        LEVEL: Event
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE  : HADR state set to S-RemoteCatchupPending (was S-DisconnectedPeer)

No momento em que a falha do banco de dados primário foi detectada pelo TSA/RSCT e um failover foi considerado necessário, a janela do peer já tinha vencido. Como resultado disso, o script de início de HADR falharia.

Listagem 19. Syslog da espera
Aug  5 10:31:15 host1 user:notice /usr/sbin/rsct/sapolicies/db2/hadrV97_monitor.ksh 
                                  [663766]: Returning 2 : db2inst1 db2inst1 HADRDB
Aug  5 10:31:17 host1 user:debug /usr/sbin/rsct/sapolicies/db2/db2V97_monitor.ksh
                                  [692326]: Returning 1 (db2inst1, 0)
Aug  5 10:31:27 host1 user:debug /usr/sbin/rsct/sapolicies/db2/db2V97_monitor.ksh
                                  [471160]: Returning 1 (db2inst1, 0)
Aug  5 10:31:34 host1 user:notice /usr/sbin/rsct/sapolicies/db2/hadrV97_start.ksh
                                  [471162]: Entering : db2inst1 db2inst1 HADRDB
Aug  5 10:31:36 host1 user:notice /usr/sbin/rsct/sapolicies/db2/hadrV97_monitor.ksh
                                  [598066]: Entering : db2inst1 db2inst1 HADRDB
Aug  5 10:31:37 host1 user:debug /usr/sbin/rsct/sapolicies/db2/db2V97_monitor.ksh
                                  [700494]: Returning 1 (db2inst1, 0)
Aug  5 10:31:39 host1 user:notice /usr/sbin/rsct/sapolicies/db2/hadrV97_monitor.ksh
                                  [598080]: Returning 2 : db2inst1 db2inst1 HADRDB
Aug  5 10:31:44 host1 user:notice /usr/sbin/rsct/sapolicies/db2/hadrV97_start.ksh 
                                  [471192]: Returning 3 : db2inst1 db2inst1 HADRDB
Listagem 20. db2diag.log da espera por volta da chamada do script de início de HADR
2010-08-05-10.31.36.489581-240 I728601A485        LEVEL: Error
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSDoTakeover, probe:47004
RETCODE : ZRC=0x8280001D=-2105540579=HDR_ZRC_NOT_TAKEOVER_CANDIDATE_FORCED
          "Forced takeover rejected as standby is in the wrong state or peer window 
           has expired"

2010-08-05-10.31.36.489773-240 I729087A363        LEVEL: Warning
PID     : 741466               TID  : 4502        PROC : db2sysc
INSTANCE: db2inst1              NODE : 000
EDUID   : 4502                 EDUNAME: db2hadrs (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSDoTakeover, probe:47008
MESSAGE : Info: Standby has failed to takeover.

Tente aumentar o valor de HADR_PEER_WINDOW .

Erros do gerenciador do cluster

Na mensagem de erro do db2diag.log, há indicadores com o identificador "###---####-###"? Isso pode indicar um erro retornado diretamente pelo TSA/RSCT ou que o TSA/RSCT não estava responsivo no momento. Consulte o centro de informações do RSCT para ver mais detalhes (consulte Recursos para ver o link).

O takeover falhou

Talvez você já tenha entendido que a etapa principal pela qual aquele que era espera assume a função de primário é um takeover do DB2. Verifique o db2diag.log para ver se há mensagens relacionadas com isso. A Listagem 21 ilustra uma mensagem de takeover com êxito:

Listagem 21. Mensagem de takeover com êxito
2010-08-06-10.31.20.530184-240 I8024A377          LEVEL: Warning
PID     : 622806               TID  : 4405        PROC : db2sysc
INSTANCE: db2inst1             NODE : 000
EDUID   : 4405                 EDUNAME: db2hadrp (HADRDB)
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSDoTakeover, probe:47003
MESSAGE : Info: Standby has completed takeover (now primary).

Você está vendo isso?

Verifique o estado atual de HADR do seu banco de dados (por meio do db2pd). Se não for primário, tente emitir manualmente o comando db2 takeover.

Listagem 22. Emita um db2 takeover
db2inst1@host2) /vbs/engn/ha/salinux $ db2 takeover hadr on db HADRDB
DB20000I  The TAKEOVER HADR ON DATABASE command completed successfully.

Próxima etapa

Se o problema não foi resolvido por meio das instruções desta seção, este seria o momento adequado para abrir um PMR. Inclua na sua descrição todas as coisas que detectou com base nas orientações acima. Além disso, informe o seguinte:

  • Saída de comandos executados manualmente
  • db2support
  • getsadata

Falha na reintegração

Depois de um failover, o antigo primário deve voltar e funcionar como a nova espera; isso é chamado de "reintegração." Em alguns casos, a reintegração pode falhar, deixando o domínio do cluster em um estado indesejável. Esta seção explora as possíveis causas de falha na integração e detalha as etapas da depuração posterior.

Perguntas que você deve fazer a si mesmo:

  • O HADR iniciou corretamente no novo primário?
  • A instância iniciou corretamente no antigo primário?

O HADR iniciou corretamente no novo primário?

Conforme o mencionado anteriormente, reintegração é quando o antigo primário reinicia como espera. Isso significa que o TSA/RSCT chamou o script de início de HADR na antiga espera, o que, por sua vez, teve como resultado a emissão do comando "db2 takeover". Se o comando de "takeover" não teve êxito, você está em uma situação de "ausência de failover". Consulte a seção "Ausência de failover" para obter assistência em relação a isso.

A instância iniciou corretamente no antigo primário?

A primeira etapa da reintegração é iniciar a instância no antigo primário, caso não tenha sido iniciada ainda.

  • Abra o syslog no antigo primário.
  • Você está vendo chamadas de scripts?
    • Sim - Continue depurando.
    • Não - Isso é muito suspeito. Você deveria ver o script de monitor sendo chamado em um determinado intervalo de tempo no syslog. Pergunte a você mesmo: "O cluster está configurado corretamente? A criação de log no syslog está ativada?"
  • Você está vendo uma chamada de script de início de instância? (Procure o script de monitor de instância "Returning 2." Logo depois dele, você deve ver a chamada do script de início de instância.)
    • Sim - Continue depurando.
    • Não - Provavelmente é um problema do TSA/RSCT. Entre em contato com o suporte IBM.
  • O script de início de instância retornou corretamente ("Returning 0")?
    • Sim - Isso significa que a instância iniciou corretamente e deve ter reintegrado. Verifique os parâmetros de configuração do banco de dados ou o db2pd para confirmar a função do banco de dados de HADR.
    • Não - Examine as possíveis causas-raiz a seguir.

Tempo limite do db2gcf

O script de início da instância usa o utilitário db2gcf para iniciar a instância. Se o db2gcf expira, você deve ver a mensagem no db2diag.log indicando isso.

Listagem 23. Mensagem do db2diag.log - o db2gcf expirou
2010-06-05-02.05.33.824563-240 I18731842A257      LEVEL: Error 
PID     : 1831554              TID : 1 
FUNCTION: DB2 Common, Generic Control Facility, GcfCaller::start, probe:40 
MESSAGE : ECF=0x9000028C Timeout occurred while calling a GCF interface function

Tente iniciar a instância manualmente e veja quanto tempo isso leva (db2start). Também é possível tentar iniciar a instância usando o db2gcf sem especificar um tempo limite e ver quanto tempo isso leva:

db2gcf u i db2inst1

O tempo de início varia de acordo com o número de partições do ambiente.Entretanto, não deve passar de alguns segundos por partição.

Falha do db2start

Se a instância iniciou corretamente, com certeza há uma mensagem no db2diag.log indicando isso.

Listagem 24. Mensagem do db2diag.log - mensagem de início com êxito
2010-08-04-22.05.57.453549-240 E10236E305          LEVEL: Event
PID     : 9620                 TID  : 47284539421760PROC : db2star2
INSTANCE: db2inst1             NODE : 000
FUNCTION: DB2 UDB, base sys utilities, DB2StartMain, probe:911
MESSAGE : ADM7513W  Database manager has started.
START   : DB2 DBM

Tente iniciar a instância manualmente para ver se dá certo.

Falha na reintegração

Nesse caso, a instância iniciou corretamente mas o antigo banco de dados primário de HADR não iniciou como espera. Conforme o mencionado na seção "lsrsrc", os sinalizadores são uma forma de comunicação entre o DB2 e o TSA/RSCT. No caso da reintegração, o novo primário criaria um sinalizador de reintegração. Trata-se de um sinal para que o antigo primário se inicie como espera. Uma vez concluída a reintegração, o sinalizador é excluído. Verifique se o sinalizador de reintegração ainda existe. Se o sinalizador ainda existe, isso é um forte indício de que a falha na reintegração teve algo a ver com a detecção do sinalizador.

A Tabela 5 lista alguns APARS relacionados à falha na reintegração. Leia cada um deles e veja se isto se aplica ao seu cenário.

Tabela 5. APARS de reintegração
APARCorrigido em
IC65836 / IC65837V95FP6 / V97FP2
IC64142 / IC64666V95FP6 / V97FP2
IC67393V97FP2

Próxima etapa

Se o problema não foi resolvido por meio das instruções desta seção, este seria o momento adequado para abrir um PMR. Inclua na sua descrição todas as coisas que detectou com base nas orientações dadas. Além disso, informe o seguinte:

  • Saída de comandos executados manualmente
  • db2support
  • getsadata

Problemas de configuração do db2haicu

Para fazer um cluster de uma configuração de HADR, usa-se a ferramenta db2haicu. Essa ferramenta interage com o TSA/RSCT de forma oculta para criar recursos para gerenciar várias entidades de DB2. Quando é executada no modo interativo, o usuário deve responder uma série de perguntas. Na maioria dos casos, se o usuário insere uma resposta incorreta/inadequada, ele recebe um aviso sobre isso.

Nesta seção, obtenha orientação para identificar os casos nos quais uma entrada incorreta não é corrigida imediatamente (em certas versões do db2haicu), o que provoca o funcionamento incorreto do cluster.

Há duas possibilidades de falha do db2haicu durante a configuração:

Para distinguir entre problemas devido a entradas inválidas e erros do TSA/RSCT, verifique o db2diag.log. Atenha-se aos logs referentes às funções da família "sqlha." Você está vendo o identificador ####-### no campo de dados? Se sim, trata-se de um erro que vem diretamente do gerenciador do cluster. Caso contrário, pode ser um erro de configuração. A seção de dados deve indicar o recurso no qual está tentando agir (por exemplo: o nome do recurso ou grupo de recursos que está tentando criar ou localizar).

Observação: Os requisitos de parâmetros de configuração de HADR do DB2 são diferentes dos requisitos da ferramenta db2haicu. Devido a essa diferença, mesmo se o par de bancos de dados de HADR estiver funcionando perfeitamente, a ferramenta db2haicu pode falhar ao criar recursos no domínio do cluster. Consulte a Tabela 2 para ver os detalhes.

Entradas inválidas comuns

Na maioria dos casos, uma entrada do usuário que é obviamente inválida será rejeitada a partir da interface interativa do db2haicu (por exemplo: usar um nome de host como VIP). No entanto, alguns erros de configuração não são detectados imediatamente; portanto, o processo de configuração pode falhar no final, com uma mensagem genérica. Será necessário examinar o db2diag.log para continuar a depuração.

Vamos analisar algumas áreas comuns que estão propensas a entradas inválidas:

Nome do host

A solução integrada de HA se baseia em várias fontes para obter o nome do host. Consequentemente, é necessário certificar-se de que a formatação de todas as entradas do usuário e valores do sistema são consistentes entre si.

Para descobrir como o TSA/RSCT vê o nome do host, emita o comando lsrpnode.

Para descobrir como o DB2 vê o nome do host, emita o comando uname. ( Observação: É uma boa prática manter o nome de host do "uname" consistente com a saída do nome do host).

A Listagem 25 mostra alguns lugares onde o nome do host é solicitado dos usuários.

Listagem 25. Solicitações de nome do host
Create a unique name for the new domain:
ha
Nodes must now be added to the new domain.
How many cluster nodes will the domain ha contain?
2
Enter the host name of a machine to add to the domain:
host1
Enter the host name of a machine to add to the domain:
host2
db2haicu can now create a new domain containing the 2 machines that you specified. 
If you choose not to create a domain now, db2haicu will exit.

Create the domain now? [1]
1. Yes
2. No
1
Creating domain ha in the cluster...
Creating domain ha in the cluster was successful.

No caso do banco de dados de HADR, os nomes do host são especificados nos parâmetros HADR_LOCAL_HOST e HADR_REMOTE_HOST . Se um endereço de IP é especificado aqui, a ferramenta interativa db2haicu pede o nome do host real.

Listagem 26. Prompt do nome do host
Setting a high availability configuration parameter for instance db2inst1 to TSA.
Adding DB2 database partition 0 to the cluster...
Adding DB2 database partition 0 to the cluster was successful.
Do you want to validate and automate HADR failover for the HADR database HADRDB? [1]
1. Yes
2. No
1
Adding HADR database HADRDB to the domain...
The cluster node 9.26.53.5 was not found in the domain. Please re-enter the host name.
host1
The cluster node 9.26.53.50 was not found in the domain. Please re-enter the host name.
host2
Adding HADR database HADRDB to the domain...
The HADR database HADRDB has been determined to be valid for high availability. 
However, the database cannot be added to the cluster from this node because db2haicu 
detected this node is the standby for the HADR database HADRDB. 
Run db2haicu on the primary for the HADR database HADRDB to configure the database for 
automated failover.
All cluster configurations have been completed successfully. db2haicu exiting...

O valor especificado nos parâmetros HADR_LOCAL_HOST e HADR_REMOTE_HOST será usado no estado em que se encontra para gerar os nomes dos recursos em cluster. Se houver inconsistência na formatação entre esses valores referentes a fontes de nome do host, ocorrerá uma falha. O fato de não manter essa consistência provocará uma falha na configuração do db2haicu. A boa prática é usar nomes de host canônicos em todas as áreas.

As Listagens 27 e 28 mostram mensagens de erro que podem ocorrer em uma situação de inconsistência do nome do host.

Listagem 27. Mensagem de erro do db2haicu
The HADR database HADRDB cannot be added to the cluster because the standby instance 
is not configured in the domain. Run db2haicu on the standby instance to configure it 
into the cluster.
All cluster configurations have been completed successfully. db2haicu exiting ...
Listagem 28. Mensagem de erro do db2diag.log
2010-08-04-13.45.17.792165+720 E258375A757        LEVEL: Error
PID     : 23901                TID  : 2199089142032PROC : db2haicu
INSTANCE: db2inst3             NODE : 000
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure, sqlhaAddResourceGroup, 
          probe:300
MESSAGE : ECF=0x90000557=-1879046825=ECF_SQLHA_CLUSTER_ERROR
          Error reported from Cluster
DATA #1 : String, 35 bytes
Error during vendor call invocation
DATA #2 : unsigned integer, 4 bytes
46
DATA #3 : String, 45 bytes
db2_db2inst3_lildb202.nz.thenational.com_0-rg
DATA #4 : unsigned integer, 4 bytes
1
DATA #5 : unsigned integer, 8 bytes
1
DATA #6 : signed integer, 4 bytes
0
DATA #7 : String, 0 bytes
Object not dumped: Address: 0x00000000800D59FC Size: 0 Reason: Zero-length data

HADR_REMOTE_INST

Outra fonte de erro na configuração de HADR é o HADR_REMOTE_INST, que faz distinção entre maiúsculas e minúsculas no db2haicu.

Listagem 29. Mensagem de erro do db2diag.log
2010-08-05-09.16.57.317614-240 E49090A665         LEVEL: Error
PID     : 717032               TID  : 1           PROC : db2haicu
INSTANCE: db2inst1             NODE : 000
EDUID   : 1
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure, sqlhaUICreateHADR, probe:895
RETCODE : ECF=0x9000056F=-1879046801=ECF_SQLHA_HADR_VALIDATION_FAILED
          The HADR DB failed validation before being added to the cluster
MESSAGE : Please verify that HADR_REMOTE_INST and HADR_REMOTE_HOST are correct
          and in the exact format and case as the Standby instance name and
          host name.
DATA #1 : String, 7 bytes
Db2inst1
DATA #2 : String, 10 bytes
host2

2010-08-05-09.16.57.317983-240 E49756A594         LEVEL: Error
PID     : 717032                TID  : 1          PROC : db2haicu
INSTANCE: db2inst1              NODE : 000
EDUID   : 1
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure, sqlhaUICreateHADR, probe:900
RETCODE : ECF=0x9000056F=-1879046801=ECF_SQLHA_HADR_VALIDATION_FAILED
          The HADR DB failed validation before being added to the cluster
DATA #1 : String, 7 bytes
db2inst1
DATA #2 : String, 7 bytes
Db2inst1
DATA #3 : String, 10 bytes
host1
DATA #4 : String, 10 bytes
host2
DATA #5 : String, 7 bytes
HADRDB

Formato geral de nomenclatura

O nome da ocorrência não pode conter um sublinhado(_), porque ele é usado como delimitador do recurso do TSA/RSCT. Pode provocar uma análise incorreta. Foram feitas melhorias no V95FP6 (IC62705) e no V97FP2 (IC64856) para permitir nomes de instância que contenham sublinhados. Entretanto, é recomendável evitar essa nomenclatura.

Falha do comando do TSA/RSCT

É possível que a configuração do d2haicu falhe mesmo quando todas as entradas são válidas. Durante o processo de configuração, o db2haicu faria chamadas de TSA/RSCT para criar e registrar vários recursos. Se a chamada do fornecedor retorna com erro, isso faz com que o db2haicu feche de forma incorreta. Para verificar isso, examine o db2diag.log para ver se há mensagens de erro que contém o indicador "### --- ####-###". As Listagens de 30 a 34 mostram mensagens de erro típicas do db2haicu e do db2diag.log para ilustrar falhas comuns.

Falha comum nº. 1

Listagem 30. Mensagem de erro típica do db2haicu
Create the domain now? [1]
1. Yes
2. No
1
Creating domain HA in the cluster ...
Creating domain failed. Refer to db2diag.log and the DB2 Information Center for details.
Listagem 31. Mensagem de erro típica do db2haicu
Adding DB2 database partition 0 to the cluster ...
There was an error with one of the issued cluster manager commands. Refer to db2diag.log 
and the DB2 Information Center for details.
Listagem 32. Mensagem de erro típica do db2diag.log
2010-01-06-14.31.50.656997-420 E3426E903           LEVEL: Error
PID     : 3485                 TID  : 48008924417584PROC : db2haicu
INSTANCE: db2inst1             NODE : 000
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure, sqlhaCreateCluster, probe:900
MESSAGE : ECF=0x90000544=-1879046844=ECF_SQLHA_CREATE_CLUSTER_FAILED
          Create cluster failed
DATA #1 : String, 24 bytes
Error creating HA Domain
DATA #2 : String, 6 bytes
UC4GHA
DATA #3 : unsigned integer, 4 bytes
2
DATA #4 : signed integer, 4 bytes
21
DATA #5 : String, 350 bytes
Line # : 8839---2632-044 The domain cannot be created due to the following errors that 
         were detected while harvesting information from the target nodes:
         db200: 2610-441 Permission is denied to access the resource class specified 
         in this command. Network Identity UNAUTHENT requires 's' permission for the 
         resource class IBM.PeerDomain on node db200.

Solução:preprpnode não foi executado em cada nó. Como raiz, emita o comando do TSA/RSCT preprpnode <host1> <host2> em cada nó.

Falha comum nº. 2

Listagem 33. Mensagem de erro típica do db2diag.log
   2010-07-20-14.52.28.537943-240 E15731289A765      LEVEL: Error  
   PID     : 974914               TID  : 1           PROC : db2haicu  
   INSTANCE: db2inst1             NODE : 000  
   EDUID   : 1  
   FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure,  
   sqlhaAddResource, probe:1600  
   MESSAGE : ECF=0x90000542=-1879046846=ECF_SQLHA_CREATE_GROUP_FAILED  
             Create group failed  
   DATA #1 : String, 35 bytes  
   Error during vendor call invocation  
   DATA #2 : unsigned integer, 4 bytes  
   0  
   DATA #3 : String, 0 bytes  
   Object not dumped: Address: 0x0000000110165890 Size: 0 Reason: Zero-  
   length data  
   DATA #4 : unsigned integer, 8 bytes  
   1  
   DATA #5 : signed integer, 4 bytes  
   309  
   DATA #6 : String, 86 bytes  
   Line # : 7227---2621-309 Command not allowed as daemon does not have a  
   valid license.

Solução: É um problema de licenciamento do TSA/RSCT. Obtenha a licença no Passport Advantage e aplique-a usando o comando samlic .

Falha comum nº. 3

Listagem 34. Mensagem de erro típica do db2diag.log
2010-07-20-14.52.28.538365-240 E15732055A369      LEVEL: Error  
PID     : 974914               TID  : 1           PROC : db2haicu  
INSTANCE: db2inst1             NODE : 000  
EDUID   : 1  
FUNCTION: DB2 Common, SQLHA APIs for DB2 HA Infrastructure,  
sqlhaCreateNetwork, probe:50  
RETCODE : ECF=0x90000542=- RETCODE : 
          ECF=0x90000542=-1879046846=ECF_SQLHA_CREATE_GROUP_FAILED 
          Create group failed. 
Line # : 6531---host1: 2661-011 The command specified for attribute MonitorCommand is 
         NULL, not a absolute path, does not exist or has insufficient permissions to
         be run.

Solução: Isso indica que os scripts de sapolicies não se encontram no local /usr/sbin/rsct/sapolicies/db2. Consulte a nota técnica "Error 'The command specified for attribute MonitorCommand is NULL' reported by db2haicu" (IBM, março de 2010) para ver uma resolução. (Consulte Recursos para ver um link.)

Para ver outros erros do gerenciador do cluster, consulte o centro de informações do RSCT (consulte Recursos para ver o link) ou entre em contato com o suporte IBM.


Conclusão

Depois de ler este tutorial, você deve entender melhor como partes diferentes da arquitetura de HA se relacionam entre si e como usar as ferramentas para depurar problemas em cada componente. Essas informações não só são importantes no diagnóstico inicial, mas também desmistificam os componentes da arquitetura de HA, estabelecem as expectativas adequadas em relação ao funcionamento desses componentes em conjunto e mostram o que cada informação de diagnóstico realmente significa, dos pontos de vista do DB2 e do TSA/RSCT.

Recursos

Aprender

Obter produtos e tecnologias

  • DB2 Express-C: faça o download do DB2 Express-C, uma versão grátis do servidor de banco de dados DB2 Express para a comunidade.
  • DB2 para Linux, UNIX e Windows: faça o download de uma versão de avaliação grátis do DB2 para Linux, UNIX e Windows.
  • Realize o seu próprio projeto de desenvolvimento com softwares de avaliação IBM, disponíveis para download diretamente a partir do developerWorks.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management, Tivoli
ArticleID=556581
ArticleTitle=Usando Recuperação de Desastre de Alta Disponibilidade do DB2 com Tecnologia Tivoli Systems Automation e Reliable Scalable Cluster
publish-date=10262010