Project

General

Profile

Actions

Bug #332

closed

hub replication feature

Added by Matt Jones over 22 years ago. Updated about 22 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
metacat
Target version:
Start date:
11/29/2001
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
332

Description

Metacat replication is currently configured such that transfers are not
transitive (ie, if A replicates to B, and B replicates to C, the only data that
B will replicate to C is its own data). This is meant to prevent people from
having to set up extended trust netorks. This is a problem, however, for the
centralized access points that we designed for NCEAS/LTER.

At the annual meeting, we agreed that we need a special 'hub' replication
feature which enables a few special metacat servers to act as a virtual hub.
All data and metadata on one of these special hub nodes will be replicated to
the other hub nodes, regardless of its origin.

For example, if NCEAS and LTER metacats are the hub nodes, and NCEAS is
receiving replication data from NRS, and LTER is receiving replication data from
SEV, then all of the data would be replicated on both NCEAS and LTER hubs.
However, if the NRS metacat is getting data from a HAMILTON reserve metacat, the
NRS metacat will not replicate that HAMILTON data and metadata to NCEAS. This
preserves the trust relationship between NRS and HAMILTON, while allowing us to
create a virtual aggregation at the NCEAS/LTER hub. if HAMILTON wants its data
to show up on both the NRS and the NCEAS metacats, it will need to establish a
peering relationship with them both separately (e.g., HAMILTON -> NRS and
HAMILTON -> NCEAS).


Related issues

Blocks Metacat - Bug #331: metacat data replication featureResolvedJing Tao11/29/2001

Actions
Actions #1

Updated by Jing Tao about 22 years ago

In metacat.properties, a variable named hub is set. If its value=super. Then
the metacat can replicate (both force replication and delt replication )
the documents or data files even the documents' home_server is
not itself.

A element named home_server was added in document information xml. If Metacat
NCEAS want to insert a document from Metacat LTER. NCEAS should know the
home_server for this documents first (Because if LTER is set hub, the
document's home_server probably is not ITER itself). If the home_server is
already in NCEAS' server list, just insert this documet as the server code of
the home_server. If home_server isn't in NCEAS' server list. Insert
home_server first, then insert document.

Actions #2

Updated by Jing Tao about 22 years ago

Change hub feature form node base to server base

Actions #3

Updated by Jing Tao about 22 years ago

In xml_replication table, a field named hub was add there. If this value was
set 1, this means local metacat is a hub server to this remote server in the
table. In other world, local metacat will replicate the documents whose home
server are not only itself but also other's to this remote metacat.

ReplicationServer and ReplicationServerList classes were created. An object of
ReplicationServer represents a entry in xml_replication table. It has a field
name hub and data type is boolean. So we can control the hub features from
this field. An object of ReplicationServerList reprents all entries in the
xml_replication table.

Actions #4

Updated by Redmine Admin over 11 years ago

Original Bugzilla ID was 332

Actions

Also available in: Atom PDF