Resynchronization and resilience

Resilient ISAM files are intended to automatically detect and correct minor errors due to index and data files being out of sync. To designate a new ISAM file as resilient when you create it, you can use the RESILIENT or FULLRESILIENT XDL keywords or specify the RESILIENT or FULLRESILIENT options in a call to ISAMC.

RESILIENT and FULLRESILIENT are supported only on 64-bit Windows and Unix. FULLRESILIENT is the same as RESILIENT, except that for all writes (STORE, WRITE, or DELETE), the data partition (.is1) data is written directly to disk using the file open flags FILE_FLAG_WRITE_THROUGH on Windows and O_DSYNC on Unix. FULLRESILIENT will slow down disk access but with improved recoverability. You should benchmark your hardware characteristics and application performance requirements before using FULLRESILIENT instead of RESILIENT.

A RESILIENT or FULLRESILIENT file that is out of sync must be resynchronized before it can be opened. This happens automatically for remote files when they are opened or updated via 64-bit xfServer. You can also manually check and resynchronize files with isutl -s.

You can enable automatic resynchronization of resilient files that are accessed locally (that is, not accessed with xfServer) by installing 64-bit xfServer on the local system. To enable this feature, xfServer (rsynd) must be running on the default port (2330) and in a mode that permits users of the machine to access it, and an xfServer license must be available. To avoid having to set up RUSER authentication, we recommend running xfServer in restricted mode (a.k.a. Windows authentication) or run-as-user mode on Windows and in effective user mode on Unix. If you choose run-as-user or effective user mode, only the account created to run xfServer will need to have access. (See Understanding xfServer security on Windows and Understanding security modes on Unix for details.) Once you have this set up, rsynd will automatically attempt to resynchronize a local out-of-sync RESILIENT or FULLRESILIENT file when it’s opened or updated, before issuing an $ERR_FILSYNC error. If you don’t have enough xfServer licenses (and would get a MAXUSER error if you tried OPENing a file to that server via normal xfServer access), an $ERR_FILSYNC error will occur if RESILIENT or FULLRESILIENT attempts to open a file to the server.

Whenever a RESILIENT file is automatically resynchronized, a log entry with the prefix "(rsynd) Re-synced" is added to the isutl.log file. Sample output looks like this: FILE: c:\test\resilient.ism (rsynd) Re-synced Wed Sep 13 11:56:28 2023, Options:"-s", PASSED Elapsed time: 00:00:00.015 Such entries provide a log that indicates how frequently a file is getting out of sync. A large number of entries suggests you may need to pay special attention to the way that file is being handled. For example, backups occurring while the file is in use may cause this issue. Excessive resynchronization operations will degrade system performance.

Another way to handle resynchronization of RESILIENT or FULLRESILIENT files is by configuring xfServer to resynchronize files on start-up. For more information, see Automating file maintenance with xfServer (Windows and Unix). Depending on the number and size of files, you may want to set up multiple xfServer processes to parallelize automatic file maintenance, using no more than two xfServer processes per physical disk LUN and using separate temporary drive locations.

Supporting RESILIENT files

For RESILIENT files local to the runtime

1.

A local rsynd must be running on the default port (2330) or on a port designated by SCSPORT.

2.

The rsynd specified on the OPEN must allow the following write permission to files that are RESILIENT:

3.

The local rsynd must have at least one xfServer license available

For RESILIENT files open on a remote server

1.

The rsynd specified on the OPEN must allow the following write permission to files that are RESILIENT:

2.

The remote rsynd must have at least one xfServer license available.