Re: Using mirroring to effect data replication

On 23 Sep 1997 03:15:56 -0700, Neil_Truby wrote: >My site has a critical system running on OnLine 5.07. Each night a level 0 >archive is taken and archived to a contingency server in a remote location. >Furthermore, every two hours a level 1 is taken and ftp'd to the contingency >server (this could also be achieved by forcing a log back-up and ftp'ing the >resultant back-up file to the contingency server). Version 7 gives you alot more options but until then there is somethings you can do. <snip> >Mirror the log dbspace of the primary server on a disk at physically adjacent >and connected to the contingency server. In the event of disastrous loss of the >primary site, the database server can be recovered at the contingency site >(using an ftd'd archive). Before this restore is effected the mirrored logs >would have to be backed up. Once the restore is complete, apply the backed-up, >mirrored, logs to give "point-of-failure" recovery. Do not do this. If the secondary machine is down for some reason it will bring your primary down also. You are adding more risk by now making it that you cannot do anything with the secondary without crashing and burning your primary. I cannot say it enough times. This is bad mojo baby! And I am not sure you could access it or that it would work on the secondary anyway. > >Aside from the probable performance degradation of remotely mirroring the log >dbspace, can anyone think of a show-stopping reason against this? > What I suggest is basically the following: Continue with the archives being FTP'd over. Set up a NFS filesystem between the two machines with the physical filesystem on the secondary. Then run a continuous log back up on the primary to a file on the remote filesystem. Also when you do an archive write a logfile to this filesystem so that you can know what logical logs to start from. Each time you do the archive stop the continuous backup and force to the next logical log. You risk losing the transactions in the current logical log. So depending on how big they are and how log it takes to fill one then that is your level of risk. But it should be a much better recovery than the various level backups you are doing now. I have some scripts for doing this on an NCR machine that I could send you if you were interested. This works and was our procedure for about a year. We now have kept that procedure but added the HDR replication. HTH, Regards, Jason Jason Harris Informix DBA Westpac Banking Corporation NOTE: I add all these address at the bottom of people who spam me Now when their extractors extract my e-mail address they will also end up spamming each other. wtcjr@ix.netcom.com Shevsky@hotmail.com speech@speechrecognition.com SmartBiz@NevWest.com slender@juice4u.net sbliss@earthfriends.com ron@moneyaction.com removeme@gwh.net rocco@lostvegas.com market@DRAWBRIDGE.NET Foxyrusski@mail-response.com emaster@email-man.com waynesmail@earthlink.net