Soluções de disponibilidade em IDS

HDR

• Implementado pela primeira vez com a versão 6 do Informix;
• Fornece Hot Backup secundário;
• Pode ser usado para compensar o processamento de leitura;
• Fácil configuração;
• Faça um backup dos dados primários e restaure;
• Trabalha com atualização automatica dos logs no servidor secundario
• Servidor Secundario esta em modo de recuperação;
• Suporta commits sincronizada;

 

Soluções avançadas de Alta Disponibilidade em Informix

• Implementado com a versão 7.22 do Informix;
• Uso
• Particionamento de carga de trabalho;
• Capacidade de substituição;
• Suporta atualizações em qualquer lugar
• Latencia muito baixa;
• Sincronização locais com dados globais;
• Integrado
• Compatível com todas as soluções de disponibilidade de outros Informix;
• Segurança das comunicações de dados;

Algumas características ER

• Templates
• Permite um grande conjunto de tabelas para ser implementado ao longo de um grande número de nós com apenas um par de comandos;
• Check/Sync
• Permite  verificação/reparo/sincronização online de um ambiente;
• Suporta mudanças de esquema;
• Configurações de replicações
• Permite a administração de um grande número de replicações com um único comando;

Outras características ER

• Resolução de conflitos
• Usado para determinar se a versão atual ou apenas recebeu versão da linha ‘ganhador’;
• Ignorar – Linha deve ser aplicada como é;
• Timestamp – Atualizações mais recentes vence;
• Store Procedure;
• Direcionamento
• Root, non-root e leaf nodes;
• Integração com HDR
• Permite um nó ER para ser um nó HDR

Remote Standalone Secondary (RSS)

• Próximo passo para a evolução do HDR – nós RSS
• Novo tipo de secundario – nós RSS
• Pode ter 0 para N nós RSS
• Pode coexistir com HDR Secundario
• Uso:
• Relatório
• Aplicações WEB
• Backup adicional no caso do primeiro falhar
• Semelhança com nó HDR secundario:
• Recebe logs do primario
• Tem seu proprio conjunto de disco para gerir
• RSS tem um impacto minimo no desempenho do primario
• Diferenças  com nó HDR secundario
• Só pode ser promovido a HDR secundario, nunca como primario
• Modo SYNC não suportado

Compartilhamento de disco secundario (SDS – Shared Disk Secondary)

• Proximo passo evolutivo
• Nós SDS compartilha discos com o primario
• Pode ter 0 para N nós SDS
• Uso
• Ajuste online da capacidade  como mudanças na demana
• Não duplicar o espaço em disco
• Caracteristica
• Não requer nenhum hardware especifico
• Simples para configurar
• Pode coexistir com ER
• Pode coexistir com nós HDR e RSS
• Semelhanças com nó HDR secundário:
• O primario pode ser trocado por qualquer nó SDS

Uso do disco compartilhado

• Maior disponibilidade
• Misturando atividades de relatorios e atualizações
• Processamento de relatorios frequentes afeta o sistema de produção OLTP
• Tendo nós DSS e OLTP trabalhando no mesmo dados
• O primario pode ser configurado como um sistema OLTP enquanto uma  ou mais nós SDS são configurados como DSS/PDQ
• Capacidade dinamica
• O nó SDS é rapidamente instanciado, é facil de adicionar ou aumentar a capacidade como a mudança na demanda de trabalhos

Atualizando o secundário

O que é isto

• Suporte adicionado no IDS 11.50
• Suporta uma operação DML (INSERT, UPDATE e DELETE) no nó secundario
• Usam concorrência otimizada para evitar a atualização de uma copia obsoleta da linha
• Suporta commit de leitura em nós secundarios
• Trabalha com os tipos de dados básicos, UDTs (aqueles que armazenam os dados no servidor) registros SMART BLOBs, e partições BLOBs.
• Suporta tabelas temporarias – explícitos e implícitos.
• Trabalha com ER.

Otimizando concorrencias  e escritas no secundario

• Adicionado IDS 11.50
• Adicionado suporte para versões de linha
• CREATE TABLE……. WITH VERCOLS
  ALTER TABLE…… [ADD] / [DROP] VERCOLS
• Cria uma coluna sombra que consiste em uma soma de verificação de inserção (ifx_insert_checksum) e atualiza a versão da coluna (ifx_row_version).
• Se for determinado que a imagem anterior (before image) no secundário é diferente da imagem atual do primário, em seguida a gravação da operação não é permitida e uma EVERCONFLICT erro (-7350) é retornado.
• Se a tabela não utiliza VERCOLS, então a before image da linha é usado para verificar se a atualização não esta tentando gravar numa linha obsoleta.

Gerenciamento de conexões

• Mantem o conhecimento de todos nós dentro do cluster
• Registro de adição e remoção dos nós
• Monitora os tipos de nós
• Monitora carga de trabalho dos nós
• Rotas aplicações  para nós do destino
• Trabalha sobre o conceito de “Service Level Agreement (SLA)
• Conecta-se ao primario
• Conecta-se o melhor possivel com o secundario
• Pode existir multiplas conexões de modo que não há nenhum ponto de falha

 

Arbitro

• O proposito é detectar rapidamente a falha do server primario
• Parte do gerenciador de conexões
• Obtém a confirmação através de caminhos alternativos antes de realizar um failover
• Executa um failover usando uma API de interface administrativa
• Há failover para o arbitro assim como há failover para o gerenciamento de conexão.

Soluções básicas de restauração de logs continuos

Opções  de restauração dos continuos logs com ontape/onbar

Com as opções de restauração dos continus logs, o servidor irá suspender a restauração de log:

ontape –l –C
roll forward deve começar com o numero de log 7
a restauração de log será suspenso no numero de log 7

a restauração de log pode ser reiniciada novamente com o comando ontape

ontape –l –C
roll forward deve começar com o numero de log 8
a restauração de log será suspenso no numero de log 10

Modo de recuperação é terminado pelo comando ontape –l

Alterações dos dados externos

• Observação do log exposto
• Fornece uma base para o IDS nao replicado
• Trabalha totalmente em protocolo SQL
  (UDRs e pseudo smart blob)

Algumas API basicas

• CDC_OPENSESS()
  Estabelece um ambiente de CDC e retorna um ‘sessionID’, que é realmente um fd para um pseudo smartblob
• CDC_SET_FULLROWLOGGING()
  Faz com que a linha inteira seja registrada. Um requisito para CDC
• CDC_STARTCAPTURE()
  Define quais as tabelas devem ser capturado
• CDC_ACTIVATESESS()
  Dados de alteração para ser devolvido ao cliente através do pseudo smartblob

Recuperação de dados CDC

• Os dados são recuperados através de uma interface smartblob
• Isso permite que aplicativos do CDC para ser escrito em qualquer ferramenta de cliente que suporta grandes objetos.
• Implementado dentro de um banco de dados ‘CDC’ composto por UDRs e pseudo objetos, assim como o sysmater.
• Para ler os dados do CDC e pseudos LOB
• mi_lo_read() – UDRs
• ifx_lo_read() – ODBC/C(++)
• ifxLoRead() - Java