Como funciona SDS - Shared Disk Secondary Server ?

Versão para impressãoEnviar para amigoVersão PDF

O recurso de SDS do Informix está disponivel para a versão Enterprise do produto. Sua finalidade é permitir um ambiente de alta disponibilidade e balanceamento de carga.

As instancias do Informix ficam em maquinas distindas, porém ambas possuem acesso ao mesmo disco (compartilhado através do storage).
Desta forma para adicionar um sevidor secundário ao ambiente é preciso apenas que a maquina tenha acesso aos mesmos discos do servidor primario, que as maquinas sejam da mesma arquitetura, utilize a mesma rede e tenha uma versão do informix instalado.

Por estarem acessando ao mesmo disco o servidor secundário tem acesso aos logical logs da maquina primária, portanto consegue reproduzir os dados alterados na memória.

O funcionamento do SDS não é sincrona.
A comunicação por rede é feita utilizando o protocolo SMX (Server Multiplexer)

Caso tenha interesse em montar um ambiente de teste com SDS você pode faze-lo utilizando duas maquina com Linux instalado e configurando o compartilhamento de disco com recursos de iSCSI. Veja o artigo que explica como preparar este ambiente.
Para os passos de como configurar o servidor Informix , leia este artigo.

Serv1 = servidor/banco primário
Serv2 = servidor/banco secundário

Funcionamento


Atualização dos dado no Serv1 para Serv2
  • Através da comunicação de rede SMX, o Serv1 (servidor primário) envia ao Serv2 (servidor secundário) o LSN (Log sequence Number) que é a ultima posição no Logical Log
  • O Serv2 recebe o LSN , lê o logical log no disco e através da mesma técnica de fast recovery carregando no buffer os dados que foram modificados, então envia um ACK LSN (Acknowledgement) para o Serv1
  • Caso Serv1 não receba o ACK LSN no tempo especificado pelo parametro SDS_TIMEOUT ele desconecta o SDS secundário.

Atualização dos dado do Serv2 para Serv1

  • Quando uma sessão inicia uma transação, a thread sqlexec da sessão irá executar a thread ProxySync, esta thread irá enviar os dados através da comunicação SMX ao Serv1 onde irá receber os dados com a thread proxyDispatch e então irá repassar a proxyTh e está em fim irá aplicar ao logical log.
    sqlexec --> proxyWrite --> SMX --> ProxyDispatch --> proxyTh --> <llog>

    Observação: Esta explicação não está completa

Pré-Requisitos


  • Para o Serv2, Definir um ou mais dbspaces temporários no parametro SDS_TEMPDBS
    Este parametro suporta que seja especificado apenas um dbspace. Para informar mais de um, basta definir o parametro mais de uma vez.
    Observação: O dbspace deste parametro é criado automaticamente na inicialização do servidor.
  • Para o Serv2, desativar o log em tabelas temporárias com o parametro TEMPTAB_NOLOG 1
  • Para o Serv2, definir dois arquivos de file system para paginação do buffer caso este seja insuficente para manter as dirty pages. Parametro SDS_PAGING.
    O motivo de ser 2 arquivos é para manter o recurso de non-blocking checkpoint. Neste caso é recomendado file system com recurso de "Journaling" desabilitado.
    O arquivo de paginação poderá apenas crescer, nunca irá encolher, mesmo se todo seu conteúdo já foi liberado.
    Obs.: Teoricamente não é possível utilizar um device RAW para estes arquivos pois não há offset no parametro , porém se houver um device/partição para cada arquivo, acredito que seja possível utilizar (não testado).

