Re: [Hardhats-members] GTM database replication at remote site

[Chris Richardson]

Title: RE: [Hardhats-members] GTM database replication at remote site

Bhaskar;      You are correct, BCMA Backup is a good start.  It is a full implementation of VistA.  It is kept up to date with a stream of HL7 messaging from the server.  Each of the BCMA backup machines only have to precess these messages until the primary server connection fails.  Then these machines come up as isolated servers and should be able to support the ward or a couple of wards stacking up the transactions as HL7 traffic sitting in queue until the communications with the primary server can be restored.  The HL7 interface is bi-directional.  In this system, there may be occassion for drift of these shaddow servers (the BCMA Backup configuration), but this should be able to be restored by a fresh extraction and file transfer to a local depot for further distribution to other BCMA BU machines around the hospital.  The journal has been kept while the new configuration was built and pushed out to the distributed machines (while they are still in service.  The swap-over can be relatively fast if there is at least 3 times as much disk space as needed to hold the configuration (the current configuration, the packed tar file, space to unpack the files while the current structure is still in process).  Once the files are positioned and unpacked, the GTM environment is brought down, the files are re-names, and the GTM configuration is brought back up (in less than 5 minutes of actual down time).  The Journals can then be sent and replayed to the new configuration.      The situation is that the there are way more reads than writes in the database.  The reads do not have to be copied to the shadow servers.  Only writes and deletes are sent via HL7. ----- Original Message ----- From: Bhaskar, Kasi To: hardhats-members@lists.sourceforge.net Sent: Tuesday, February 15, 2005 5:05 AM Subject: RE: [Hardhats-members] GTM database replication at remote site With GT.M logical dual site operation, there is always a single primary on which updates occur.  A couple of other ways to accomplish what you want come to mind: The BCMA backup system developed for the VA so that there is a local backup system for inpatients for those occasions when the main server is down has some ability to share records between VistA systems.  I don't know whether this is strictly one way, or if it can be used to share records between servers. At the cost of some extra overnight processing (which can probably be automated, except that someone needs to review that it executes correctly each night, and the run book must have procedures to specifying what to do when it doesn't).  Imagine a system where all three servers are logically in sync at the beginning of the day.  Each works on its own, in isolation.  At the end of the day, the satellite servers roll back the entire day's work (accomplished with one command), and ship the extract (the so called lost transaction report in logical dual site parlance) back to the main server where application logic reads the extract and applies it to the main database.  An extract of the entire previous day's work is then shipped to the satellite servers so that all databases are logically in sync for the next business day. I don't know what CPRS GUI bandwidth requirements are relative to the bandwidth used by GT.M's GT.CM client/server operation.  If this is the case, you can run the VistA logic on local servers (or even individual PCs - client logic can certainly run on a CoLinux virtual machine, for example) connecting over a secured LAN/VPN to the main server. Note that from an administrative point of view, you may find it easier to manage point-to-point links (even if the underlying technology is DSL) from the satellite offices to the main office, with a link to the Internet from the main office. By the way, are you sure that VPN over commercial DSL will not suffice to run CPRS GUIs at the satellite locations? -- Bhaskar -----Original Message----- From:   [EMAIL PROTECTED] on behalf of Kevin Toppenberg Sent:   Mon 2/14/2005 10:20 PM To:     Hardhats Sourceforge Cc:     Subject:        [Hardhats-members] GTM database replication at remote site I have finally printed out the GTM system administrator's manual, and am picking through it.  I have some questions about database replication at a remote site.  I'm guessing this is a Bhaskar question--but anyone can answer. From my initial review, it seems that database replication takes place by sending a journal/log of events to a remote database.  The remote database applies these events to synchronize the databases. Here is my situation and question. We have two sites (and will eventually have 3) that will be using VistA.  Our database will be largely reading notes that have been input by transcriptionists.  The problem is that the network bandwidth/speed between sites it less than we would like.  We currently have a commercial grade DSL line. My understanding is that our only other option would be to purchase a T1 for $$/month, which we don't really want to do. [KSB] <...snip...>