发布新帖

查找

讨论 (3)3
登录或注册以继续
文章
· 五月 16, 2024 阅读大约需 3 分钟

Installation and adaptation of EMPI in Standalone mode - Notifying registrations and linkages to external systems

Reviewing the different articles that I have published, I realized that I needed to explain a very practical functionality within our EMPI (Enterprise Master Patient Index) and it is none other than the notification of registrations and links to systems external to the EMPI.

This functionality is frankly useful in a tool such as EMPI and especially in environments such as healthcare in which it is very common for the same patient to have their data duplicated in different systems and in the end it is necessary to uniquely identify it. The solution to reduce this amalgamation of records is to merge all this data into a single record that unifies all the available information.

In general, this work of deciding which records should be merged is quite complex if it is intended to be done by hand since it is very complicated to have access to the various systems that contain patient information (systems such as HIS, RIS, LIS, etc. from different providers distributed throughout the different centers of the health organization), but thanks to the EMPI linkage system this task is simplified by automating the vast majority of said links.

How can we inform that entire ecosystem of applications that they need to merge two patient records? Well, let's see it:

EMPI configuration

The first step to start generating notifications is to configure the PIX Notification Register:

Here we can see that by default we have two notification records:

One of the records is for PIXv3 notifications using HL7 v.3 messages (in XML) while the other will be PIXv2 using HL7 v.2 messaging.

In order to generate the necessary messages we must either define the domains in the field defined by default or check the All Domains box, this domain concept will correspond to the Assignment Authority (health services, hospital centers, etc.). With this step we will be defining the consumers of our output message; if we do not define any domain, the message will not be generated.

Now we open the production that manages the operation of the EMPI, let's take a look at the Business Process HS.IHE.PIX.Manager.Process that will be in charge of creating the response messages.

Let's pay attention to the configuration of said BP, as you can see we have two parameters PIXv2Operations and PIXv3Operations that are configured with 2 business operations of our production, the first of them will be in charge of receiving an HL7 v.2 message and the second an HL7 message v.3.

Let's now look at the BO  PIXv2.Notification.Operations:

As you can see, we have defined a BO of the EnsLib.HL7.Operation.FileOperation class since we will simply limit ourselves to writing the HL7 message for updating the patient data generated to a file on the server, but you could use any business operation that you have developed and that accepts HL7 messages as input, being able to forward them via TCP, embedded in a SOAP or through a REST call to an external API.

Testing

Let's look at an example of what happens with two patients in linkage review status after linking them normally.

We will link the first two, Juan García and Roberto Martín. Once the link is made, let's see the trace of the message:

Here we have our HL7 message generated of type ADT_A31 in which we report the update of the patient that has been linked to the new MPIID, now the patient Roberto Martín with MRN 556432 from Hospital 12 de Octubre has replaced his old MPIID (100001000) with the the same one that Juan García has (100000001).

Our EMPI will maintain a record for each patient, creating only the link with the MPIID assigned to both. With this ADT_A31 message it would now be the responsibility of the health service or hospital to merge both patients into one.

Conclusion

As we have seen in this article, EMPI has pre-built functionalities that cover the needs of any organization in a simple and agile way and allows us to expand them to cover those that are more specific to each client, one of them would precisely be automatic notifications. to any external application.

1 Comment
讨论 (1)2
登录或注册以继续
文章
· 五月 16, 2024 阅读大约需 3 分钟

Instalación y adaptación de EMPI en modo Standalone - Notificando altas y vinculaciones a sistemas externos

Revisando los diferentes artículos que he ido publicando he caído en la cuenta de que me faltaba explicar una funcionalidad bastante práctica dentro de nuestro EMPI (Enterprise Master Patient Index) y no es otra que la notificación de altas y vinculaciones a sistemas externos al EMPI.

Esta funcionalidad es francamente útil en una herramienta como es el EMPI y sobretodo en entornos como el sanitario en el cual es muy habitual que un mismo paciente tenga sus datos duplicados en diferentes sistemas y que al final es necesario identificar univocamente. La solución para reducir dicha amalgama de registros es la fusión de todos esos datos en un registro único que unifique toda la información disponible.

Por lo general este trabajo de decidir que registros deberían ser fusionados es bastante complejo si se pretende realizar a mano ya que es muy complicado tener acceso a los diversos sistemas que contengan información de pacientes (sistemas como el HIS, RIS, LIS, etc de diferentes proveedores distribuidos por los diferentes centros de la organización de salud), pero gracias al sistema de vinculaciones del EMPI esta tarea se simplifica al automatizar la gran mayoría de dichas vinculaciones.

¿Cómo podemos informar a todo ese ecosistema de aplicaciones que debe fusionar dos registros de paciente? Pues bien, veámoslo:

Configuración de EMPI

El primer paso para poder empezar a generar notificaciones es configurar el registro de notificación PIX:

Aquí podemos ver que por defecto tenemos dos registros de notificaciones:

Uno de los registros es para notificaciones PIXv3 mediante mensajes de HL7 v.3 (en XML) mientras que el otro será PIXv2 que utiliza mensajería HL7 v.2. 

Para poder generar los mensajes necesarios deberemos o bien definir los dominios en el campo definido por defecto o marcar la casilla All Domains, este concepto de dominio corresponderá con el de Autoridad de Asignación (servicios de salud, centros hospitalarios, etc). Con este paso estaremos definiendo los consumidores de nuestro mensaje de salida, si no definimos ningún dominio el mensaje no se generará.

Ahora abrimos la producción que gestiona el funcionamiento del EMPI echemos un vistazo al Business Process HS.IHE.PIX.Manager.Process que será el encargado de la creación de los mensajes de respuesta.

Prestemos atención a la configuración de dicho BP, como véis tenemos dos parámetros PIXv2Operations y PIXv3Operations que están configurados con 2 business operations de nuestra producción, el primero de ellos será el encargado de recibir un mensaje HL7 v.2 y el segundo un mensaje de HL7 v.3.

Veamos ahora el BO  PIXv2.Notification.Operations:

Como podéis ver hemos definido un BO de la clase EnsLib.HL7.Operation.FileOperation ya que simplemente nos limitaremos a escribir el mensaje HL7 de actualización de los datos de paciente generado a un fichero del servidor, pero podríais utilizar cualquier business operation que tengáis desarrollado y que acepte mensajes de HL7 como entrada, pudiendo reenviarlos vía TCP, incrustados en un SOAP o mediante una llamada REST a una API externa.

Pruebas

Veamos un ejemplo de lo que ocurre con dos pacientes en estado de revisión de la vinculación tras vincularlos normalmente.

Vincularemos a los dos primeros, Juan García y Roberto Martín. Una vez realizada la vinculación veamos la traza del mensaje:

Aquí tenemos nuestro mensaje HL7 generado de tipo ADT_A31 en el que informamos de la actualización del paciente que se ha vinculado con el nuevo MPIID, ahora el paciente Roberto Martín con MRN 556432 del Hospital 12 de Octubre ha reemplazado su antiguo MPIID (100001000) por el mismo que tiene Juan García (100000001). 

Nuestro EMPI mantendra un registro para cada paciente, creando únicamente la vinculación con el MPIID asignado a ambos. Con este mensaje ADT_A31 ahora sería responsabilidad del servicio de salud o del hospital fusionar ambos pacientes en uno sólo.

Conclusión

Como hemos visto en este artículo, el EMPI dispone de funcionalidades preconstruidas que cubren las necesidades de cualquier organización de una forma sencilla y ágil y nos permite ampliarlas para cubrir aquellas que sean más específicas de cada cliente, una de ellas sería precisamente la de notificaciones automáticas a cualquier aplicación externa.

讨论 (0)1
登录或注册以继续
问题
· 五月 16, 2024

RSA Encryption Decryption

Hi guys,

 

I try to make a test of encryption, decryption of a simple text.

I can crypt my text, but I can't decrypt it, do you see somewhere a dummy error of my part ?

Thanks for help

ClassMethod UnitTest()

{

  set inputPlainText = "David"

 

  // get private key

  set privKeyFileName = "C:\temp\toto.pem"

  set privobjCharFile = ##class(%Stream.FileCharacter).%New()

  set privobjCharFile.Filename = privKeyFileName

  set privKey = privobjCharFile.Read()

 

  set Inputbase64 = $SYSTEM.Encryption.Base64Encode(inputPlainText)

 

  // encrypte text using RSA

  set encryptText = $System.Encryption.RSAEncrypt(Inputbase64, privKey)

 

  // decrypt text using RSA

  set outputbase64 = $System.Encryption.RSADecrypt(encryptText, privKey)

 

  set plaintext = $SYSTEM.Encryption.Base64Decode(outputbase64)

 

  return plaintext

}

2 Comments
讨论 (2)1
登录或注册以继续
文章
· 五月 16, 2024 阅读大约需 26 分钟

外部バックアップの仕組みとバックアップとリストア方法について

開発者の皆さん、こんにちは。

この記事は、「インターシステムズ製品をバックアップする前に確認したいこと」に続く記事で、InterSystems製品のバックアップの手法の中の「外部バックアップ」の仕組みと、バックアップ・リストア手順について解説します。

まず、「外部バックアップ」とは、InterSystems製品の専用ルーチン使用せず、InterSystems製品以外のバックアップソリューションを使用してデータベースをバックアップする方法で、現時点の推奨されるバックアップ方法です。

詳細な説明、手順については、ドキュメント「外部バックアップ」をご参照ください。

