Artigo
· jan 25 31min de leitura

Visão geral do Journal - configuração, operações e utilitários

O que é o diário (Journal) ?

O diário (Journal) é um recurso essencial do IRIS e uma parte do que torna o IRIS um banco de dados confiável. Embora o diário seja fundamental para o IRIS, há nuances, então escrevi este artigo para resumir (mais brevemente do que nossa documentação com todos os detalhes) o que você precisa saber. Percebo a ironia de dizer que uma leitura de 27 minutos é breve.

Toda modificação em um banco de dados que tenha diário (sets e kills) é registrada com o carimbo de data/hora em um arquivo de diário. Isso é feito em paralelo com as gravações nos bancos de dados e no diário de imagem de gravação (WIJ) para a redundância. O IRIS usa os diários para reproduzir as mudanças no banco de dados em um cenário de recuperação, reverter transações e sincronizar bancos de dados para espelhamento.

Este artigo foca no que depende do diário e nos utilitários usados para gerenciar o diário. Também vamos mostrar uma breve visão geral das operações do IRIS relacionadas para explicar por que o diário é tão importante. Fique à vontade para entrar em contato com o WRC caso precise de suporte crítico com um problema no diário, mas conhecer os fundamentos pode ajudar você a configurar o diário corretamente e responder a cenários específicos da maneira apropriada.

Antes de começar, nossa documentação sobre o diário é robusta e pode ser encontrada abaixo. Às vezes, vou mencionar tabelas da documentação, em vez de reproduzi-las inline. Também vou adicionar um link para nossas melhores práticas de diário. - Recomendo muito a leitura desse documento.

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCDI_journal

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_journal#GCDI_journal_config_bestpract

A documentação mais recente (vinculada) no momento da escrita deste artigo é para o IRIS 2023.3 (CD), e a instância a que me referi está executando o IRIS 2023.1.2 (EM).

 

Configuração do diário

O portal de gerenciamento de sistemas é o local mais fácil para fazer alterações no diário (Administração do Sistema > Configuração > Configuração do Sistema > Configurações do Diário), mas há rotinas fora dele que também podem ser usadas para isso. Elas estão localizadas principalmente no namespace %SYS, e a maioria delas é indexada pela rotina ^JOURNAL, que chama os outros utilitários.

Observação: o portal de gerenciamento de sistemas será chamado de SMP para abreviar

O diário pode ser ativado principalmente no nível do sistema e no nível do banco de dados. Por padrão, o diário está sempre ativado em todo o sistema. Há pouquíssimas situações em que você deve desabilitar isso, portanto não há opção no SMP. Você precisará usar a rotina ^JRNSTOP. A interrupção do diário para o sistema dura até a reinicialização do IRIS, quando o diário é retomado automaticamente. Um erro também pode desativar o diário em todo o sistema, por exemplo, ficar sem espaço em disco no diário. Caso isso aconteça, você verá uma mensagem de messages.log avisando que o diário foi desativado. Você precisará usar a rotina ^JRNSTART para retomar o diário.

Para revisar o diário no nível do banco de dados, você pode acessar o SMP (Administração do Sistema > Configuração > Configuração do Sistema > Banco de Dados Local). O padrão é que os bancos de dados tenham diário.

Por padrão, os nomes dos arquivos do diário têm o formato aaaammdd.nnn e são armazenados em <install_dir>/mgr/journal/. Se o diário for compactado, o nome do arquivo terá o sufixo "z". O arquivo journal.log que registra o nome de cada arquivo do diário está em /mgr/. O log do diário limpará as entradas sequencialmente com base em se o próprio arquivo do diário foi limpo e se a entrada tem 30 dias ou mais. O journal.log é referenciado pelo IRIS para trocar e limpar diários, além de poder ser usado para ajudar a reproduzir diários. Ele nunca deve ser modificado manualmente.

Você pode ajustar algumas configurações do diário usando o SMP (Administração do Sistema > Configuração > Configuração do Sistema > Configurações do Diário) ou a rotina ^JRNOPTS, que é a opção 7 de ^JOURNAL. A maioria dessas configurações é armazenada no arquivo de parâmetros iris.cpf nas seções [config] e [journal]. Quase todas elas podem ser alteradas sem reiniciar o IRIS, mas podem incorrer em uma troca de arquivo de diário.

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=RCPF_config

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=RACS_journal

As seguintes configurações estão tanto no SMP quanto na ^JRNOPTS.

  1. Diretórios de diário primário e alternativo - Se ocorrer um erro ao gravar no diretório de diário primário, vamos trocar automaticamente para o outro.
  2. Limite de tamanho do arquivo de diário - o padrão é 1.024 MB, mas pode ser ajustado para até 4.079 MB.
  3. Prefixo do nome do arquivo do diário
  4. Critério de limpeza do arquivo de diário - O critério padrão é 2 dias ou 2 backups bem-sucedidos. Se um dos limites for atingido, o arquivo será removido ao executar a tarefa de limpeza do diário (diariamente). O backup online do IRIS relatará automaticamente se tiver êxito para essa finalidade. Se você estiver usando uma solução de backup externa, poderá informar o backup bem-sucedido ao IRIS chamando esta função: $$BACKUP^DBACK("","E").
  5. Compactar arquivos de diário - o padrão é ativado. Os arquivos de diário não ativos serão compactados.

