Jeffrey If you are going to have some automated failover system then you probably want to script around it to avoid these situations - adopt STONITH or a similar strategy. Otherwise failover and recovery are "sysadm ( informed ) choice" ....
The Unidata log files tell you pretty much what the current situation is - though some of the messages could be improved (maybe later...). If you know what you are looking for it is all there. There have been some incremental changes in UDT replication and it is worth keeping up-to-date..... BTW: STONITH= Shoot The Other Node In The Head Basically - if you have chosen (manually or automatically) to fail over from a Publisher to a Subscriber then it is up to your network strategy (whether manual or scripted) to avoid even the POSSIBILITY of a "dual master"...... This is all pretty standard HA configuration. Typically if a failure were invoked then 1. A failover situation is detected (manual or scripted based on *your* rules) 1. The Publisher (failed) is killed off for access purposes (just in case it is still up or being accessed) - if it is up it kills off everything. 2. The publishing group(s) fail over and the subscriber becomes the master 3. The network reconfigures TCP addresses to route connections from the (old) publisher to the (new) publisher (ex-subscriber). TCP address re-route or HOSTS...(whatever...) 3. The (old) publisher is in whatever state it is in and you take the recovery steps necessary - IF it is fixed at some point without needing a full restore or similar then: 4. At some point you can failback (similar rules to above in terms of access control) STONITH in some form is definitely necessary - but it is part of your overall strategy based around replication. Replication is the stage, your replication groups are the actors, network reconfiguration is done by scene shifters, and stage direction is provided by your SYSADM - whether manually or by script. Regards JayJay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lettau, Jeff Sent: 02 September 2004 20:01 To: [EMAIL PROTECTED] Subject: RE: [U2] Anyone have experience "mirroring" a HDD over a WAN >From what I've read about the replication, in UD, it can replicate across servers and when one goes down the remaining one will assume it is now the master and continue processing transactions. When the downed server is restored it will be updated with the missed transactions or rebuild the database depending on how bad the failure was. The problem with this idea is that over a wan you can have a connection failure and both or multiple servers will think they are the master server and begin processing the transactions. They keep log files but I don't see any way to reconcile the differences. It also looks like there should only be one master server at a time. I don't think you can have 20 offices with their own server. I would still look for some 3rd party solution to keep the data in sync and have a recovery plan that would allow a merge and audit of the logs to keep your integrity. Program triggers that keep all the databases updated virtually in real time sounds like the best real world solution to me. Jeffrey Lettau ERP Systems Manager polkaudio -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Banker Sent: Thursday, September 02, 2004 2:09 PM To: [EMAIL PROTECTED] Subject: Re: [U2] Anyone have experience "mirroring" a HDD over a WAN Have you looked into data replication? ----- Original Message ----- From: "Dennis Bartlett" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 02, 2004 8:19 AM Subject: [U2] Anyone have experience "mirroring" a HDD over a WAN Anyone have experience "mirroring" a HDD over a WAN? We have a scenario where triggers were going to be the "data collection" and a "distribution" program to blow extracted data to various end of the earth. All this was an attempt to maintain a 24/7 access to a working system. = All log on to the main server and work as at present. = When comms break at any branch, they log into their own server and continue to work (the data being an exact copy of that on the HO server up until the night before = synchronization to take place at night, when network traffic is lowest) We've now had to abandon triggers, moving to a scenario where we get to modify source code (not a preferred route). This has caused us to stop and think... if this can go wrong, how much more the distribution of data onto every server at every branch (20 branches, plus HO). An alternative solution is to set up a hardware mirror to handle the movement of data. A google produces an overwhelming array of choices... What does the collective authority of the list say? <PRE> --------------------------------------------------------- GWK BEPERK/LIMITED (REG: 1997/022252/06) POSBUS 47 PO BOX 8730 DOUGLAS Direkteure/Directors: NB Jacobs, FJ Lawrence, J v/d S Botes, JH Coetzee, JGD Smit, JF Jacobs, AO M|ller, JW Smit, JP Snyman, JG Stander, JH van Dyk(MD/BD), JG Jacobs, A M|ller, M van Zyl, Sekr/Secr: E van Niekerk. Hierdie e-pos is onderworpe aan 'n vrywaring beskikbaar by: http://www.gwk.co.za/DisclaimerVrywaring.asp This e-mail is subjected to the disclaimer that can be viewed at: http://www.gwk.co.za/DisclaimerVrywaring.asp</PRE> ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