外部バックアップでは、主に、論理ディスク・ボリュームの有効な "スナップショット" を迅速に作成するテクノロジと共に使用します。

例えば、

  • Windowsサーバの場合は、VSS(ボリューム・シャドウ・コピー・サービス)と組み合わせて利用する
  • AWSのEBS Snapshotと組み合わせて利用する

スナップショット・テクノロジが使用できないシステムであっても、後述する「特別な考慮」で対応できればご利用いただけます。

それでは早速、外部バックアップの前後で必要となるIRIS側の手続きと、バックアップとリストアについて確認していきましょう!

 

外部バックアップ前後で必要となる処理(ライトデーモンの一時停止と再開)

最初に、外部バックアップを実行するために、データベースに未反映の更新ブロックをデータベースに書き込む必要があります。

InterSystems製品では、ライトデーモン(WRTDMN)というシステムプロセスが、データベースに加わった変更をデータベースに書き込む一連の流れを管理しています。

通常時ライトデーモンは、以下の順序でデータベースに更新データを反映します。

① データベースキャッシュにたまった更新ブロックをライトイメージジャーナルファイル(WIJ)に退避し、正常に退避が完了すればリカバリ判定フラグをセットします。

更新ブロックのWIJへの退避が完了すると

② データベースファイルに更新ブロックを反映し、反映が正常に終了するとWIJにつけたリカバリ判定フラグをリセットします。

ライトデーモンは一定間隔(*)で①~②の処理を繰り返し実行します。

(*) この間隔はシステムにより短い頻度に変更される場合もあります。

外部バックアップを実行する場合、データベースへ書き込みを命令するライトデーモンの動作を止めない限り、正常なデータベースの退避が行えません。

タイミングが悪いと、②でIRIS.DATに反映させているブロックが一部のみの状態のデータベースファイルを退避してしまう可能性があり、このデータベースファイルを利用してリストアを行うことでデータベース壊す可能性があります。

この理由から、外部バックアップを実行する前にライトデーモンの処理を一時的に凍結させた状態でスナップショットを取り、スナップショットの取得が終了したらライトデーモンを凍結解除する手続きを行う必要があります。

外部バックアップ前後で利用するメソッドは以下の通りです。

 

ライトデーモンの働きについてさらに詳しく確認されたい場合は、ウェビナーアーカイブ:IRISデータベースの内部動作をご参照ください。

 

外部バックアップ手順

バックアップ手順は以下の通りです。

1) ライトデーモンの一時凍結(BackUp.GeneralクラスのExternalFreeze()

具体的なコマンドは以下の通りです。 InterSystems製品にログインし、%SYSネームスペースに移動します。

Linuxやコンテナ利用時は、iris session インスタンス名 -U %SYS/ ccontrol session インスタンス名 -U %SYS でログインできます。
set status=##class(Backup.General).ExternalFreeze()
write status

必ずExternalFreeze()の実行結果を確認してください。ライトデーモン(WRTDMN)の凍結が成功するとステータスOKとして1が返ります($$$OK)。

このコマンドがO/Sスクリプトの一部として使用された場合、システムの凍結に成功すると、Status値として5が返されます。凍結に失敗した場合は、Status値として3が返されます。実行例文はBackUp.GeneralクラスのExternalFreeze()をご参照ください。

またジャーナルファイルが切り替わります。

リストア作業を行う場合、ExternalFreeze()の実行により切り替わったジャーナルファイルからリストアを開始するため、ファイル名を記録しておきます。

ファイル名は、管理ポータル > [システムぺレーション] > [ジャーナル] より確認できます。「原因」列に「バックアップにより」と記載されている行のファイル名がバックアップにより切り替わったファイルです。

エラーの場合は、エラーステータスが戻るためエラー情報を確認するため、以下メソッドを実行してください。

write $system.Status.GetErrorText(status)

エラーステータスの取得方法について詳しくは、ObjectScriptクックブック%Statusのエラーが返ってきたらをご参照ください。

**注意!**
ExternalFreeze()でライトデーモン(WRTDMN)を凍結できる時間は10分(600秒)に設定されています。タイムアウト以内にExternalThaw()を実行しないとシステムの更新処理が一時停止状態になり、システムがハングアップした状態になります。ご注意ください。

なお、タイムアウト値を延長する方法については後述の「特別な考慮」をご覧ください。

2) 外部のスナップショット・ユーティリティを使用して、ファイル・システムのスナップショットを作成します。

リストアの目的別で退避内容が異なります。

✅ システム全体をリストアすることが目的の場合

以下をバックアップ対象として退避します。

  • データベースディレクトリ
  • インストールディレクリ
  • WIJディレクトリ
  • ジャーナルディレクトリ
  • 構成ファイル(cpf)

※ ジャーナルファイルについては、バックアップ時点のファイルだけでなく、バックアップ以降のファイルがリストアで必要となるため、バックアップ以降のファイルも何らかの方法で退避する必要があります。