O SMP contém outras configurações que não estão em ^JRNOPTS, incluindo "Congelar em caso de erro" - entender essa configuração é importante o suficiente para eu discutir suas implicações na seção a seguir. Resumindo, nossa recomendação é ativar essa configuração.

Há outras configurações disponíveis na página "Configurações do Diário" que são menos usadas, como "Sessão da Web do Diário", "Diretório do Diário de Imagem de Gravação" e "Tamanho alvo para o wij". Informações sobre essas configurações estão disponíveis na documentação do CPF. Não vou abordá-las porque são situacionais.

Há também configurações avançadas de diário disponíveis em outros locais do SMP.

Observação: a partir de 2023.3, um novo recurso de arquivamento de diário foi lançado para que os diários compactados possam ser movidos para um drive separado.

Em Administração do Sistema > Configuração > Configurações Adicionais > Memória Avançada, você pode modificar os buffers do diário (jrnbufs), que têm, por padrão, 64 MB, mas podem variar de 8 ou 16 MB a 1.024 MB, dependendo se a sua instalação for de 8 bits ou Unicode. Essa configuração controla o tradeoff entre desempenho e confiabilidade (os dados do diário armazenados na memória/buffers são mais rápidos, mas temporários em caso de falha).

Em Administração do Sistema > Configuração > Configurações Adicionais > Compatibilidade, temos a configuração "SynchCommit", que determina quando um comando TCOMMIT solicitará que os dados estejam no disco. True faz com que TCOMMIT espere a gravação do diário, mas o padrão false permite que TCOMMIT retorne antes da gravação. Isso está relacionado às transações, que são abordadas algumas seções abaixo.

 

Congelamento do diário em caso de erro

A configuração "Freeze on error", ou "Congelar em caso de erro", (Administração do Sistema > Configuração > Configuração do Sistema > Configurações do Diário) determina como o IRIS responderá aos erros de I/O do diário. O tradeoff que você precisa considerar é a disponibilidade em relação à integridade dos dados e das transações.

Essa configuração está desativada por padrão. Caso ocorra um erro no diário, você pode esperar o seguinte comportamento. O daemon do diário tentará novamente a cada 1s (padrão) até passar 150s (padrão) ou a instância ficar sem memória (buffers globais) para as atualizações do diário. Nesse momento, o diário será desativado em todo o sistema, impedindo que os dados após esse ponto sejam recuperáveis em um cenário de desastre. Outras preocupações com o diário desativado são que a reversão da transação falhará, o espelhamento falhará e o bloqueio do ECP/recuperação da transação será comprometido. Quando o diário for desativado devido a um erro, uma mensagem será registrada em messages.log informando que você precisará reativar manualmente o diário usando ^JRNSTART. Além disso, recomendamos que, em caso de execução com o diário desativado, você resolva o problema, troque o arquivo do diário e faça backup dos bancos de dados.

Em geral, recomendamos ativar "Congelar em caso de erro", ou seja, se ocorrer um erro com o diário, o IRIS congelará para que você resolva o problema. Todas as atualizações de globais do diário serão interrompidas, e as atualizações de globais serão congeladas quando o daemon do diário ficar inativo por 30s. O daemon do diário continuará tentando e descongelará quando tiver sucesso. Isso provavelmente travará o IRIS até que o problema do diário seja resolvido. Você verá mensagens de gravidade 3 em messages.log avisando você ao tentar novamente a I/O com falha.

Para explicar melhor o comportamento em relação à reversão da transação, com "Congelar em caso de erro" desativado, um TROLLBACK com falha encerrará a transação e liberará os bloqueios. Com a configuração ativada, o processo de abertura da transação será interrompido e CLNDMN tentará repetidamente reverter a transação. Os bloqueios serão mantidos durante essa operação. Se CLNDMN estiver tentando reverter uma transação para um trabalho inativo (como mostrado em messages.log), você poderá usar Manage^CLNDMN para encerrar manualmente a transação. As considerações aqui são semelhantes às discutidas acima: disponibilidade x integridade.

Observação: isso só se aplica à reversão local (não ECP).

 

Integridade dos dados

O diário é fundamental para a recuperação de desastres. Ao gravar em um banco de dados do IRIS, o IRIS grava essas mudanças duas vezes antes de tocar no banco de dados em si. Todos os sets e kills são registrados no diário, que é gravado pelo menos a cada 2 segundos (há alguns outros gatilhos que vou omitir para simplificar). As alterações também são gravadas no diário de imagem de gravação (WIJ), que armazena as modificações do banco de dados por até 80s antes de serem gravadas no banco de dados em uma passagem. A combinação de diários e do WIJ garante que, em caso de falha, seja possível verificar novamente o que gravamos nos diários, no WIJ e no banco de dados.

Essa é uma breve explicação. Para saber mais, nosso "Guia de integridade dos dados" é um excelente recurso.

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCDI

Quando o IRIS é inicializado após uma interrupção anormal, ele determinará se precisa reaplicar o WIJ ou não e reproduzirá diários (como os diários são gravados com mais frequência, eles podem estar mais atualizados). Se você restaurar um backup, os diários podem/devem ser aplicados em seguida para reproduzir a sequência de sets e kills e atualizar o banco de dados. Sem o diário, você só poderá restaurar até o ponto do backup, quando ele tiver sido feito.

 