Recomendações


  • Para melhor performance deve-se incluir nas tabelas os campos de contole de versionamento (VERCOLS ) :
    ALTER TABLE... ADD VERCOLS
    

    Serão incluidos dois campos na tabela:
    • ifx_insert_checksum: contem o checksum de apenas quando o registro foi incluido, após isso, mesmo após qualquer alteração este campo não se modifica mais.
    • ifx_row_version: trabalha como um campo serial, porém é incrementado cada vez que o registro é modificado.
  • Estes campos podem ser selecionados e utilizados por desenvolvedores, porém para vizualiza-los é necessário explicitar seus nomes no select.
  • Para evitar o uso de paginação dos buffers , avaliar e monitorar sua utilização (onstat -g sds e onstat -g iof) e configurar os buffer pools apropriadamente
  • O path para os chunks do dbspaces no servidor secundário será exatamente o mesmo do servidor primário, porém ainda assim recomenda-se altamente que seja utilizado links
  • Definir o parametro TEMPTAB_NOLOG com 1 em todos os servidores (primario e secundários) e assim evitar sobrecarga na rede e processamento.
    ATENÇÃO, verificar se o programa cliente considera a tabela temporária como logada ou não.

Observações e possíveis problemas


  • Programas que possem no código o nome do dbspace temporário em criação de tabelas temporários com fragment ou round robin.
  • Programas que fazem controle de transação em tabelas temporárias terá problema pois as tabelas temporárias nos servidores secundários, obrigatóriamente não são logadas.
  • Não é possível atualizar em servidores secundários campos do tipo TEXT/BYTE salvos em BLOBSPACES (Simple Large Object) , uma vez que trabalhando desta maneira eles não são logados no logical log. Para poder utiliza-los deve-se migra-los para dbspaces comum
  • Quando o Serv1 cai, o Serv2 continua no ar, porém assim que o Serv1 retorna, o Serv2 é automaticamente baixado (off-line).
  • Novos tipos de erros a considerar e tratar no código, descrição abaixa copiada do comando finderr:
    ERRO 7350. An attempt was made to update a stale version of a row. This caused an optimistic concurrency failure. This error can occur when using Updatable Secondary servers and the current version of the row has not yet been replicated to the Secondary to which the client application is connected. This error code is also returned when the table schema at the Secondary server does not match the table schema at the Primary server.
    EROO 7351. The connection between Secondary and Primary has been lost. This will prevent the usage of Updatable Secondary servers until connectivity has been reestablished.
  • Por motivos de segurança o comando "oninit -i" não executa quando o parametro SDS_ENABLE é igual a 1.
  • As threads de tasks schedule (dbWorks) não executam em servidores secundários, pois estes servidores estão em eterno estado de roll-back e estas threads apenas executam quando ele entra em estado online (que será quando ele assumir como primário )
  • É possível ativar o sqltrace em servidores secundários.
    Se for ativado através da função task() e o servidor não estiver com UPDATABLE_SECONDARY ativo, a função irá retornar o erro 626/140 porém o trace é ativado mesmo assim.
  • As SPL sysdbopen()/sysdbclose() continuam a funcionar nos servidores secundários. Caso seja necessário o DBA pode personalizar a função , identificando dentro dela com a variável dbservername e realizar parametrização especifica do mesmo usuário para diferentes servidores
  • Apartir da versão BTS.2 os indices podem ser gravados em SmartSpace, e permitindo o uso do BTS em HA.
  • O recurso de LBAC funciona perfeitamente nos servidores secundários , porém a administração dele só pode ser feito no primario.
  • Nos servidores secundários, isolation level:
    - Nao suporta REPEATIBLE READ, CURSOR STABILITY, permite executar o comando SET ISOLATOIN, porém o comando não efeito.
    - READ LAST COMMITED é suportado apenas em tabelas com locks de linhas. Mas isto é independente de trabalhar com SDS, RSS, HDR.
    - Isolation level defaul: Dirty Read

0
Ainda não votado
Sua avaliação: Nenhum

Comentar

O conteúdo deste campo é privado não será exibido ao público.
  • Endereços de páginas de internet e emails viram links automaticamente.
  • Você pode usar tags BBCode no texto.
  • Tags HTML permitidas: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>

Mais informações sobre as opções de formatação

CAPTCHA
Este teste é para bloquear programas automatizados e previnir spams
CAPTCHA de Imagem
Digite o texto exibido na imagem.