✅ データベースのみのバックアップ

対象となるデータベースディレクトリ以下を退避します。

 

3) 2)が終了したら、ライトデーモンを再開(BackUp.GeneralクラスのExternalThaw())させます。

1) と同様に、InterSystems製品にログインし、%SYSネームスペースに移動し、以下実行します。

set status=##class(Backup.General).ExternalThaw()
write status

必ずExternalThaw()の実行結果もご確認ください。ライトデーモン(WRTDMN)の再開が成功するとステータスOKとして1が返ります($$$OK)。 エラーの場合は、エラーステータスが戻るためエラー情報を確認するため、以下メソッドを実行してください。

write $system.Status.GetErrorText(status)

 

特別な考慮

スナップショット・テクノロジが利用できない環境であっても、BackUp.GeneralクラスのExternalFreeze()の引数を利用することで実行することができます。

最初に注目すべき引数について説明します。

なお、引数を指定しない場合はデフォルト設定値で動作します。

 

第7引数:ExternalFreezeTimeOut

ExternalFreeze()でライトデーモンを休止する秒数を指定できます。(デフォルトは600秒(10分)に設定されています。

タイムアウトを迎えた場合、システムの更新処理が一時停止状態になり、システムがハングアップした状態になります。 ExternalThaw()を実行するまで、新規プロセスでInterSystems製品へログインすることができません。

※ ExternalFreeze()前から稼働中のプロセスは継続利用できますが、書き込みできなくなります。

 

第10引数:WDSuspendLimit

ライトデーモンを再開する時間を秒数で指定できます。 デフォルトは設定されていないため、ExternalThaw()の実行まで再開しません。

 

目的別留意点

第7、10引数に利用については、目的別の留意点があります。

 

A. バックアップを確実に成功させたい場合

第7引数:ExternalFreezeTimeOut を バックアップ時間より長めに設定 します。ただし、指定可能な値の上限は1200秒です(それ以上長い値を指定しても1200秒が使用されます)。

留意点としては、バックアップ中のユーザプロセスからの更新で、データベースキャッシュが満杯になると、書き込みを行おうとするユーザプロセスは一時停止します。

 

B. バックアップ中にユーザプロセスの一時停止を避けたい場合

第10引数:WDSuspendLimit を使用して、ライトデーモン再開までの秒数を指定します(デフォルトは設定されていないため、ExternalThaw()の実行までライトデーモンは再開しません)。

留意点としては、バックアップ途中でライトデーモンが再開した場合、バックアップは失敗します。バックアップが失敗したかどうかを確認するには、ExternalThaw()の実行前に IsWDSuspended()メソッド の戻り値を利用して、ライトデーモンが休止中かどうかを確認します。

1が戻ると休止中、0が戻ると動作中を表します。

 

その他の引数

第1引数:LogFile

ログファイル名をフルパスで指定できます。指定したファイル名が存在しない場合は作成し、存在する場合はログはファイルの末尾から追加されます。デフォルトでは、すべてのメッセージをmessages.log(またはcconsole.log)に記録します。

 

第2引数:Text

ジャーナル・マーカーに格納するオプションのテキスト文字列を指定できます。

 

第3引数:SwitchJournalFile

0/1 で、システムをフリーズする前に新しいジャーナル・ファイルに切り替え、ジャーナル・マーカを追加するかどうかを指定します。デフォルトは1(ジャーナルを切り替えます)。

 

第4引数:TimeOut

(クラスタ化されていないシステムでは無視される引数)クラスタ化されたシステムの場合、システムが静止するまでの待ち時間 (秒)を指定できます。デフォルト10秒。

 

第5引数:Hibernate

(クラスタ化されていないシステムでは無視される引数)クラスタ化されたシステムの場合、失敗を返す前に(データベースの更新を再開して)ハイバネートし、ブロックと待機の全プロセスを再試行する回数を指定できます。デフォルトは0。

 

第6引数:Verbose

(クラスタ化されていないシステムでは無視される引数)0/1 クラスタ化されたシステムの場合、何が起こっているかについてのメッセージを画面に出力するかどうか指定できます。デフォルトは0。

 

第8引数:Username

ExternalThaw() メソッドに渡すユーザ名を指定できます。デフォルトは "" です。

 

第9引数:Password

ExternalThaw() メソッドに渡すパスワードを指定できます。デフォルトは""です。

 

第11引数:RequiredFile

参照渡しで指定します。バックアップがリストアされた後、トランザクションのロールバックに必要な最も古いジャーナル・ファイル名が設定されます。

 

バックアップからのリストア方法

リストアの目的に合わせ、バックアップファイルを使用してリストアします。

システム全体のリストアを目的としている場合、バックアップ時点に退避したWIJを利用するか/しないか、で方法が異なります。

データベースのみのリストア方法については データベースのみのリストア方法 をご参照ください。

外部バックアップ実行時(=ExternalFreeze())WIJには、データベースの更新ブロックの情報以外にジャーナルファイルへのポインタ情報が含まれています。

  • トランザクションを開始している場合はトランザクションのオープン位置
  • データベースに正常に書き込まれたデータに対するジャーナルエントリへのポインタ

上記ポインタ情報を利用したリストア方法については システム全体のリストア:バックアップ時点に退避したWIJを利用したリストアの手順 をご参照ください。

ポインタを利用せずにリストアを行う方法については システム全体のリストア:バックアップ時点のWIJを使用しないでリストアを行う手順 をご参照ください。

 

システム全体のリストア:バックアップ時点に退避したWIJを利用したリストアの手順

このリストアのシナリオでは、外部バックアップ時にデータベースファイル(IRIS.DATまたはCACHE.DAT)とともにWIJをバックアップする必要があります。

1) InterSystems製品がダウンした状態のままとします。

