This is a discussion on Data Replication within the Sco Unix forums, part of the Unix Operating Systems category; --> Hi All, I've got a customer running his business system on top of SCO UnixWare, the business system uses ...
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| Hi All, I've got a customer running his business system on top of SCO UnixWare, the business system uses a proprietary database developed by the makers of the system. My customer would like, as part of their DR strategy, to have a second server running a "copy" of the system which would be update online and in real time. Unfortunately the business system vendor hasn't got the technology to achieve this at the database level... so my question(s) to the group is: Can this be done at the OS level? Does UnixWare have the capability to replicate data on real time to another UnixWare server? If so how can it be done? Any help would be greatly appreciated. Regards, Ed. |
| |||
| efr611@yahoo.com.au wrote: > Hi All, > > I've got a customer running his business system on top of SCO > UnixWare, the business system uses a proprietary database developed by > the makers of the system. > > My customer would like, as part of their DR strategy, to have a second > server running a "copy" of the system which would be update online and > in real time. > > Unfortunately the business system vendor hasn't got the technology to > achieve this at the database level... so my question(s) to the group > is: > > Can this be done at the OS level? Does UnixWare have the capability to > replicate data on real time to another UnixWare server? If so how can > it be done? > > Any help would be greatly appreciated. > > Regards, > > Ed. > > i sync the programmers boxen with rsync to our main data server every night...it works over lan as well as it does over the internet, and only copies the data that is updated (unless you tell it otherwise!) seems to be sort of standard for situations like you are in. would never be realtime though...sort of like another backup, but it would be to a usable server rather than removable media... have you thought of manually porting the app to a microsoft sql clustering solution ? :P |
| |||
| efr611@yahoo.com.au wrote: > Hi All, > > I've got a customer running his business system on top of SCO > UnixWare, the business system uses a proprietary database developed by > the makers of the system. > > My customer would like, as part of their DR strategy, to have a second > server running a "copy" of the system which would be update online and > in real time. > > Unfortunately the business system vendor hasn't got the technology to > achieve this at the database level... so my question(s) to the group > is: > > Can this be done at the OS level? Does UnixWare have the capability to > replicate data on real time to another UnixWare server? If so how can > it be done? > > Any help would be greatly appreciated. > > Regards, > Well, some sort of data replication can be achieved with SCO's ReliantHa, even if this piece of sw is particularly aimed at High Availability solutions rather than data replication ones. The trick here is to have the data on an external storage which is "seen" from both nodes (assuming you're running a high-avaliability solution made up of 2 servers); when the first goes down, the second one takes the conn and drive the data. You can also use "rsync" but dunno how well it performs when dealing with dbase data. -- Roberto Zini - r.zini<@AT@>strhold.it --------------------------------------------------------------------- "Has anybody around here seen an aircraft carrier?" (Pete "Maverick" Mitchell - Top Gun) |
| |||
| <efr611@yahoo.com.au> wrote in message news:rkpg61ljmi7vmt86blu93anblr6j7oubpj@4ax.com... > Hi All, > > I've got a customer running his business system on top of SCO > UnixWare, the business system uses a proprietary database developed by > the makers of the system. > > My customer would like, as part of their DR strategy, to have a second > server running a "copy" of the system which would be update online and > in real time. > > Unfortunately the business system vendor hasn't got the technology to > achieve this at the database level... so my question(s) to the group > is: > > Can this be done at the OS level? Does UnixWare have the capability to > replicate data on real time to another UnixWare server? If so how can > it be done? > > Any help would be greatly appreciated. > > Regards, > > Ed. > > There are several 3rd party products to do this. Some such products are: http://www.savwareha.com/ http://www.twincom.com/dualdisc.html http://www.neohigh.com/welcome/welcome.htm |
| ||||
| <efr611@yahoo.com.au> wrote in message news:rkpg61ljmi7vmt86blu93anblr6j7oubpj@4ax.com... > Hi All, > > I've got a customer running his business system on top of SCO > UnixWare, the business system uses a proprietary database developed by > the makers of the system. > > My customer would like, as part of their DR strategy, to have a second > server running a "copy" of the system which would be update online and > in real time. > > Unfortunately the business system vendor hasn't got the technology to > achieve this at the database level... so my question(s) to the group > is: > > Can this be done at the OS level? Does UnixWare have the capability to > replicate data on real time to another UnixWare server? If so how can > it be done? > > Any help would be greatly appreciated. > > Regards, > > Ed. > > Software RAID might also be an option. There used to be (I haven't looked into this in several years) a group named 1776 Inc. that had a software raid that worked on clustered servers. Maybe something like this would be a workable solution. As you know, on any type of RDBMS, obtaining true real-time mirroring is iffy unless the applications DBMS itself handles dual updating. Temporary files like 'before image' and 'after image' storage containers and general locking files are usually the root of most problems. But, that being said, there is probably a functional solution to resolve those issues, or at the very least, be able to deal with them. Good luck on your quest. JP |