Transações

Os diários também facilitam as transações. Resumindo, as transações são usadas para garantir que uma sequência de alterações no banco de dados possam ser tratadas como uma única operação. Você provavelmente já ouviu falar do exemplo do caixa eletrônico: você não quer sacar dinheiro de uma conta, mas fazer com que não alcance seu destino. Ao colocar uma sequência de sets e kills entre os comandos "TSTART" e "TCOMMIT", com o bloqueio adequado para lidar com vários processos, você pode ter certeza de que, se uma das mudanças for gravada no disco, todas as alterações terão persistido. Se um erro ou outro evento impedir que o processo alcance o TCOMMIT, nenhuma das mudanças na transação será feita. Se você iniciar uma transação, mas não conseguir fazer o commit devido a um erro ou outro evento, o IRIS pode consultar o diário para desfazer todas as mudanças no banco de dados, voltando ao TSTART. Pela natureza das transações, mesmo se um banco de dados não tiver um diário, uma transação ainda será registrada em um diário. Esteja ciente de que isso se aplica somente a reversões de tempo de execução e, para uma inicialização de recuperação, não ocorrerá a reversão.

Uma explicação mais detalhada sobre as transações está disponível em nossa documentação "Processamento das transações":

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GCOS_tp

 

Espelhamento

O espelhamento é a solução de alta disponibilidade / recuperação de desastres / réplica de dados da InterSystems. No espelhamento, uma instância do IRIS envia seus diários a uma ou mais instâncias do IRIS, que executam em sequência os mesmos sets e kills (esse processo se chama "dejournaling") para manter os bancos de dados sincronizados. Isso permite a réplica de dados lógica em nós. Você nunca pode desativar o diário em um banco de dados espelhado por esse motivo.

Depois de se tornar um membro espelho primário, os arquivos de diário criados terão "MIRROR" no nome e o log do diário será registrado em um mirrorjrn-mirror_name.log, bem como no journal.log regular. Os outros membros espelho armazenarão os diários espelho junto com seus próprios diários e manterão uma cópia do log do diário espelho; mirrorjrn-mirror_name.log é criado em install-dir/mgr/.

Há outras ressalvas para o diário e o espelhamento que tentarei mencionar quando relevante. Nossa documentação sobre o espelhamento está aqui:

https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=GHA_mirror

 

Ressalvas ao espelhamento

Esta seção provavelmente só é interessante para você se estiver usando o espelhamento. Ela discutirá como a localização dos arquivos de diário, o critério de limpeza e a configuração "Congelar em caso de erro" são afetados pelo espelhamento.

O critério de limpeza padrão para os arquivos de diário são um determinado número de dias ou backups. No entanto, se pelo menos um desses gatilhos for atendido, os arquivos do diário espelho podem ser preservados se forem necessários para a sincronização. Por exemplo, se um diário for necessário para concluir uma transação em qualquer membro espelho, ele não será removido.

Um membro de tolerância a falhas primário só limpará um arquivo de diário depois que o critério de limpeza for atingido e o arquivo tiver sido recebido por todos os membros espelho assíncronos e de backup. Isso é aplicável a menos que um assíncrono tenha sido desconectado há >14 dias.

Um membro de tolerância a falhas de backup ou assíncrono de recuperação de desastres limpará um diário após o arquivo passar por dejournaling, o critério de limpeza local for atendido e o diário for recebido por todos os assíncronos. É aplicável a mesma exceção de 14 dias conforme acima.

Em um assíncrono de relatório, os diários espelho são removidos imediatamente após o dejournaling por padrão. Isso pode ser modificado nas configurações do membro espelho (no CPF: AsyncUseSystemPurgeInterval).

O tempo limite de 14 dias pode ser modificado usando o método SYS.Mirror.JrnPurgeDefaultWait, documentado aqui:

https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=SYS.Mirror#JrnPurgeDefaultWait

A configuração de diário "Congelar em caso de erro" é ativada automaticamente para um membro espelho primário, já que não consegue continuar operando como um membro espelho sem o diário. Se o congelamento continuar por muito tempo, o membro de tolerância a falhas de backup deve detectar a inatividade e assumir como primário.

 

Quando você deve evitar o diário

Agora temos uma ideia do motivo pelo qual o diário é usado e geralmente deve estar ativado. Mas há algumas situações em que você deve evitar o diário? Para isso, indico essa breve série de artigos escritos por Tani Frankel para Caché, mas aplicável ao IRIS, que aborda os seguintes tópicos:

  1. Como determinar o que está causando a atividade de diário incomum usando o perfil do diário ou ^JRNDUMP.
  2. Uma discussão sobre o que precisa de diário e por que - ele também discute a recuperação de desastres e as transações. Se você não precisar recuperar dados e não estiver usando transações, o diário pode ser razoável ou não.
  3. Métodos para evitar o diário - em todo o sistema (^JRNSTOP), CACHETEMP (agora IRISTEMP), mapeando para bancos de dados sem diário, no nível do processo (^%NOJRN) e ao arquivar um objeto.

https://community.intersystems.com/post/what-causing-journals-grow-rapidly

https://community.intersystems.com/post/my-growing-journals-how-do-i-minimize

https://community.intersystems.com/post/preventing-globals-getting-journaled-continued-how-do-i-minimize-my-journals

 

 

Tarefas de operação de diário

