From owner-freebsd-isp@FreeBSD.ORG Tue May 27 15:35:53 2003 Return-Path: Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92C9437B401 for ; Tue, 27 May 2003 15:35:53 -0700 (PDT) Received: from ns.dixons.org (ns.dixons.org [217.199.172.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4496D43F75 for ; Tue, 27 May 2003 15:35:52 -0700 (PDT) (envelope-from jdd@dixons.org) Received: from localhost (jdd@localhost) by ns.dixons.org (8.11.6/8.11.6) with ESMTP id h4RLX1O18858 for ; Tue, 27 May 2003 22:33:01 +0100 Date: Tue, 27 May 2003 22:33:01 +0100 (BST) From: Jim Dixon To: In-Reply-To: <2217.148.243.211.187.1054021261.squirrel@mail.unixmexico.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: replicating data over 2 servers X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Internet Services Providers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2003 22:35:53 -0000 On Tue, 27 May 2003 nbari@unixmexico.com wrote: > hi all, i have to servers (A, B) with round robin DNS, users enter to > server A and server B and they write to a txt file, how can i sync the > file from both server so it can be always the same? for example if a user > enter to server A and modify some data, replicate that modification to > server B so when user enter to server B he can see his changes, and the > same if user modify a file on server B, replicate that file to server A, > any idea? We need more information. How often does the data get changed? How much delay is tolerable? Are the two servers on the same LAN or in different places on the Internet? Most important, how do you define "the same"? Is it tolerable if the servers are out of sync for a few milliseconds? for a few seconds? minutes? You probably need a protocol for writing like this: 1 lock local copy of data 2 lock remote copy of data 3 write new values 4 unlock remote copy 5 unlock local copy This guarantees that data on the two servers will be consistent. For better performance (less delay perceived by the user): 1 read-lock local copy (ie, no writing permitted, but reading OK) 2 write-lock remote copy (no reading, no writing) 3 write-lock local copy 4 update values 5 drop local lock to read-lock 6 unlock remote copy 7 unlock local copy You can elaborate the protocol to allow for server failures. Dealing with network failures is more interesting. You could do this with a Perl script and ssh without much trouble, assuming that the data was coarse-grained, ideally a single item ;-) If the data has a complex structure and there is lots of it, then you probably need a distributed database. -- Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881