[THIN] ps3 replicated datastore - BCP strategy

  • From: "Lilley, Brian" <brian.lilley@xxxxxxxx>
  • To: "'thin@xxxxxxxxxxxxx'" <thin@xxxxxxxxxxxxx>
  • Date: Tue, 1 Feb 2005 13:09:30 -0000

Hi list...

I think I have a cunning plan...but not sure.. perhaps it is over engineering
just because I can...

I have designed a single global PS3 farm based on a replicated SQL
infrastructure with a master and two regional subscriber nodes.

The design includes a level of failover for the regional nodes in order that
they continue to accept read/writes in the event of loss of communication with
the master node.  If a subsriber node (using immediate update synchronous
replication) should loose sight of the master subscriber, then it will
fail-over to queued updates (asynchronous replication)... now, this is where
the plan falls apart.

Because citrix generates and stores the primary keys for its database record
entries in the database itself, it is unable to support any kind of merge
replication, in other words asynchronous replication.... so, if a node becomes
isolated it will fail over to queued updates and when the master is brought
back online, we simply drop the node and re-snapshot from the master.

So, what are likely to be the problems with this... I assume that we would
need to recreate the lhc on each server which is attached to a regional node
that is 're-snapshotted'?

I guess that, depending on the amount of time a subscriber node is out of
communications with its master, i.e. the amount of time it is a read-only
datastore affects whether it is worthwhile turning it into a read/write
datastore and therefore suffer the headache of a)re-snapshotting from master
database and b)for each of the servers pointing to that datastore, having to
re-create their LHC.

any advice and guidance much appreciated...


Brian R Lilley
Architecture and Engineering

This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.

This Weeks Sponsor: ThinPrint, GmbH
Now available: .print Remote Desktop Printing Engine 
for Microsoft Terminal Services
Useful Thin Client Computing Links are available at:
ThinWiki community - Excellent SBC Search Capabilities!
For Archives, to Unsubscribe, Subscribe or 
set Digest or Vacation mode use the below link:

Other related posts:

  • » [THIN] ps3 replicated datastore - BCP strategy