|
NISMAILを別サーバに移行する際、新環境作成後に実定義を使用してテスト
転送を行うと、サーバ移行後に各集配信定義の最初の転送にて重複転送防止
機能が動作する事がございます。
ディスク障害等で古いバックアップからNISMAILを復旧した場合についても
同様に各集配信定義の最初の転送にて重複転送防止機能が動作する事がございます。
予期せぬ重複転送防止機能の動作に伴い、データは相手サーバに転送されずに
送信側では正常終了となります。
重複転送防止機能が動作した次の転送からは、正常に転送が行われます。
サーバ間転送で転送を行う際にネットワークの状態により、送信側では転送失敗、受信側では正常終了と
転送の終了状態に差異が発生する事がございます。
送信側は転送失敗となっておりますので転送のリトライを行いますが、受信側では正常終了してますので
このままでは2重転送となってしまいます。
ファイルを2重に受信しない為に、NISMAILでは転送に番号を付けて管理する重複転送防止機能を実装しております。
重複転送防止機能の動作については、『018. SV共通 サーバ間転送機能(SCC)で「ファイル重複のため受信拒否」と出力し転送できない』
に記述しておりますので参照ください。
NISMAILのサーバ間転送では、送信側で転送に番号を付けて送信を行います。
受信側では転送終了時に転送に付けられた送信側の番号を保存します。
移行先のNISMAILに新規に定義登録を行う場合は、受信側には送信済みの番号が
存在しない状態で作成されます。
登録した定義でテスト転送を行うと、受信側には送信済みの番号が保存されます。
また、既存環境より環境ディレクトリをコピーした場合は、受信側には転送による
番号が保存された状態で作成されます。
上記の様に受信側で送信側の番号が保存されている状態で移行後に転送を開始すると、
各集配信定義の移行後の最初の転送では、重複転送防止機能が動作する可能性がございます。
同様にバックアップから復旧した場合も環境が巻き戻り、幾らかの転送を
行う前の状況に戻る事になります。
巻き戻った環境で新規に送信を行った時に、受信側では転送済みの番号と
判断され重複転送防止機能が動作する事がございます。
以下のいずれかの手段で回避可能です。
○環境ディレクトリをそのまま移行する場合
・ワンポイントで切り替えを行う。
移行時に移行元を停止させた直後の環境ディレクトリを移行先に移す事
により、番号のずれを無くします。
移行前のテスト転送はテスト用の定義を準備して行ってください。
移行は、移行先の環境ディレクトリを削除してから移してください。
・移行後に全ての集配信定義にテストデータで転送を行う。
1度転送する事により、番号の整合性をとることができます。
重複転送となる、ならないに関わらず整合性がとられます。
次回より正常に転送が行われます。
テストデータについては利用者にて準備してください。
※ワンポイントの切り替えか、テストデータでの転送のどちらか片方のみ実施してください。
○定義情報のみ移行する場合
・定義登録直後の環境ディレクトリのバックアップを使用する。
定義を登録した時には受信側に送信済みの番号が保存されていません。
定義登録直後のバックアップを採取しておき、テスト転送後に
バックアップから転送前の状態を復元します。
バックアップ対象は環境ディレクトリが対象となります。
バックアップから復元する時には上書きせず、既存の環境ディレクトリを
削除してから復元してください。
環境ディレクトリの上書きを行った場合は、正常に動作しなくなります。
・移行後に全ての集配信定義にテストデータで転送を行う。
1度転送する事により、番号の整合性をとることができます。
重複転送となる、ならないに関わらず整合性がとられます。
次回より正常に転送が行われます。
テストデータについては利用者にて準備してください。
※バックアップか、テストデータでの転送のどちらか片方のみ実施してください。
本件につきましては、制限事項とさせて頂きます。
|