2) データベースファイル(IRIS.DATまたはCACHE.DAT)とバックアップ時に退避したWIJをリストアします。

ダウンしたInterSystems製品の構成通りに配置します。

3) InterSystems製品を開始します。

開始時、WIJの情報を元に、その時利用していたジャーナルファイルを利用して、自動的にロールフォーワードを行います。

4) 妥当性の検証やメンテナンスを行う目的で、ジャーナルファイルをリストアします(オプション)。

ジャーナルリストアの流れは、10、ジャーナルリストアを実行をご参照ください。

※上記例の中ではジャーナルに記録されている情報の中から、特定のデータベースディレクトリに対する記録のみをリストアする方法を解説しています。データベースディレクトリを目的のディレクトリに読み替えてご利用ください。

5) InterSystems製品を停止します。

6) InterSystems製品を通常開始します。ユーザからの接続が許可されます。

 

システム全体のリストア:バックアップ時点のWIJを使用しないでリストアを行う手順

このリストアのシナリオでは、バックアップ時に退避しているWIJファイルを使用せずにリストアする方法を説明します(=バックアップ時点のWIJがない場合でもリストアできる方法)。

1) InterSystems製品がダウンした状態のままとします。

2) データベースファイル(IRIS.DATまたはCACHE.DAT)をリストアします。

ダウンしたInterSystems製品の構成通りに配置します。

3) InterSystems製品を開始します。

4) ダウンしたときのWIJを使用せず、開始します。

5) ジャーナルファイルをリストアします。

ジャーナルリストアの流れは、10、ジャーナルリストアを実行をご参照ください。

※上記例のジャーナルリストアではジャーナルに記録されている情報の中から、特定のデータベースディレクトリに対する記録のみをリストアする方法を解説しています。データベースディレクトリを目的のディレクトリに読み替えてご利用ください。

6) InterSystems製品を停止します。

7) InterSystems製品を通常開始します。ユーザからの接続が許可されます

 

データベースのみのリストア方法

他の正常なデータベースを通常状態に戻すため、以下の手順でリストアします。

1) 障害発生時のWIJを用いてリストアを行うため InterSystems製品を開始します。

WIJをロールフォーワードし、さらに障害発生直前まで使用していたジャーナルファイルを使用して、リストア対象ではない他の正常なデータベースを直近の状態までロールフォーワードします。

2) InterSystems製品を一旦停止します。

バックアップしていたデータベースファイル(IRIS.DATまたはCACHE.DAT)を利用して、データベースファイルを置き換えます。

3) InterSystems製品を開始します。

4) ジャーナルファイルをリストアします。

リストアを開始するため、的確なジャーナルファイルを決定します。通常、バックアップ前に切り替えられたジャーナルファイルを利用して、リストアを開始します。

ジャーナルリストアの流れは、10、ジャーナルリストアを実行をご参照ください。

※上記例のジャーナルリストアでは、ジャーナルに記録されている情報の中から、特定のデータベースディレクトリに対する記録のみをリストアする方法を解説しています。データベースディレクトリを目的のディレクトリに読み替えてご利用ください。

※ 手順1で障害発生時点のWIJを使用したロールフォーワードリカバリが正常に終了しない場合もあります。その場合はサポートセンターまでお問い合わせください。

 

演習:外部バックアップとリストア

この演習では、単一のデータベースのバックアップを例に、外部バックアップ、バックアップファイルのリストア、ジャーナルリストアについて練習します。

演習では、以下データベースを外部バックアップで退避します。

  • T1データベース=/usr/irissys/mgr/t1

以下例では、T1データベースのあるディスクが壊れたことを想定し、リストア時のT1データベースディレクトリがバックアップ時点とは異なるディレクトリにリストアしなくてはならない場合の流れで解説します。

