Eclipse Database Replication

UniVerse Database Replication

 

Eclipse HA

Data replication frequency: typically “real time”
Time to recovery: typically a few minutes

Eclipse customers that want “real time” replication can use UniVerse’s native replication functionality. The software is configured to capture writes to the database and replicate them to a secondary server while preserving the integrity of the database. Recovery is also quick, since the Eclipse software is already up and running on the secondary server. This solution is implemented and supported directly by the database vendor, Rocket Software, so please contact your account manager for more details.

How do I perform a manual rsync backup on Linux?

If your system is configured to perform an rsync backup as part of the standard snapshot script, simply run the following command:

at now -f /u2/UTILS/bin/snapsave_linux.sh

To schedule the backup at specific date and time, for example at 11PM today, change now to 23:00.

at 23:00 -f /u2/UTILS/bin/snapsave_linux.sh

This script will suspend your database, take snapshots of the database files and create a full tape backup. You will not see any output in your console session, because the script creates a separate log file under /tmp/snapsave.log.

If you have already created the snapshot filesystem, but you want to perform a separate manual tape backup:

 rsync  -avz --delete --stats /snap/u2/   /mnt/nas/rsync/

If there are no snapshots present, but no users are on the system and you want to perform a manual rsync backup:

 rsync  -avz --delete --stats /u2/   /mnt/nas/rsync/

References:
How to use the at command
How to use rsync

How do I view my Eclipse rsync backup logs on Linux?

The standard rsync backup script keeps a number of log files that are accessible to the system administrator. To view the log files, log into your server as root and run the following commands. You may also configure the backup script to send an email every time the backup is run.

/tmp/snapsave.log contains the output from the last successful rsync backup

more /tmp/snapsave.log

The log for a successful rsync backup will show output similar to the following:

Copy done - status=0

Number of files: 2248894
Number of files transferred: 6519
Total file size: 181.30G bytes
Total transferred file size: 135.72G bytes
Literal data: 135.72G bytes
Matched data: 0 bytes
File list size: 82.91M
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 135.82G
Total bytes received: 152.13K

sent 135.82G bytes  received 152.13K bytes  14.44M bytes/sec
total size is 181.30G  speedup is 1.33

A successful backup status returns a 0, while an unsuccessful one returns a non-zero value that usually can be interpreted as an error code.

  • /tmp/snapsave.rsync-local.log  –  contains the files that were backed up or updated by rsync backup operation
  • /tmp/snapsave.log –  logs database suspension and snapshot operations:
less /tmp/snapsave.log

The following log file shows a successful backup and details the database and snapshot operations taking place. This is very useful for troubleshooting backup issues.

