[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Handle-info] handle replication / mirroring update questions

I responded to this off-list, but thought I should also post an overview of replication here in case others are interested.

Handle servers use a replication system to keep secondary/mirror handle servers up to date with any handles that were created, modified, or deleted on the primary handle server(s) in the same service. Replication only works if handles are only changed through an interaction with the primary handle server using the handle admin protocol. So if you run a multi-server handle service and your handle server is configured to use an SQL database as the back end, you need to either take care of the replication at the database level (via something like Oracle's mirroring) or ensure that all changes are performed through the handle server.

When the primary handle server receives a request to add, modify or delete a handle it will record an entry in a transaction log just before modifying the database. This transaction log can be viewed in the "txns" subdirectory of a primary handle server. There is a transaction log file for each calendar day, with one transaction per line. Each transaction consists of an encoded handle, the encoded type of change (add, delete, modify, home-prefix, unhome-prefix), a time-stamp and transaction ID. There is also an "index" file that contains the first time-stamp and transaction ID for each daily log.

Secondary servers are configured to replicate a from a specific primary site. When a brand new secondary server is started, it requests all handles from the primary servers. We call this a "dump" because for some primaries the list can be very large and listing them can take a while. Once the full list is received, the secondary performs incremental replication. With incremental replication the secondary servers will poll the primary server(s) for any transactions that have occurred since the last time they connected based on the transaction ID and timestamp of the last received transaction. If the last time-stamp is outside of the window of the transaction log of the primary server, the secondary server is notified that it needs to do a re-dump (retrieve all of the handles again). If the time-stamp isn't too old the primary server returns all transactions that have a transaction ID greater than the one provided by the secondary. For transactions other than delete- handle, home-prefix and unhome-prefix, the current handle values are included with the transaction listing.

Thanks,
Sean

On Jul 9, 2007, at 11:35 AM, Eric Auer wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi all,

I would like to get in contact with somebody who
has experience with mirroring / replication of
servers in the handle system. My questions are:

How do the servers know when to sync, which handles?
Which server does initiate the update, the mirror
server or the primary server of the mirrored area?
Is this related to the timestamp / TTL, and if so,
when is it checked? Regular intervals or only if a
client queries the mirror server? What happens if
the timestamp is not set (default is setting it to
zero in the HandleValue(index, type, value) java
constructor for values, only the many-parameter
extended constructor lets you set a time manually)?

Background is that we use The Handle System only as
an external interface. So the replication should
also work if we read (on primary and mirror) and
write (on primary) via the fast SQLHandleStorage
instead of the complex networked Handle System TCP
protocol with lots of slow handshaking...

It would probably be acceptable if we could read
the mirror only via TCP, but writing the server
via SQL is needed. We could modify our code to set
the timestamp / TTL via the SQLHandleStorage if
that is required for proper replication.

Thanks for shedding some light on mirrors :-).

Eric

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGkg9x99dkROyhRRsRAltRAJ9I5r/WIEG/YLOp6rElyF76Rglj/ACePqMq
eqmR3M6K73ih72ZvuBz8Ws0=
=4fji
-----END PGP SIGNATURE-----


_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info


Attachment: smime.p7s
Description: S/MIME cryptographic signature