Neste capítulo, vou abordar algumas operações de diário comuns que você pode precisar realizar. Uma lista mais completa de utilitários de diário poderá ser vista no terceiro capítulo, "Utilitários de diário".

Não é possível inicializar e interromper diários no nível da instância pelo portal de gerenciamento de sistemas. Você só pode fazer essa alteração através de ^JOURNAL ou usando ^JRNSTART e ^JRNSTOP.

As principais páginas de Diário no portal de gerenciamento estão localizadas em Operação de Sistema > Diários.

Para trocar os diretórios de diário, há um botão "Switch Directory" (Trocar diretório) na página de Diários no SMP, além do SWDIR^JOURNAL, que é a opção 13 em ^JOURNAL. Se você não tiver outro diretório definido, essa opção não estará disponível.

Para trocar para um novo arquivo de diário, você pode usar o botão "Switch Journal" (Trocar diário) na página de Diários no SMP ou utilizar o ^JRNSWTCH, que é a opção 3 em ^JOURNAL. Os arquivos de diário mudarão automaticamente após um backup bem-sucedido, se um arquivo de diário ficar cheio, se o diretório ficar indisponível e ao mudar as configurações do diário.

Se você quiser revisar o conteúdo de um arquivo de diário, poderá fazer isso no portal de gerenciamento de sistemas (Operação de Sistema > Diários) ou usando ^JRNDUMP. SELECT^JRNDUMP permitirá que você despeje registros de diário específicos em um arquivo, filtrando por uma variedade de critérios.

Observação: se você precisar conferir um arquivo de diário arbitrário, pode mudar o URL dessa página do SMP para que aponte para outro arquivo. Isso presume que o IRIS tenha permissões para acessar esse arquivo.

Para obter uma visão geral do conteúdo de um diário, você deve criar o perfil do diário usando a opção "Perfil" na página de Diários do SMP. Isso dará a você uma ideia dos globais que estão sendo alterados - a frequência e em quais bancos de dados. Você também pode ver um resumo dos metadados do arquivo de diário usando a opção "Resumo" na página de Diários. Isso contém informações como os bancos de dados envolvidos, se eles são criptografados e quando o arquivo de diário foi criado. A página de Diários também oferece a possibilidade de realizar uma verificação de integridade em um arquivo de diário.

Se você precisar limpar manualmente seus diários, por exemplo, se alguma atividade incomum de banco de dados causar registros excessivos no diário, é possível fazer isso usando PURGE^JOURNAL, a 6ª opção de ^JOURNAL. Assim, você pode fazer a limpeza com base no seu critério padrão ou remover todos os diários desnecessários para a transação ou recuperação da falha. A tarefa "Limpar Diário" padrão (Operação de Sistema > Gerenciador de Tarefas > Programação de Tarefas) é executada às 00:30, logo após a tarefa padrão "Trocar Diário" às 00:00. Se uma limpeza falhar, por exemplo, o arquivo de diário for necessário para uma transação ou espelhamento, você pode esperar uma mensagem de messages.log informando sobre isso. Você não deve tentar excluir arquivos de diário no nível do SO, já que isso pode causar o desalinhamento do sistema de arquivos com o journal.log e a quebra de operações de diário padrão.

Por fim, você pode se deparar com uma situação em que seja necessário executar uma restauração manual do diário. Os mecanismos exatos são mais discutidos na seção ^JRNRESTO, mas os conceitos básicos são os seguintes. ^JRNRESTO é a opção 4 de ^JOURNAL, e você deve garantir que os usuários não estejam no sistema, que o diário seja interrompido e que você tenha restaurado seu backup. Em seguida, pode executar o ^JRNRESTO e reiniciar o diário. Essa operação não está disponível no portal de gerenciamento de sistemas, porque só é usada em circunstâncias de força maior.

 

Acesso avançado às informações do diário

Para uso mais avançado, como determinadas soluções de problemas ou necessidades programáticas, o global ^%SYS("JOURNAL") contém informações detalhadas sobre o diário. O %SYS.Journal.System contém consultas e métodos do diário, conforme documentado aqui:

https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=%25SYS.Journal.System

 

 

Utilitários do diário:

^JOURNAL

Nas duas seções anteriores, mencionei os utilitários do diário. Vários deles são agregados no ^JOURNAL, uma rotina disponível no namespace %SYS. Essa seção será mais detalhada do que as seções anteriores e darei exemplos específicos de caminhos de prompts. Você pode achar isso mais útil como uma referência do que um artigo para leitura.

A interface oferecerá essas opções:

1) Iniciar o diário (^JRNSTART)

 2) Parar o diário (^JRNSTOP)

 3) Trocar o arquivo do diário (^JRNSWTCH)

 4) Restaurar os globais do diário (^JRNRESTO)

 5) Exibir o arquivo do diário (^JRNDUMP)

 6) Limpar os arquivos do diário (PURGE^JOURNAL)

 7) Editar as propriedades do diário (^JRNOPTS)

 8) Ativar ou desativar a criptografia do diário (ENCRYPT^JOURNAL())

 9) Mostrar o status do diário (Status^JOURNAL)

10) -não disponível-

11) -não disponível-

12) Atualizar diário com os bancos de dados espelhados (MirrorCatchup^JRNRESTO)

13) Trocar diário para o diretório secundário (SWDIR^JOURNAL)