--------------------------------------------------------------------------------
Tue Sep  7 21:00:05 CDT 2010: Current snapshot status
Snapshots for /u2
Current  Location          512-blocks        Free Time
*        /dev/fslv00           163840       50432 Mon Sep  6 21:01:32 CDT 2010
Snapshots for /u2/eclipse
Current  Location          512-blocks        Free Time
*        /dev/fslv01          2818048     1512448 Mon Sep  6 21:01:39 CDT 2010
Snapshots for /u2/eclipse/ereports
Current  Location          512-blocks        Free Time
*        /dev/fslv02            32768       32000 Mon Sep  6 21:01:44 CDT 2010
Snapshots for /u2/pdw
Current  Location          512-blocks        Free Time
*        /dev/fslv03          1835008     1833984 Mon Sep  6 21:01:48 CDT 2010
--------------------------------------------------------------------------------
Tue Sep  7 21:00:16 CDT 2010: Releasing and unmounting previous snapshots
Tue Sep  7 21:00:18 CDT 2010: Unmounting /snap/u2/pdw
Tue Sep  7 21:00:23 CDT 2010: Removing snapshot(s) of /u2/pdw
rmlv: Logical volume fslv03 is removed.
Tue Sep  7 21:00:31 CDT 2010: Unmounting /snap/u2/eclipse/ereports
Tue Sep  7 21:00:32 CDT 2010: Removing snapshot(s) of /u2/eclipse/ereports
rmlv: Logical volume fslv02 is removed.
Tue Sep  7 21:00:39 CDT 2010: Unmounting /snap/u2/eclipse
Tue Sep  7 21:00:40 CDT 2010: Removing snapshot(s) of /u2/eclipse
rmlv: Logical volume fslv01 is removed.
Tue Sep  7 21:00:47 CDT 2010: Unmounting /snap/u2
Tue Sep  7 21:00:47 CDT 2010: Removing snapshot(s) of /u2
rmlv: Logical volume fslv00 is removed.
--------------------------------------------------------------------------------
Tue Sep  7 21:00:53 CDT 2010: Suspending database
--------------------------------------------------------------------------------
Tue Sep  7 21:00:59 CDT 2010: Performing snapshots:
Tue Sep  7 21:00:59 CDT 2010: Taking snapshot of /u2
Snapshot for file system /u2 created on /dev/fslv00
Tue Sep  7 21:01:04 CDT 2010: Taking snapshot of /u2/eclipse
Snapshot for file system /u2/eclipse created on /dev/fslv01
Tue Sep  7 21:01:11 CDT 2010: Taking snapshot of /u2/eclipse/ereports
Snapshot for file system /u2/eclipse/ereports created on /dev/fslv02
Tue Sep  7 21:01:16 CDT 2010: Taking snapshot of /u2/pdw
Snapshot for file system /u2/pdw created on /dev/fslv03
--------------------------------------------------------------------------------
Tue Sep  7 21:01:21 CDT 2010: Database suspend released.
--------------------------------------------------------------------------------
Tue Sep  7 21:01:21 CDT 2010: Mounting snapshot filesystems
Tue Sep  7 21:01:23 CDT 2010: Mounting snapshot: /snap/u2
Tue Sep  7 21:01:25 CDT 2010: Mounting snapshot: /snap/u2/eclipse
Tue Sep  7 21:01:27 CDT 2010: Mounting snapshot: /snap/u2/eclipse/ereports
Tue Sep  7 21:01:30 CDT 2010: Mounting snapshot: /snap/u2/pdw
rmt0 changed
Tue Sep  7 21:02:05 CDT 2010: Starting backup from /snap
--------------------------------------------------------------------------------
Tue Sep  7 22:40:15 CDT 2010: Mailing backup report
--------------------------------------------------------------------------------

How do I contact EVault for support?

If you are experiencing issues with the scheduled backup job or the agent on your Eclipse AIX/Linux server, you may contact Eclipse for support. If you are experiencing issues with your EVault Express Recovery appliance (on-site backup server), with the off-site vault, or have any account-related questions, you may contact EVault directly for support. Please have your EVault account information available:

How do filesystem snapshots work in AIX?

To perform valid backups of your database, it is important to suspend the database. This prevents modifications of files during the backup process. By taking a point-in-time snapshot of your database files, your backup program will be capturing a “frozen” database instead of an “in motion” database.

Eclipse has an updated backup script that uses database suspension with snapshots to create point-in-time images of your database files. If you would like this script installed on your AIX server, please submit a service request for the support team to review your system’s configuration, validate that it meets the appropriate requirements, and implement the changes.

The snapshot script is typically scheduled to run at regular intervals via crontab to create new filesystem snapshots.

After running the script, the snapshot filesystems are mounted under /snap, allowing read-only access by backup software. For example, the snapshot of the /u2/eclipse/LEDGER file would be located at /snap/u2/eclipse/LEDGER. When configuring backup software, it is recommended to backup every file under /snap/u2.

Since every change (delta) between the snapshot and the “live” filesystem must be recorded, the snapshots have a finite lifespan. By default, the snapshot script is configured to hold 1GB of changes before requiring a refresh. On busier systems, or on systems where the snapshots must be retained for a longer period of time to accommodate a slow backup process, the snapshot volume size may be increased by editing the snapshot backup script.

When the snapshot volume has reached its maximum capacity for tracking changes, it must be recreated by running the snapshot script again.

For troubleshooting purposes, a log of the snapshot backup script is kept at /tmp/snapsave.log.

For more information, refer to the following resources: