Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: Asychronous Replication
Date: Tue, 10 Apr 2007 16:00:22 -0400
Message-ID: <145D98CA0348A6458EC5604B5284470801740EC6@NUMEVP03.na.imtn.com>
Thread-Topic: Asychronous Replication
Thread-Index: Acd7qt+L58QrtHPuSqW+ij8n/g/hHQ==
From: "Chabot, Jerry" <Jerry.Chabot@ironmountain.com>
To: <derby-user@db.apache.org>
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C77BAA.DF8B53F3"

This is a multi-part message in MIME format.


------_=_NextPart_001_01C77BAA.DF8B53F3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=0D=0AI'm considering options for asynchronous replication=2E A low cost op=
tion is to freeze the source and target databases,=0D=0Asynchronize the fil=
es using rsync (one way) and unfreeze the databases=2E Freezing is acceptab=
le given the expected=0D=0Ausage=2E=0D=0A=0D=0AMy concern is existing clien=
ts of the target database may see stale data=2E Is there a need to flag the=
 target clients that =0D=0Athe files have changed?=0D=0A=0D=0ADoes anyone s=
ee any technical issues with this approach?=0D=0A=0D=0A-Jerry=0D=0A=0D=0A=
=0D=0A=0D=0A-----------------------------------------=0D=0AThe information =
contained in this email message and its attachments=0D=0Ais intended only f=
or the private and confidential use of the=0D=0Arecipient(s) named above, u=
nless the sender expressly agrees=0D=0Aotherwise=2E=0D=0ATransmission of em=
ail over the Internet is not a secure=0D=0Acommunications medium=2E If you =
are requesting or have requested the=0D=0Atransmittal of personal data, as =
defined in applicable privacy laws=0D=0Aby means of email or in an attachme=
nt to email, you must select a=0D=0Amore secure alternate means of transmit=
tal that supports your=0D=0Aobligations to protect such personal data=2E=0D=
=0AIf the reader of this message is not the intended recipient and/or=0D=0A=
you have received this email in error, you must take no action=0D=0Abased o=
n the information in this email and you are hereby notified=0D=0Athat any d=
issemination, misuse or copying or disclosure of this=0D=0Acommunication is=
 strictly prohibited=2E If you have received this=0D=0Acommunication in err=
or, please notify us immediately by email and=0D=0Adelete the original mess=
age=2E=0D=0A
------_=_NextPart_001_01C77BAA.DF8B53F3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3=2E2//EN">=0D=0A<HTML>=0D=0A<HEAD>=
=0D=0A<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso=
-8859-1">=0D=0A<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server versi=
on 6=2E5=2E7651=2E59">=0D=0A<TITLE>Asychronous Replication</TITLE>=0D=0A</H=
EAD>=0D=0A<BODY>=0D=0A<!-- Converted from text/plain format -->=0D=0A<BR>=
=0D=0A=0D=0A<P><FONT SIZE=3D2>I'm considering options for asynchronous repl=
ication=2E A low cost option is to freeze the source and target databases,<=
BR>=0D=0Asynchronize the files using rsync (one way) and unfreeze the datab=
ases=2E Freezing is acceptable given the expected<BR>=0D=0Ausage=2E<BR>=0D=
=0A<BR>=0D=0AMy concern is existing clients of the target database may see =
stale data=2E Is there a need to flag the target clients that<BR>=0D=0Athe =
files have changed?<BR>=0D=0A<BR>=0D=0ADoes anyone see any technical issues=
 with this approach?<BR>=0D=0A<BR>=0D=0A-Jerry</FONT>=0D=0A</P>=0D=0A=0D=0A=
</BODY>=0D=0A</HTML>=0D=0A=0D=0A<HTML><BODY><P><hr size=3D1></P><br>=0D=0A<=
P><STRONG><br>=0D=0AThe information contained in this email message and its=
 attachments<br>=0D=0Ais intended only for the private and confidential use=
 of the<br>=0D=0Arecipient(s) named above, unless the sender expressly agre=
es<br>=0D=0Aotherwise=2E<br>=0D=0ATransmission of email over the Internet i=
s not a secure<br>=0D=0Acommunications medium=2E If you are requesting or h=
ave requested the<br>=0D=0Atransmittal of personal data, as defined in appl=
icable privacy laws<br>=0D=0Aby means of email or in an attachment to email=
, you must select a<br>=0D=0Amore secure alternate means of transmittal tha=
t supports your<br>=0D=0Aobligations to protect such personal data=2E<br>=
=0D=0AIf the reader of this message is not the intended recipient and/or<br=
>=0D=0Ayou have received this email in error, you must take no action<br>=
=0D=0Abased on the information in this email and you are hereby notified<br=
>=0D=0Athat any dissemination, misuse or copying or disclosure of this<br>=
=0D=0Acommunication is strictly prohibited=2E If you have received this<br>=
=0D=0Acommunication in error, please notify us immediately by email and<br>=
=0D=0Adelete the original message=2E<br>=0D=0A</STRONG></P></BODY></HTML>=
=0D=0A
------_=_NextPart_001_01C77BAA.DF8B53F3--