Data Domain: Replikoinnin uudelleensynkronoinnin selitys
Summary: Tässä artikkelissa kerrotaan, miten replikoinnin uudelleensynkronointi määrittää, mitä tietoja verkossa lähetetään.
Instructions
TARKOITUS
- Tässä artikkelissa kerrotaan, miten replikoinnin uudelleensynkronointi määrittää, mitä tietoja verkossa lähetetään. Lisätietoja uudelleensynkronoinnin suorittamisesta on artikkelissa: Data Domain: Kuinka rikkoa ja synkronoida hakemiston replikointi uudelleen.
KOSKEE SEURAAVIA:
- Kaikki Data Domain (DD) -mallit
- Hakemiston replikointi
- Kaikki ohjelmistoversiot 4.3 ja uudemmat
RATKAISU
Uudelleensynkronointi on lähes identtinen alustuksen kanssa, ja se voidaan jopa määrittää hakemistoreplikointikonteksteissa alustuksen sijasta seuraavin eroin:
Replikahakemiston *ei* tarvitse olla tyhjä. Sisäisesti kohde siirtää olemassa olevat tiedostot pois tieltä.
(Kohdissa 4.3–4.5 tämä tapahtuu nimeämällä nämä tiedostot uudelleen $destdir/.ddrsaved/ directory. 4.6+:ssa se tapahtuu tekemällä tilannevedos ja poistamalla tiedostot replikointikontekstista $destdir.)
Se tarkistaa jokaisen lähdehakemistossa olevan tiedoston kohdalla, onko kohteessa sama suhteellinen polku (tarkistamalla $destdir/.ddrsavedtai tilannevedos).
Jos tiedosto on olemassa, se tarkistaa, onko kohdetiedosto identtinen lähdetiedoston kanssa.
Jos se on identtinen, olemassa oleva replikatiedosto linkitetään kiinteästi paikalleen ilman lisävaatimuksia suodattaa tai lähettää mitään sen sisältöä.
Tiedoston identiteetin tarkistus tapahtuu jatkuvasti.
Tarkistus onnistuu, jos replikatiedosto on luotu hakemiston replikoinnin >avulla = 4.3.
Tämä tarkoittaa, että kylvö voidaan suorittaa suorittamalla kokoelman replikointi (kätevä, jos Data Domainit ovat lähiverkossa), rikkomalla sitten kokoelman replikointi ja tekemällä sitten hakemistoreplikoinnin uudelleensynkronointi.
Jos replikatiedostoa ei löydy tai sisältö ei täsmää, tiedosto replikoidaan normaalisti eli suodatetaan segmenttikohtaisesti.
Koko uudelleensynkronoinnin tarkoitus on välttää tätä suodatusta mahdollisuuksien mukaan.
Mahdollinen sudenkuoppa on, että ihmisen toiminta tai sovelluslogiikka, joka nimeää tiedostoja uudelleen, voi aiheuttaa alkuperäisen tai replikatiedoston siirtämisen tai uudelleennimeämisen replikoinnin katkeamisen jälkeen ennen uudelleensynkronointia.
Tämä aiheuttaa sen, että polun nimen haku uudelleensynkronoinnissa ei löydä vastaavuutta, ja edellyttää kunkin tiedoston täydellistä suodatusta.
Koska segmentit ovat olemassa määränpäässä, saavutetaan korkea replikoinnin pakkaus, mutta menetetään tilaisuus välttää segmenttiviitteiden lähettäminen ja suodattaminen.
-
Versiossa 4.5 uudelleensynkronointi epäonnistuu, jos replikassa on tai on joskus ollut käytössä säilytyslukitus.
-
Versiossa 4.6 ja sitä uudemmissa versioissa on joitakin lisävaatimuksia, jotka liittyvät replikan säilytyslukittuihin tiedostoihin. Periaatteessa minkä tahansa kohteen säilytyslukitun tiedoston on myös oltava olemassa, ja sillä on oltava vastaava sisältö ja määritteet lähettäjässä. Tämä estää replikointia yrittämästä poistaa säilytyslukittuja tiedostoja replikasta.