This is an outline of my proposed replication scheme.

Each peer will have a complete list of peers.

	peer (peer_id, address)
	      -------

When an update, insert, or delete occurs, the transaction is logged to a 
transaction table.

	tr_log (datetime, tr_id, table, key, tr_type, command)
	        ---------------

The transaction log has two child tables that log the peers that have 
executed the transaction.  The are global and local tables.  The global 
table gets cleared when all peers have processed the transaction.

	g_tr_exec (datetime, id, peer_id)
	           ------------

The local table is only cleared when all peers are online and no peers 
have tr_log rows.  This table prevents the peer from reexecuting an old 
transaction.

	l_tr_exec (datetime, id)
	           ------------

The peer logging the transaction will create g_tr_exec and l_tr_exec rows 
when it creates the tr_log entry (it has already executed the command).  
The new tr_log and g_tr_exec rows are forwarded to each online peer.  Each 
online peer will execute the command and create their own g_tr_exec row, 
which is forwarded to all online peers.  When a tr_log row has a g_tr_exec 
child for every peer, the tr_log row and tr_exec children are deleted.

When a peer comes online, it will merge its tr_log and g_tr_exec with 
those of the other peers.  It will then check the log for any unexecuted 
transactions.  When one is found, the l_tr_exec table is checked to 
confirm that it is unexecuted.  If the transaction is unexecuted, the 
transaction is executed and logged and the log confirmation is forwarded 
to all online peers.  If the transaction has been executed, the 
transaction is not executed but still logged and the log confirmation is 
forwarded to all online peers.