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

Also available in: Atom PDF