なお、バックアップファイルのリストア後、ジャーナルファイルを利用したリストアも行う必要がありますので以下の流れで試していきます。

1、バックアップ前にT1データベースに任意データ登録する(^prebackup=1)

2、外部バックアップを実行する

3、切り替わったジャーナルファイル名を確認する

4、バックアップ後だとわかる任意データをT1データベースに登録する(^postbackup=1)

5、ジャーナルファイルに 4で登録した情報が含まれているか確認する

6、T1データベース(/usr/irissys/mgr/t1)を削除

7、T1データベースを別ディレクトリ(/usr/irissys/mgr/t1rest)に再作成

8、バックアップからのリストアを実行する

退避していたT1データベースのIRIS.datをリストア対象ディレクトリに置換します。

  • リストア対象ディレクトリ:/usr/irissys/mgr/t1rest

9、^prebackup=1 が戻ることを確認する

10、ジャーナルリストアを実行

T1データベースのみリストアするように指定します。

  • バックアップ時点のディレクトリ:/usr/irissys/mgr/t1
  • リストア時に指定するディレクトリ:/usr/irissys/mgr/t1rest

11、^postbackup=1 が戻ることを確認する


 

1、バックアップ前にT1データベースに任意データ登録する(^prebackup=1)

ネームスペースT1に接続し、以下実行します。

Linuxやコンテナを利用されている場合は、iris session インスタンス名 -U T1 でログインすると簡単です。

set $namespace="T1"
set ^prebackup=1

 

管理ポータルでデータを確認します。

[システムエクスプローラ] > [グローバル] > T1ネームスペース選択

グローバル変数名が多く一覧される場合、画面左端の「フィルタ」の「グローバル名」に pre* と書くとフィルタされた結果が表示されます。

 

2、外部バックアップを実行する

ライトデーモンを凍結させるため、以下実行します。

なお、ExternalFreeze()実行から10分後にタイムアウトを迎えます。タイムアウト前にExternalThaw()を必ず実行し、ライトデーモンの凍結解除を行ってください。

set status=##class(Backup.General).ExternalFreeze()
write status

変数statusに1が設定されていれば実行が成功したことを示します。

T1データベースディレクトリ(/usr/irissys/mgr/t1)を退避エリアにコピーします。

コピーが完了したら、凍結解除用メソッドを実行します。

set status=##class(Backup.General).ExternalThaw()
write status

 

3、切り替わったジャーナルファイル名を確認する

管理ポータル > [システムオペレーション] > [ジャーナル] 「バックアップにより」切り替わったジャーナルファイルを確認します。

以下の例でジャーナルリストアの開始ファイルとして指定するファイル名は「/usr/irissys/mgr/journal/20240426.002」です。

 

4、バックアップ後だとわかる任意データをT1データベースに登録する(^postbackup=1)

ネームスペースT1に接続し、以下実行します。

Linuxやコンテナを利用されている場合は、iris session インスタンス名 -U T1 でログインすると簡単です。

set $namespace="T1"
set ^postbackup=1

 

5、ジャーナルファイルに 4で登録した情報が含まれているか確認する

管理ポータル > [システムオペレーション] > [ジャーナル] で現在のジャーナルファイルを開き、^postbackupが記録されているか確認します。

画面右端のデータベースディレクトリ名を確認し、「/usr/irissys/mgr/t1」で記録されていることを確認します。

 

6、T1データベース(/usr/irissys/mgr/t1)を削除

管理ポータルメニューから削除します。

稼働中に削除する場合、一旦データベースをディスマウントすることをお勧めします。

管理ポータル > [システムオペレーション] > [データベース] > T1を選択 > ディスマウントボタンをクリック

ディスマウント後、構成メニューに移動しデータベースを削除します。

管理ポータル > [システム管理] > [構成] > [システム構成] > [ローカルデータベース] > T1を削除

この削除時に ”チェックしたネームスペースを削除します” の T1 にチェックを入れてT1ネームスペースも削除します。

 

7、T1データベースを別ディレクトリ(/usr/irissys/mgr/t1rest)に再作成

管理ポータルでT1ネームスペース、データベースを作成します。

このときのデータベースは最初に作成したディレクトリとは異なるディレクトリで作成します。

例では、/usr/irissys/mgr/t1rest としています。

 

8、バックアップからのリストアを実行する

作成したT1データベース(/usr/irissys/mgr/t1rest)をディスマウントします。

管理ポータル > [システムオペレーション] > [データベース] > T1を選択 > ディスマウントボタンをクリック

ディスマウント中に、退避していたT1データベースのIRIS.dat(元/usr/irissys/mgr/t1以下にあったIRIS.dat)を /usr/irissys/mgr/t1rest に置換します。

置換後、マウントボタンでデータベースをマウントします。

 

9、^prebackup=1 が戻ることを確認する

