RWP04: Registry Replication

Keith Noddle ktn at star.le.ac.uk
Thu Apr 24 09:29:25 PDT 2003


On Thu, 2003-04-24 at 17:18, Wil O'Mullane wrote:
> On Thu, Apr 24, 2003 at 04:22:20PM +0100, Keith Noddle wrote:
> > > Surely a user fo a registry just wants to search - he should not see
> > > this
> > > detail of implementation.
> > > Hence we need only 
> > >  1. Search the selected registry
> > Absolutely, that should be the default behaviour. I may be wrong, but I
> > get the impression that some astronomers want simple tools whilst others
> > want to know exactly what is being done and have control over the
> > process. Hence my suggestion that we support more complex search types,
> > like the www.google.com advanced search page, perhaps.
> This is true for image/data processing - not for registry searching I would say
If we adopt a distributed model we probably want to provide control over
the searching at some level, but see below...
>  
> 
> > 
> > > It would be nice if we had fail over though which caused the next reg
> > > to be searched if the selected one failed.
> > I agree. We do need to define "fail" however. Is it the absence of the
> > registry, lack of data within that registry ... ? If the latter, how far
> > do we expect the registry to spread the search on behalf of the user? To
> > which registries? Again I had in mind a simple default behaviour and an
> > advanced page for those who wish to delve.
> I still maintain registry where people search should probably be complete i.e. 
> they should harvest data from other registries to keep themselves complete.
> A search in a registry is then in a registry and never goes anywhere else.
So the registries would organise themselves in a Microsoft Primary
Domain Controller / Secondary Domain Controller(s) fashion? All data
held in a few central places with full fail over should the local
"primary" fail? That would work - would the data centres hosting the
primaries be up for the data and network volumes? Probably not too
excessive although we need to be sure as the primary / secondary scheme
is not truly scalable...

Keith.

-- 

Keith Noddle			Phone:  +44 (0)116 223 1894
AstroGrid Technical Lead	Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy	Mobile: +44 (0)7721 926 461
University of Leicester		Email:  ktn at star.le.ac.uk
Leicester, UK   LE1 7RH		Web:    http://www.astrogrid.org



More information about the registry mailing list