Vou descrever essas opções na ordem da quantidade de detalhes que fornecerei, da mais simples para a mais complexa. Observe que algumas opções (como 10 e 11 acima) podem aparecer como "-não disponível-" dependendo da sua configuração. Vou indicar isso.

Opções 1 "Iniciar diário (^JRNSTART)", 2 " Parar diário (^JRNSTOP)", 3 " Trocar arquivo do diário (^JRNSWTCH)" e 13 "Trocar diário para o diretório secundário (SWDIR^JOURNAL)" são simples, já que realizam uma única operação. A opção 13 ficará indisponível se a instância não tiver um diretório de diário alternativo configurado.

A opção 12 "Atualizar diário com os bancos de dados espelhados (MirrorCatchup^JRNRESTO)" também é uma operação básica para uma instância espelhada e iniciará uma atualização de espelho. O diário não precisa estar ativado nesse momento, mas precisa ter sido iniciado pelo menos uma vez desde a inicialização do IRIS para ter o diretório do diário atual na memória

A opção 7 "Editar propriedades do diário (^JRNOPTS)" permite que você modifique 5 configurações de diário básicas. Você pode mudar os diretórios do diário, o limite de tamanho do arquivo do diário, o prefixo do arquivo do diário e seu critério de limpeza.

A opção 10 oferece a "Restauração de cluster de diário (CLUMENU^JRNRESTO)". As considerações de cluster ECP estão além do que abordarei neste artigo, mas você pode encontrar informações sobre essa opção aqui na documentação do Caché:

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_cluster_journal#GCDI_cluster_tools_cjr

A opção 8 é "Ativar ou desativar a criptografia do diário (ENCRYPT^JOURNAL())", e uma descrição profunda será omitida. Destaco que essa configuração se aplica a arquivos de diário futuros. Para configurar os arquivos de diário criptografados, veja esta documentação:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ROARS_encrypt_dbmgmt#ROARS_encrypt_dbmgmt_startup_ejf

A opção 6 "Limpar arquivos de diário (PURGE^JOURNAL)" permite que você limpe com duas opções diferentes: com base no critério configurado (dias e backups bem-sucedidos) ou qualquer diário que não seja necessário para a reversão da transação ou recuperação de falhas. Ela relatará quais arquivos de diário foram removidos.

A opção 9 "Mostrar o status do diário (Status^JOURNAL)" oferece algumas metainformações sobre o diário. Ela dirá o status atual do diário, incluindo:

  1. Os diretórios do diário e quanto espaço eles ainda têm.
  2. O arquivo de diário atual, o tamanho máximo e quão cheio ele está.
  3. Se o diário está ativado ou desativado e, caso esteja desativado, o motivo. Observe que, se estiver desativado devido a um erro de I/O, se o status relatar congelamento, os dados do diário serão descartados.
  4. Se aplicável, ele conterá o ID do processo que está executando ^JRNSTART, ^JRNSTOP ou ^JRNSWTCH.

As opções 11, "Gerenciar reversão de transação pendente ou em andamento (Manage^JRNROLL)", 5 "Exibir o arquivo do diário (^JRNDUMP)" e 4 "Restaurar os globais do diário (^JRNRESTO)" são tão envolvidas que eu as separei em seus próprios cabeçalhos.

 

Opção 11 de ^JOURNAL: Manage^JRNROLL

Em geral, a reversão da transação deve ser rápida, já que as transações só podem ser abertas por breves períodos, mas, se uma transação for deixada aberta por tempo prolongado, a instância pode precisar verificar um número significativo de arquivos de diário antes da inicialização normal do sistema. Verificamos as transações abertas na inicialização da instância e ao se tornar um membro espelho primário.

Se o tempo de atividade do sistema for essencial, Manage^JRNROLL pode suspender temporariamente o processo de reversão. Em geral, não recomendo usar esse utilitário, já que você quase certamente sacrificará a integridade transacional. Será preciso avaliar se o tempo de atividade é importante o suficiente para fazer esse tradeoff, e você também precisará se preparar para tomar qualquer medida necessária para solucionar o estado dos dados quando as transações não estiverem sendo resolvidas corretamente.

Não posso discutir todo cenário possível aqui, mas recomendo que você entre em contato com a WRC para receber ajuda se achar que precisa usar isso.

Além disso, Manage^JRNROLL permite que você monitore o processo de reversão. Ele dirá a você se a instância está verificando os arquivos de diário ou está realizando a reversão, quantos MB ainda precisam ser processados dos diários e quantas transações abertas foram encontradas. Outra opção para monitorar a reversão é o messages.log. Em versões modernas, você deve receber mensagens do messages.log relatando a quantidade de dados que ainda precisam ser processados e o número de transações abertas.

 

^JRNRESTO

Depois de aplicar um backup, ^JRNRESTO é o utilitário usado para aplicar os arquivos de diário do momento do backup até o presente. Isso se chama "dejournaling." ^JRNRESTO só afetará os bancos de dados que estão definidos como diário ao executar a rotina.

^JRNRESTO oferece vários recursos para definir os diários que serão restaurados. Principalmente, você pode especificar vários arquivos de diário. Você também pode selecionar bancos de dados ou globais específicos para serem atualizados. Além disso, é possível selecionar bancos de dados ou globais individuais para a restauração. Para mais granularidade, você pode usar um filtro de diário personalizado de ^ZJRNFILT, que será abordado depois. Você também pode restaurar para a instância atual ou para os bancos de dados de outra instância do IRIS. ^JRNRESTO também pode ser usado para inicializar a atualização do espelho se você estiver tentando restaurar finais de diário espelho para um banco de dados espelhado no mesmo espelho. Nesse caso, ele simplesmente usará MirrorCatchup^JRNRESTO.

 

Desempenho do ^JRNRESTO

^JRNRESTO permite que você desative o diário para as atualizações de restauração, que melhorará o desempenho. Para aumentar ainda mais a velocidade do dejournaling, o dejournaling em paralelo pode usar até 4 jobs para atualizar vários bancos de dados ao mesmo tempo. Para usar isso, você precisaria de pelo menos 8 CPUs e heap de memória compartilhada suficiente configurada (gmheap). Cada job paralelo que você quer usar requer 200 MB de gmheap, ou seja, é necessário um mínimo de 400 MB de gmheap para usar o dejournaling em paralelo. Mesmo se você não alcançar esse limite, aumentar o heap de memória compartilhada pode melhorar o desempenho. É possível modificar a configuração de gmheap no portal de gerenciamento (Administração do Sistema > Configuração > Configurações Adicionais > Memória Avançada) e exige a reinicialização. Se a configuração permitir, por padrão, o IRIS usará o dejournaling em paralelo.

 

Usando ^JRNRESTO

Você pode iniciar a restauração do diário ao trocar para o namespace %SYS e inserir "do ^JRNRESTO". A melhor forma de se familiarizar com esse utilitário é testar por conta própria, já que você pode ter uma ideia melhor do tipo de restauração de diário que talvez seja necessário em seu ambiente. Exemplos de prompts e amostras de saída estão disponíveis na documentação, e descreverei as etapas do processo, para você saber o que esperar.

Se a instância está em um espelho, o primeiro prompt perguntará se você quer "Atualizar bancos de dados espelhados? Não =>". Sua resposta aqui determinará se você será redirecionado para MirrorCatchup^JRNRESTO ou seguirá com mais prompts para especificar manualmente quais diários devem ser restaurados para quais bancos de dados.

Se você definiu um filtro de diário (ZJRNFILT, discutido abaixo), precisará responder se esse filtro deve ser usado ou não. MARKER^ZJRNFILT não é aplicável à grande maioria dos casos de uso:

"Usar filtro de diário atual (ZJRNFILT)?

Usar filtro de marcador de diário (MARKER^ZJRNFILT)?"

Depois disso, você pode especificar se quer "Processar todos os globais de diário em todos os diretórios?" ou não. Se você não quiser restaurar nada, precisará responder a uma série de prompts para declarar o que exatamente deseja restaurar. Você poderá escolher bancos de dados (mesmo para uma instância diferente do IRIS) e globais para cada banco de dados.

 

Como identificar bancos de dados para ^JRNRESTO

O primeiro esclarecimento solicitado será "Os arquivos de diário são importados de um sistema operacional diferente?" Isso determinará se ^JRNRESTO pode usar o formato de caminho de diretório padrão do SO.

A próxima etapa será especificar o caminho do diretório para o banco de dados de origem no prompt "Diretório para restaurar [? para ajuda]". Se você estiver restaurando diários espelhados para um banco de dados não espelhado, também pode usar o nome de espelho completo aqui (por exemplo, :mirror:<mirror_config_name>:<mirror_db_name>). O seguinte prompt é "Redirecionar para o diretório", para selecionar o banco de dados de destino. Você pode escolher o padrão e pressionar <enter> para selecionar a origem como o destino.

Para cada banco de dados, se devem ser restaurados todos ou alguns globais específicos.

"Processar todos os globais em <directory_to_db>? Não =>"

Depois de inserir todos os bancos de dados que você quer restaurar, você pode pressionar <enter> em "Diretório para restaurar [? para ajuda]:" a fim de prosseguir. Você precisará confirmar suas seleções.

OBSERVAÇÃO: se você estiver restaurando vários bancos de dados de origem para um banco de dados de destino, precisará fazer a mesma seleção de globais ou restaurar todos os globais.

 

Como identificar os arquivos de diário para ^JRNRESTO

^JRNRESTO tenta facilitar o máximo possível a restauração de uma sequência de arquivos de diário. Seja fazendo qualquer especificação de banco de dados acima ou restaurando todas as entradas, o primeiro prompt é "Os arquivos de diários foram criados por essa instância do IRIS e estão localizados nos seus caminhos originais? (Usa journal.log para localizar diários)?" Se você selecionar "sim", ^JRNRESTO poderá gerar uma lista de arquivos de diário disponíveis a partir do journal.log, em vez de exigir que o usuário direcione manualmente o processo para os arquivos de diário. Também é possível selecionar "não, você deverá responder se tem uma cópia do journal.log a partir da instância do IRIS de origem, e apontar para o diretório com os arquivos de diário que você quer restaurar.

Em ambos os casos, você receberá o prompt a seguir, onde poderá ver uma lista de arquivos de diário e fazer sua seleção. Os backups iniciam a troca de diário e registram uma mensagem (se você iniciar um congelamento externo para um backup externo, isso será registrado no messages.log), que pode servir como guia para os diários que você quer restaurar:

"Especifique a variedade dos arquivos que serão processados

Insira ? para abrir uma lista de arquivos de diário e selecione o primeiro e o último arquivo de

Primeiro arquivo para processar:"

Se você não tiver um arquivo journal.log para consulta, ainda poderá fornecer nomes de arquivos de diário e um diretório para procurar arquivos.

O IRIS deixará você revisar os arquivos selecionados e perguntará se você quer verificar a integridade dos arquivos de diário. Se você estiver tentando restaurar um arquivo de diário ativo, o IRIS exigirá e solicitará que você troque o arquivo.

 

Outras opções variadas para ^JRNRESTO

Como descrito acima, o dejournaling em paralelo pode ser usado para melhorar o desempenho. Se você estiver usando o dejournaling em paralelo, o processo não será registrado em diário. Se você não estiver usando o dejournaling em paralelo, ainda terá a opção de desativar o diário dessas atualizações, melhorando o desempenho.

A escolha final que você fará antes de começar a restauração do diário será como responder a erros. Você pode selecionar respostas a erros nos níveis do banco de dados e do diário. É possível determinar se você quer continuar ou abortar o processo caso haja qualquer tipo de erro. Se você decidir abortar em qualquer um dos casos, o dejournaling em paralelo não poderá ser usado.

O processo começará a relatar seu progresso, informando qual arquivo de diário está sendo processado e a % de conclusão periodicamente. Quando a restauração for concluída, aparecerá um resumo dela.

Observação: ao restaurar diários, as transações abertas serão revertidas. Para garantir que você não tenha preocupações de integridade das transações, reverta ou use o commit nas transações. Se você tiver preocupações com a atividade do usuário, pode reiniciar o IRIS no modo de usuário único, conforme documentado aqui:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=ASECMGMT#ASECMGMT_emerg

 

^ZJRNFILT

Você pode usar ^ZJRNFILT para criar um filtro personalizado para uso durante a restauração do diário, controlando os sets e kills aplicados. Você precisará criar uma rotina personalizada aceitando os seguintes parâmetros.

ZJRNFILT(jid,dir,glo,type,restmode,addr,time)

jid - ID do job para identificar o PID que gerou o diário

dir - caminho completo do diretório com o IRIS.DAT que será restaurado, especificado no registro do diário

glo - global no registro do diário

type - tipo de comando conforme especificado na documentação aqui:

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_journal#GCDI_journal_type_tbl

restmode - defina isso como 1 ou 0 no seu código personalizado para determinar se um registro deve ser restaurado

addr - endereço do registro do diário

time - carimbo de data/hora do registro (formato $horolog). Observe que essa é a hora em que o buffer do diário é criado, e não quando realmente ocorre o set/kill.

Exemplos de como escrever um ^ZJRNFILT estão disponíveis na documentação. Se a rotina ^ZJRNFILT personalizada existir, a restauração do diário solicitará que você use o filtro. Ao usá-lo, o filtro será chamado em cada registro do diário. Isso usará a lógica que você escrever na rotina, envolvendo quaisquer parâmetros que você queira usar, para definir o restmode como 1 (aplicar) ou 0 (não aplicar).

Considerações especiais

Se o processo de inicialização ^STU chamar ^JRNRESTO, ele não aplicará seu filtro ZJRNFILT personalizado.

Quando a restauração do diário for concluída, você deverá renomear ou excluir o ^ZJRNFILT. Ao renomear a rotina, ela será copiada para ^XJRNFILT, e ^ZJRNFILT será excluído.

Se ^ZJRNFILT se deparar com um erro, o processo de restauração será abortado.

 

^JRNDUMP

Às vezes, o portal de gerenciamento pode não ser suficiente para analisar os arquivos do diário. Isso pode acontecer devido ao arquivo do diário ser tão grande que ocorre um tempo limite. Nesses casos, você pode usar ^JRNDUMP ou SELECT^JRNDUMP para despejar os registros do diário, facilitando a visualização.

^JRNDUMP mostrará uma seleção de arquivos de diário e o diretório onde podem ser encontrados. Você pode usar as seguintes opções para navegar pela exibição: "Pg(D)n,Pg(U)p,(N)ext,(P)rev". Você também pode usar "(G)oto" para indicar diretamente um arquivo de diário para investigar.

A opção "(I)nfo" fornecerá metadados de um arquivo de diário, incluindo o arquivo GUID, tamanho máximo, data e hora de criação, número de arquivos, min trans, arquivo anterior, arquivo GUID anterior, final do arquivo anterior, próximo arquivo, próximo arquivo GUID. A maioria dessas entradas é facilmente compreensível, porém, "Min Trans" contém o arquivo do diário e o deslocamento em que sabemos que todas as transações estão fechadas. Depois desse ponto, pode haver transações abertas. A partir daí, "(D)atabases" dirá quais bancos de dados são afetados por esse arquivo de diário. Todas as informações "(I)nfo" também estão disponíveis na página "Resumo do Arquivo do Diário" no portal de gerenciamento de sistemas.

