| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Re: clustering |
From: Mike '/m' Look into OpenVMS clustering. The nodes of the cluster can be geographically distant. /m On Sun, 05 Jun 2005 15:49:45 -0700, Ellen K. wrote: >Well, after a little more reading, I don't think clustering is going to >be my answer. If I correctly understood what I read, clustering means >the clustered machines all use ONE set of data. So it protects against >machine failure and network failure but if the location where the data >reside goes down for whatever reason what good are the additional boxes? >(Our L.A. location is obviously vulnerable to earthquakes, and not so >obviously vulnerable to terrorist attack of several nearby institutions, >and TJ, well, it's in Mexico, nuff said.) I think we want redundancy of >the DATA in addition to being protected against machine failure and >network failure. > >Log shipping (similar to replication but specifically designed for when >you want a standby server, for example there are stored procedures for >making the standby the primary etc) seems more like what I want except >that for my recordings database it isn't going to be a solution because >BLOB data are actually stored on their own pages, all that's in the BLOB >field is the pointer to the location of the data, and the BLOB data per >se are not written to the log. I haven't seen anything about whether >BLOB data are propagated if we go back to my original idea of >transactional replication, that's my next piece of research. > >My boss agreed that using replication with the idea of changing the IP >number of the Subscriber wouldn't work because they will be on different >subnets, but suggested that instead of changing the IP number of the >Subscriber, change the *applications* to point to the Subscriber instead >of the Publisher. On further thought it seems to me that since we're >going with this Enterprise Service Bus thing we could have something >that sends a message with the new location to point to, and/or have the >connection string somewhere in the middle tier so we could change it in >the event of a disaster, and this would be transparent to the users. > >Comments? --- BBBS/NT v4.01 Flag-5* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45) SEEN-BY: 633/267 270 5030/786 @PATH: 379/45 1 106/2000 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.