管理ポータル > [システムエクスプローラ] > [グローバル] > T1ネームスペース選択

^prebackupは表示されますが、^postbackupがまだ戻っていないことを確認します。

 

10、ジャーナルリストアを実行

続いて、ジャーナルリストアを実行します。

ご参考:^JRNRESTO を使用したジャーナル・ファイルからのグローバルのリストア

ジャーナルのリストアもジャーナルファイルに記録されている全データベースディレクトリではなく、/usr/irissys/mgr/t1 で記録されていた情報のみをリストアするようにします。グローバル変数まで指定してリストアできますが、今回は /usr/irissys/mgr/t1 のグローバルをすべてリストアするようにします。

%SYSネームスペースで^JOURNALルーチンを実行します。

ジャーナルリストアメニューは、4番を選択します。

%SYS>do ^JOURNAL
 1) Begin Journaling (^JRNSTART)
 2) Stop Journaling (^JRNSTOP)
 3) Switch Journal File (^JRNSWTCH)
 4) Restore Globals From Journal (^JRNRESTO)
 5) Display Journal File (^JRNDUMP)
 6) Purge Journal Files (PURGE^JOURNAL)
 7) Edit Journal Properties (^JRNOPTS)
 8) Activate or Deactivate Journal Encryption (ENCRYPT^JOURNAL())
 9) Display Journal status (Status^JOURNAL)
10) -not available-
11) -not available-
12) Journal catch-up for mirrored databases (MirrorCatchup^JRNRESTO)
13) -not available-

Option? 4
This utility uses the contents of journal files
to bring globals up to date from a backup.

ジャーナルをリストアしますか?には、Yes(またはEnter)を入力します。

Restore the Journal? Yes => Yes

この質問の回答が重要です。 ジャーナルファイルに記録された全データベースディレクトリの全グローバル変数をリストアする場合は、Yesを入力します。

今回は、指定ディレクトリんの全グローバルをリダイレクトしながらリストアしたいので、no を入力します。

Process all journaled globals in all directories? no

リストアしようとしているジャーナルファイルが別のOSで作成されたものかどうか質問されます。今回は同じマシンで作成されたものなのでNoを入力します。

Are journal files imported from a different operating system? No => No

続いて、リストアするデータベースディレクトリを指定します。

/usr/irissys/mgr/t1 /usr/irissys/mgr/t1rest にリダイレクトしながらリストアします。

Directory to restore [? for help]: /usr/irissys/mgr/t1  /usr/irissys/mgr/t1/??
No database exists in that directory.
(you will be required to redirect to another directory)
Redirect to Directory: /usr/irissys/mgr/t1/
 => /usr/irissys/mgr/t1rest--> /usr/irissys/mgr/t1rest/

指定したデータベースディレクトリに含まれるすべてのグローバルをリストアしたいですか?と聞かれています。今回は特定のグローバルではなく全てリストアするためyesを指定します。

Process all globals in /usr/irissys/mgr/t1/? No => yes

さらにリストア対象データベースがある場合は同様に指定しますが、ない場合は、Enterを押下します

Directory to restore [? for help]:

ここまで指定したディレクトリリストを表示します。変更がなければyesを入力します。

Processing globals from the following datasets:
 1. /usr/irissys/mgr/t1/   All Globals
    (Redirect to: /usr/irissys/mgr/t1rest/)

Specifications correct? Yes => yes

リストアに使用するジャーナルファイルはこのインスタンスで作成され、ジャーナルディレクトリにあるパスに配置されているかどうか質問されています。(InterSystems製品にはjournal.logファイルがあり、直近までのジャーナルファイルのフルパス情報が記録されています。このファイルを使用できるかどうかの質問です。)

例では、設定どおりにジャーナルファイルが配置されているため、yesを入力します。

Are journal files created by this InterSystems IRIS instance and located in their original paths? (Uses journal.log to locate journals)? yes

次に、どのジャーナルファイルをリストア対象とするか指定します。ファイル名が不明な場合は ? を入力するとリストを出します。リストから選択することもできます。(例では、First fileとFinal fileが同一ですが問題ありません)

最終行の質問は、ひとつのジャーナルファイルのリストアが完了して次のジャーナルファイルをリストアする前にプロンプト(入力待ち)をするかどうかです。自動的に指定したすべてのジャーナルファイルをリストアする場合は no を入力します。

Specify range of files to process

Enter ? for a list of journal files to select the first and last files from
First file to process:  ?
1) /usr/irissys/mgr/journal/20240425.003
2) /usr/irissys/mgr/journal/20240425.004
3) /usr/irissys/mgr/journal/20240426.001
4) /usr/irissys/mgr/journal/20240426.002

First file to process:  4 /usr/irissys/mgr/journal/20240426.002
Final file to process:  /usr/irissys/mgr/journal/20240426.002 =>
Prompt for name of the next file to process? No => no

ジャーナルファイルのリストに欠落がないかどうかチェックするか質問されます。 Enter(またはYes)を入力します。


The following actions will be performed if you answer YES below:

* Listing journal files in the order they will be processed
* Checking for any missing journal file on the list ("a broken chain")

The basic assumption is that the files to be processed are all
currently accessible. If that is not the case, e.g., if you plan to
load journal files from tapes on demand, you should answer NO below.
Check for missing journal files? Yes => Yes

処理対象ジャーナルファイルが表示されます。

続いて、ジャーナルファイル内の整合性チェックを行うか確認されます。(デフォルトはNo)例ではNoを選択しています。

Journal files in the order they will be processed:
1. /usr/irissys/mgr/journal/20240426.002

While the actual journal restore will detect a journal integrity problem
when running into it, you have the option to check the integrity now
before performing the journal restore. The integrity checker works by
scanning journal files, which may take a while depending on file sizes.
Check journal integrity? No => No

リストア処理前後でジャーナルファイルを切り替えるか質問されます。 切り替えたほうがわかりやすいので、例ではYesを指定しています。

The journal restore includes the current journal file.
You cannot do that unless you stop journaling or switch
     journaling to another file.
Do you want to switch journaling? Yes => Yes
Journaling switched to /usr/irissys/mgr/journal/20240426.003

ジャーナルリストア中のジャーナルを無効化したいか質問されています。デフォルトのYes(無効化)を選択します。

※ミラーリングを利用している場合は無効化を選択せず、リストア中のジャーナルを他メンバーに転送し適用することで全メンバーのリストアが自動的に完了させることもできます。

You may disable journaling of updates for faster restore for all
databases other than mirrored databases. You may not want to do this
if a database to restore is being shadowed as the shadow will not
receive the updates.
Do you want to disable journaling the updates? Yes => Yes
Updates will NOT be journaled

リストアを開始する前にデフォルトオプションを確認しています。

デフォルトは、

  • データベースに関連するエラーが発生した場合でもリストアを続行します。
  • ジャーナルに関連するエラーが発生した場合、リストアを中止します。

別の方法は、

  • データベースに関連するエラーが発生した場合中止します。
  • ジャーナルファイルに関連する問題が発生した場合でもリストアを続行します。

変更しない場合は、デフォルトのNoを指定します。

Before we job off restore daemons, you may tailor the behavior of a
restore daemon in certain events by choosing from the options below:

     DEFAULT:    Continue despite database-related problems (e.g., a target
     database cannot be mounted, error applying an update, etc.), skipping
     updates to that database. Affected database(s) may not be self-consistent
     and will need to be recovered separately

     ALTERNATE:  Abort if an update would have to be skipped due to a
     database-related problem (e.g., a target database cannot be mounted,
     error applying an update, etc.). Databases will be left in a
     self-consistent state as of the record that caused the restore to be
     aborted. Parallel dejournaling will be disabled with this setting

     DEFAULT:    Abort if an update would have to be skipped due to a
     journal-related problem (e.g., journal corruption, some cases of missing
     journal files, etc.)

     ALTERNATE:  Continue despite journal-related problems (e.g., journal
     corruption, some missing journal files, etc.), skipping affected updates

Would you like to change the default actions? No => No

リストアを開始する場合は、Yesを入力します。

Start the restore? Yes => Yes

ジャーナルリストアを開始し、リダイレクト先のデータベースディレクトリが更新されます。

メニューが表示されるので特に他の作業がなければEnterを押下し%SYSネームスペースのプロプト表示に戻ります。

Journal file being applied: /usr/irissys/mgr/journal/20240426.002
/usr/irissys/mgr/journal/20240426.002
  0.81% 100.00%
[Journal restore completed at 20240426 14:10:16]

The following databases have been updated:

1. /usr/irissys/mgr/t1rest/


 1) Begin Journaling (^JRNSTART)
 2) Stop Journaling (^JRNSTOP)
 3) Switch Journal File (^JRNSWTCH)
 4) Restore Globals From Journal (^JRNRESTO)
 5) Display Journal File (^JRNDUMP)
 6) Purge Journal Files (PURGE^JOURNAL)
 7) Edit Journal Properties (^JRNOPTS)
 8) Activate or Deactivate Journal Encryption (ENCRYPT^JOURNAL())
 9) Display Journal status (Status^JOURNAL)
10) -not available-
11) -not available-
12) Journal catch-up for mirrored databases (MirrorCatchup^JRNRESTO)
13) -not available-

Option?
%SYS>

 

11、^postbackup=1 が戻ることを確認する

管理ポータル > [システムエクスプローラ] > [グローバル] > T1ネームスペース選択

^postbackupが存在するか確認します。

 


ご参考

讨论 (0)1
登录或注册以继续