"(E)xamine" mostrará as entradas individuais do diário com o endereço, ID do processo, operação, diretório, global e valor. Você pode usar (N)ext, (P)rev, (G)oto e (F)ind para navegar por esses endereços do diário. "(E)xamine" mais para analisar uma única entrada em profundidade, que fornecerá quase as mesmas informações disponíveis na página "Ver diário" do portal de gerenciamento de sistemas. Isso seria o endereço, tipo de operação, se a operação estava em uma transação, ID do job, ID do processo, ID do sistema ECP (0 se não estiver configurado para ECP), carimbo de data/hora, ordenação, endereço anterior e próximo, além do global e do seu novo valor. Se a entrada foi gravada em uma transação, o valor antigo também será listado.

Uma lista completa das diferentes operações/tipos está disponível na documentação (vinculada na parte superior da seção ZJRNFILT).

Há três tipos principais de registros de diário: registros de dados, marcadores de diário e cabeçalhos de diário. ^JRNDUMP não mostrará cabeçalhos de diário, e marcadores de diário são indicados por Tipo: JrnMark. Os marcadores de diário são usados para várias operações de sistema diferentes, como backups. Quase todas as entradas que você verá serão registros de dados.

 

SELECT^JRNDUMP

SELECT^JRNDUMP permite que você despeje entradas de diário filtradas no terminal ou em um arquivo. Você pode filtrar com base nos seguintes critérios:

SELECT^JRNDUMP(%jfile,%pid,%dir,%glo,%gloall,%operation,%remsysid)

%jfile - caminho completo de um arquivo do diário, o padrão é o arquivo atual

%pid - ID do processo, o padrão é "any"

%dir - diretório de um banco de dados, o padrão é "any"

%glo - referência do global, o padrão é "any"

%gloall - modificador de %glo. Se isso for 0, o filtro procurará exatamente pelo nome do global especificado por %glo. Se isso for 1, o filtro pegará os nomes dos globais com o parâmetro %glo

%operation - tipo de operação, o padrão é "any"

%remsysid - ID do sistema ECP, o padrão é "any"

Alguns exemplo de filtros especificados para SELECT^JRNDUMP estão disponíveis na documentação.

 

^STURECOV

Se a inicialização do IRIS se deparar com um erro de restauração de transação ou diário, você talvez seja colocado no modo de usuário único. Você verá uma mensagem de messages.log assim:

12/28/18-07:06:43:099 (1234) 1 1 erros durante a restauração do diário,

veja mais detalhes no arquivo messages.log.

A inicialização foi abortada, entrando no modo de usuário único.

Entre no IRIS com

     iris session IRIS -B

e execute ^STURECOV para ajudar na recuperação dos erros.

Dependendo do erro, ^STURECOV oferece diferentes opções para ajudar você a se recuperar.

Observação sobre o espelho: ^STURECOV não poderá ser executado em um banco de dados se a reversão de transação estiver em andamento, já que o banco de dados não montará a leitura/gravação até que a reversão seja concluída. A Opção 11 do ^JOURNAL acima: Manage^JRNROLL aborda o que você deve fazer nesse caso.

Especificamente para um erro de diário, o menu ^STURECOV ficará assim:

1) Exibir a lista de erros da inicialização

2) Executar a restauração do diário novamente

3) Derrubar o sistema antes de uma inicialização normal

4) Desmontar um banco de dados

5) Montar um banco de dados

6) Utilitário de conserto do banco de dados

7) Verificar a integridade do banco de dados

8) Redefinir o sistema para que o diário não seja restaurado na inicialização

9) Exibir instruções sobre como desativar o sistema   >>>>> [somente Unix]

10) Exibir Menu do Diário (^JOURNAL)

Alerta: a opção 8 é irreversível e impedirá que a próxima inicialização faça a restauração do diário. Nesse ponto, se você quiser restaurar diários, precisará usar ^JRNRESTO. Isso geralmente só deve ser usado se houver uma necessidade de contornar a recuperação e inicializar o IRIS.

 

^JRNMARK

Esse utilitário pode ser usado para adicionar um marcador de diário ao arquivo do diário - você provavelmente não precisará usá-lo. Ele é usado da seguinte maneira:

SET rc=$$ADD^JRNMARK(id,text)

"rc" retornará o deslocamento do diário e o nome do arquivo do diário. O id pode ser qualquer valor inteiro (entradas inválidas são definidas como 0 por padrão) e o texto pode ser qualquer string de até 256 caracteres.

Você poderá ver o marcador do diário no arquivo do diário, porém, se quiser analisar o texto ou o id, precisará usar ^JRNDUMP. O portal de gerenciamento de sistemas não oferece essa funcionalidade.

 

^JRNUTIL

^JRNUTIL inclui várias tags que permitem a manipulação de arquivos de diário programaticamente. Isso permite que você abra, exclua ou leia um arquivo de diário, entre outras opções.

Se você tiver interesse em usar essas funções, provavelmente deve falar direto com alguém da InterSystems.

 

^JCONVERT e ^%JREAD

Esses utilitários só são necessários para a conversão de DSM para Caché. Eles permitem que você converta arquivos de diário para um formato comum. Um exemplo está disponível na documentação, mas esse uso é específico o suficiente para que eu não o aborde aqui.

 

 

TLDR

Apenas leia a primeira seção e a documentação de melhores práticas. Espero que você tenha achado essa visão geral do diário útil - ela foi escrita por um humano (admin de sistema) para um humano. Fique à vontade para fazer comentários ou perguntas abaixo. Você também pode me enviar uma mensagem direta.

Discussão (0)0
Entre ou crie uma conta para continuar