Replicatie-algoritme
Laten we stap voor stap bekijken wat er gebeurt tijdens een replicatiesessie

Stap 1. Een verbinding tot stand brengen met de server. De server (station) die de replicatie initieert, maakt verbinding met de opgeroepen server. De authenticatieprocedure vindt plaats en de mogelijkheid om toegang te krijgen tot de deze server(over het authenticatiemechanisme en toegangscontrole tot de server >>>)
De server gebruikt het verbindingsdocument om het replicatieschema in te stellen Adresboek, Notes-client - Locatiedocument
Stap 2. Een lijst met gerepliceerde databases opbouwen. Elke server ondersteunt zijn eigen server virtueel geheugen een tabel met alle beschikbare databases en sjablonen, geordend op replica-identifier - de zogenaamde replica-ID-cache. De replicator vergelijkt zijn cache met de cache van de opgeroepen server en bouwt, rekening houdend met replicatieprioriteiten en databases die zijn opgegeven voor replicatie (in het Connection-document of in de consoleopdrachtparameters), een lijst met databases die in deze sessie moeten worden gerepliceerd.
Stap 3. Vervolgens voor elke basis uit de lijst
• Bepaalt of databasereplicatie verboden is. Als een van de replica's is geconfigureerd met een optie die replicatie verbiedt ( Schakel replicatie voor deze replica tijdelijk uit in de replicatie-instellingen), vindt databasereplicatie niet plaats, zoals aangegeven door de regel op de serverconsole. Replicatie is uitgeschakeld<сервер> <база>
• Kan elk van de servers een replica op een andere server openen? Als een van de servers geen toegang heeft (niveau Geen toegang) tot een van de replica's, of geen toegang heeft tot de verbonden (gekoppelde) map waarin de replica zich bevindt, eindigt de databasereplicatie met een bericht Toegangscontrole is ingeschakeld<сервер> <база>om replicatie van niet toe te staan<сервер> <база> . Als beide servers toegang hebben tot beide replica's, opent de replicator een replica op de opgeroepen server.
• ACL-replicatie. Voor ACL-replicatie is het noodzakelijk dat de opgeroepen server beheerderstoegang heeft tot de ACL van de aanroepende server en dat deze optie is geselecteerd in de replicatie-instellingen op de aanroepende server Ontvang deze elementen van andere replica's: Toegangscontrolelijst. De replicator vergelijkt de ACL-wijzigingsdatums in beide replica's. Als de ACL van de ‘buitenlandse’ replica later is gewijzigd dan de ACL van de ‘eigen’, ontvangt de replicator de ACL van de opgeroepen server en vervangt daarmee zijn eigen ACL, waarna hij opnieuw controleert of elk van de servers open kan de replica van de ander. Met het schema Trek-duw spiegelachtige acties worden door de replicator uitgevoerd in relatie tot de ACL op de opgeroepen server. Met een replicatieschema Trek-trek de update (indien nodig) wordt uitgevoerd door de replicator van de opgeroepen server nadat de controle daaraan is overgedragen in de tweede fase van de replicatiesessie
• Replicatie van ontwerpelementen. Om dit deel van de databasereplicatie succesvol te laten zijn, is het noodzakelijk dat het toegangsniveau van de aangeroepen server in de ACL van de databasereplica op de initiërende server minimaal gelijk is aan het Designer-niveau. De server zoekt en accepteert ontwerpelementen die later op de opgeroepen server zijn gewijzigd dan deze elementen op zijn kant, en vervangt deze laatste. Maar alleen als dit is toegestaan ​​door de opties die zijn opgegeven in de databasereplicatieparameters in de velden Ontvang deze elementen van andere replica's: ontwerpelementen, agenten, replicatieformules. Het verwijderen van ontwerpelementen is vergelijkbaar met het verwijderen van documenten door verwijderingsinformatie door te geven ( stompjes). Na het accepteren van de wijzigingen duwt de server de wijzigingen die op zijn kant hebben plaatsgevonden naar buiten (diagram Trek-duw) na spiegelachtige controles, of gaat door naar de volgende fase van ontvangst, waarbij de overdracht van wijzigingen wordt overgelaten tot de tweede fase van de sessie (schema Trek-trek)
• Replicatie van documenten. Ontvangst van documentwijzigingen op de initiërende server vindt plaats als de opgeroepen server toegang heeft tot de database (ACL) en documenten (toegangsvelden tot documenten van het type Lezers en Auteurs), waardoor u documenten kunt aanmaken, wijzigen of verwijderen. Onder de documenten van de opgeroepen server wordt een speciale weergave gebouwd met daarin documenten volgens de replicatieformule. De replicator maakt vervolgens een lijst met document-ID's die sinds de laatste replicatie zijn gewijzigd. Als de optie Documenten ontvangen van server - Kleinste eerst is ingeschakeld in de replicatie-instellingen, wordt de resulterende lijst gesorteerd op documentgrootte, anders op wijzigingsdatum. Vervolgens wordt voor elk document de tegenhanger in zijn replica doorzocht op identificatie. Als dit niet lukt, nieuw document toegevoegd aan de replica. Als het document niet nieuw is, worden het tijdstip van de laatste wijziging en de volgnummers van deze documenten vergeleken. Als het document is gewijzigd sinds de laatste replicatie op beide servers, treedt er een replicatieconflict op (dit geval wordt hieronder besproken). Anders worden de wijzigingen verzonden naar de replicatie-initiërende server, waarbij het document op zijn kant wordt gewijzigd. Bovendien gebeurt dit vanaf versie 4.x niet meer volledige kopie alle velden, alleen velden met verschillende Seq Num-vlaggen worden gekopieerd. Hierdoor wordt het volume aanzienlijk verminderd doorgegeven informatie. Dit wordt replicatie op veldniveau (items) genoemd. Verder herhaalt de serverreplicator, afhankelijk van het replicatieschema, de acties die in deze paragraaf worden beschreven in de spiegelrichting, waarbij nieuwe en gewijzigde documenten worden gepubliceerd (schema Trek-duw), of gaat onmiddellijk verder met het volgende punt en laat dit werk over aan de replicator van iemand anders ( Trek-trek)
• Een vermelding in de replicatiegeschiedenis bijwerken. Na succesvolle voltooiing van de voorgaande replicatiefasen maakt de replicator een aantekening in de replicatiegeschiedenis van zijn replica. Als replicatie plaatsvindt volgens het schema Trek-duw, dan maakt de replicator een soortgelijke vermelding in de replicatiegeschiedenis van de replica van iemand anders
Stap 4. Einde van de replicatiesessie. Wanneer de lijst met gerepliceerde databases uitgeput is, verbreekt de replicator de verbinding (scheme Trek-duw), of stuurt een verzoek om de replicator te activeren achterkant en het terugsturen van wijzigingen.

Replicatieconflicten oplossen
Wanneer de replicator detecteert dat sinds de laatste replicatieversies van het document in beide databasereplica's zijn gewijzigd, wordt hij gedwongen de situatie van een replicatieconflict aan te pakken. De versie van het document met een latere wijzigingstijd wordt geselecteerd en gebruikt als hoofddocument. De tweede versie van het document wordt opgeslagen als antwoorddocument op het hoofddocument (de aanwezigheid van een $Ref-veld met een link naar het hoofddocument). Bovendien wordt een veld met de naam $Conflict toegevoegd aan het antwoorddocument en lege waarde. In opvattingen die ondersteunen hiërarchische organisatie documenten, worden dergelijke documenten weergegeven als een antwoorddocument, gemarkeerd met een ruit in de documentselectiekolom en een lijn .
Eigenlijk om conflicten op te lossen, te beginnen vanaf de vijfde Opmerkingen versies, wordt beïnvloed door de waarde van het veld $ConflictAction, waarvan de waarde in de Domino Designer-clientinterface kan worden ingesteld via de eigenschap Conflict Handling van het formulier waarop documenten worden gemaakt

• De waarde van deze eigenschap Create Conflicts (geen veld $ConflictAction of veldwaarde ingesteld op "1" in het document) specificeert de hierboven beschreven machtiging conflictsituatie- het creëren van een replicatieconflict
• Eigenschapswaarde conflicten samenvoegen ($ConflictAction veldwaarde gelijk aan "2") - conflicten samenvoegen die zijn opgetreden bij het bewerken van verschillende velden in verschillende databasereplica's

Organisatorisch gezien is het, om de conflicten op te lossen die zijn ontstaan, noodzakelijk om de auteurs van de veranderingen “aan een ronde tafel” te verzamelen om te begrijpen wijzigingen aangebracht en ontwikkeling van een overeengekomen optie.
Technisch gezien is dit probleem als volgt opgelost. Als wordt besloten de versie van het document als hoofdversie te laten gelden, wordt het conflicterende document eenvoudigweg verwijderd. Als u de versie van het conflicterende document wilt behouden, open het dan in de bewerkingsmodus, sla het op (de velden $Conflict en $Ref verdwijnen en het document wordt het hoofddocument) en verwijder vervolgens de andere versie van het document. [Maar in dit geval, als er een conflict optreedt met het antwoorddocument, samen met het $Ref-veld, gaat de binding met het hoofddocument verloren. Het is noodzakelijk om de verbroken verbinding te herstellen]. Ten slotte, als beide versies moeten blijven bestaan, is het voldoende om het conflicterende document opnieuw op te slaan.
Als er tijdens de werking van de basis een verhoogde neiging bestaat om conflicten te creëren, is het hoogstwaarschijnlijk nodig om het ontwerp van de basis of de technologie om ermee te werken te veranderen. Een van de meest effectieve technieken ontwerpwijzigingen - splitsing groot document in verschillende kleine documenten, waarbij wijzigingen niet in één document worden aangebracht, maar op basis van de creatie van nieuwe, kleinere documenten. Bovendien biedt het venster met formuliereigenschappen opties Versiebeheer- documentversiebeheer en Conflicthantering- met de optie voor het automatisch samenvoegen (samenvoegconflicten) van conflicterende documenten, indien verschillende gebruikers veranderde verschillende velden daarin.
NAAR organisatorische problemen Dit verwijst in de eerste plaats naar de technologische beperking van de mogelijkheid om een ​​document door zo weinig mogelijk gebruikers te bewerken (idealiter de auteur van het document plus, voor de zekerheid, de databasebeheerder). Andere gebruikers brengen wijzigingen aan in het document door er antwoorddocumenten voor te maken in de vorm van opmerkingen.

Standaard repliceert Domino alle databases die dezelfde replica-ID hebben. Als u alleen specifieke databases wilt repliceren, bewerkt u het veld Bestand/mappen die u wilt repliceren in het verbindingsdocument. Voer in dit veld de namen in van de databases of directorynamen die u wilt repliceren. Scheid ze van elkaar met een puntkomma.

Om de geselecteerde database voor replicatie te identificeren, voert u de bestandsnaam in, inclusief de .NSF-extensie. Als de database zich in een submap bevindt, vermeldt u het pad dat relatief is aan de Notes-gegevensmap, bijvoorbeeld EAST\SALES.NSF.

Om alle bestanden in een map te identificeren, typt u EAST\. U kunt hiervoor geen asterisk (*) gebruiken.

Repliceer databases op basis van hun prioriteiten.

Databasebeheerders wijzen replicatieprioriteit toe aan databases, zodat Domino-beheerders replicaties voor databases kunnen plannen op basis van prioriteit. U kunt bijvoorbeeld prioriteit geven aan databases die bedrijfskritisch zijn. Domino Directory wordt bijvoorbeeld regelmatig gerepliceerd. U kunt ook databases met een lage prioriteit targeten.

Replicatie-instellingen die prioriteit gebruiken, worden bewerkt in het veld Databases repliceren van van het verbindingsdocument. De standaardinstelling is Lage & Gemiddelde & Hoge prioriteit.

Als aan twee replica's verschillende prioriteiten zijn toegewezen, gebruikt Domino de prioriteit die is toegewezen aan de replica's op de server die de replicatie initieert.

Tijdslimiet voor replicatie.

Door de replicatietijd te beperken, voorkomt u uitgebreide replicatiesessies en kunt u de kosten van replicaties op afgelegen gebieden van uw systeem beheren. Als replicaties bijvoorbeeld afhankelijk zijn van verbinding op afstand via de telefoon en de database heeft tijd nodig om te repliceren, u kunt de duur van de replica's beperken.

Om de tijd van replica's te beperken, voert u een waarde in het veld Replicatietijdlimiet uit het verbindingsdocument in.

Waarschuwing Opmerking: als u een zeer korte tijd opgeeft, kunnen de databases niet volledig worden gerepliceerd. Het LOG.NSF-bestand maakt een vermelding die aangeeft dat er een communicatie-afsluiting heeft plaatsgevonden, maar dat de replicatie niet is gelukt. De replicatiegeschiedenis wordt niet bijgewerkt.

Om replicaties voor de hele server in de tijd te beperken, bewerkt u het NOTES.INI-bestand zodat het de ReplicationTimeLimit-variabele opneemt.

Meerdere replicatoren tegelijkertijd gebruiken

Als u verbindingsdocumenten maakt die meerdere serverreplicaties tegelijkertijd gebruiken, of replicaties met verschillende doelservers overlappen, voert u meerdere replicators uit om elke sessie af te handelen. Meerdere lanceringen van de replicator maken effectief gebruik van serverbronnen, verkorten de replicatiecycli, vooral op Hub-servers, en besparen replicatietijd.

Wanneer u meerdere replicaties gebruikt, verwerkt elke replicator slechts één replicatiesessie. Als Hub-E/East/Acme bijvoorbeeld gepland is om tegelijkertijd naar zowel HR-E/East/Acme als Hub-W/West/Acme te repliceren, handelt één replicator de replicatie van Hub-E/East/Acme af en HR-E/East/Acme, een andere replicator verzorgt de replica tussen Hub-E/East/Acme en Hub-W/West/Acme.

Meerdere replicators verwerken tegelijkertijd meerdere replica's tussen één bronserver en meerdere doelservers.

Voorbeeld. Als Database 1 en Database 2 op Hub-E/East/Acme moeten repliceren vanuit Hub-W/West/Acme, praat er om beurten slechts één replicator met elke replicatiesessie.

Bestudeer de verbindingsdocumenten die uw replicaties op elke server in kaart brengen. Door replicaschema's aan te passen en meerdere replicators uit te voeren, kunt u de tijd verkorten volledige cyclus replicaties. Met deze vermindering van cycli kunt u een of meer extra cycli per dag plannen, wat kortere tijdsintervallen voor het bijwerken van databasegegevens en een snellere replicatiecyclus betekent. Nadat u meerdere replicators hebt gestart, kunt u de opdracht -Tell gebruiken om alle replicators te stoppen; U kunt echter niet de opdracht -Tell gebruiken om een ​​specifieke replicator te stoppen.

Tenzij u meerdere replicators gebruikt, mag u geen replica's plannen vanaf de server die tegelijkertijd verschillende poorten gebruikt.

Voorbeeld. Als u één replicator gebruikt, plan dan niet tegelijkertijd een replica van Hub-E/East/Acme naar Hr-E/East/Acme op COM1 als van Hub-E/East/Acme naar Hub-W/west / Acme via COM2 gelijktijdig.

Meerdere replicatoren toestaan.

Afwijzing van replicatieverzoeken van de server.

Om te voorkomen dat de server replicatieverzoeken accepteert, bewerkt u het NOTES.INI-bestand zodat het de variabele ServerNoReplRequests opneemt. Als deze instelling is ingesteld op 1, weigert de server alle replicatieverzoeken.

U kunt deze functie gebruiken om de replicatiewerklast op een geselecteerde server te verminderen.

Verbod op replicaties.

Als u replicaties wilt uitschakelen (bijvoorbeeld als u replicaties op meerdere servers test, of als u niet wilt dat bepaalde databases worden gerepliceerd), kunt u replicaties uitschakelen.

Om replicatie uit te schakelen, bewerkt u het verbindingsdocument in de Domino Directory. Schakel in de sectie Replicatie het gebruik van replicatie uit en stel de veldwaarde Replicatie in op Taken – Uitgeschakeld.

Geplande replicaties forceren.

U kunt wijzigingen repliceren naar kritieke databases, zoals Domino Directory, zonder te wachten op geplande replicatie. Nadat u verbindingsdocumenten hebt gemaakt, kunt u de serverconsoleopdracht gebruiken om onmiddellijke replicatie af te dwingen.

Er zijn veel situaties waarin gedwongen replicaties nodig zijn. Het kan bijvoorbeeld zijn dat u de database onmiddellijk wilt upgraden, zonder te wachten op geplande replicatie, of dat u gegevens van verschillende servers wilt repliceren omdat deze servers doorgaans niet beschikbaar zijn.

Wanneer u onmiddellijke server-naar-server-replicatie afdwingt, kunt u in één of beide richtingen repliceren.

Commando's voor de replicator:

Replica- Veranderingen in databases worden in beide richtingen gerepliceerd. Domino haalt eerst de wijzigingen op en duwt vervolgens de gewijzigde documenten naar buiten.

Trekken- Wijzigingen in databases worden in één richting gerepliceerd, waarbij de server alleen wijzigingen van een andere server oppikt

Duw- Veranderingen in databases worden in één richting gerepliceerd, waarbij de server databasewijzigingen alleen naar een andere server pusht.

Documentbeheersysteem Lotus-notities

Kenmerkend

Lotus Notes - Databasegericht eigen formaat systeem client-server-architectuur, ontwikkeld door Lotus Development Corporation, dat momenteel wordt ontwikkeld en verkocht door IBM. Het systeem is actief verschillende platforms Windows-families en UNIX.

Doel

Lotus Notes is oorspronkelijk ontworpen om in te werken lokale netwerken, maar nu kan het ook wereldwijd werken, bijvoorbeeld op internet.

Belangrijkste componenten:

DOOR gemiddeld niveau(Middelware).

Korte beschrijving functioneren

Elke client of server kan meerdere lokale databases hebben. Elke database is een verzameling aantekeningen. De client is een combinatie van een startsubsysteem en weergavemodules, qua functionaliteit vergelijkbaar met webbrowsers. In tegenstelling tot browsers bieden ze niet alleen de mogelijkheid om informatie te lezen, maar ook om informatie te bewerken.

De belangrijkste functie van een Lotus-server (Lotus Domino) is het beheren van een verzameling databases en het verlenen van toegang daartoe aan clients en andere servers.

Replicatie

Replicatie is gebaseerd op verbindingsdocumenten - speciale opmerkingen in de Domino-directory die het tijdstip, de methode (replicatieschema - zie Tabel 5) en het replicatieobject beschrijven.

Tabel 4 Typen identificatiecodes voor bankbiljetten
Identificatie	Domein	Beschrijving
Universele ID (UNID)	Globaal	Globaal unieke identificatiecode toegewezen aan elk biljet
Auteurs-ID (OID)	Globaal	Noteer ID inclusief geschiedenisinformatie
Database-ID	Binnen de server	Tijdstempel voor het maken van een database of het herstellen van een database na een serverstoring
Opmerking-ID	Binnen de databank	Opmerking ID afhankelijk van het DB-exemplaar
Replica-ID	Globaal	Tijdstempel die wordt gebruikt om kopieën van dezelfde database te identificeren

Bewerkingen wijzigen:

Documentwijziging;

Een document toevoegen;

Een document verwijderen.

Het gewijzigde document moet naar alle replica's worden gedistribueerd. Wijzigingen in een notitie resulteren in een wijziging in de OID, waarvan de vorige waarde wordt gekopieerd naar het documentgeschiedenislogboek. Wanneer u een document toevoegt, worden er een nieuwe UNID en OID voor gemaakt. Wanneer een document wordt verwijderd, wordt op zijn plaats in de database een verwijderingsstrookje geplaatst. Het verwijderstrookje wordt pas vernietigd als alle kopieën zijn vernietigd verwijderd document.

Replicatieconflicten oplossen

Tijdens pull-forward-replicatie wordt voor elke replica een lijst met OID's gemaakt. Vervolgens worden de lijsten van de twee servers vergeleken. Notities met UNID's die niet aanwezig zijn op de andere server (d.w.z. toegevoegd) moeten ernaar worden overgebracht.

Voor notities met dezelfde UNID maar een andere OID in de lijsten met servers A en B: volgende stappen. Bij de replicatietaak wordt naar de geschiedenis van beide notities gekeken. Als een van de verhalen deel uitmaakt van de andere, is er geen conflict: de nieuwere noot vervangt de oudere. Als de wijzigingen van toepassing zijn op verschillende elementen notities, dan zijn er ook geen tegenstrijdige wijzigingen: de meest recente elementen worden overgebracht naar de samengevoegde notitie. In alle andere gevallen is het conflict onoplosbaar. In dit geval kiest Notes één van de documenten als winnaar. Dit wordt de kopie met het grotere serienummer in de OID of (bij gelijke serienummers) met een grotere tijdstempel.

Replicatie in een cluster

In een cluster worden wijzigingen, in plaats van de replicatie expliciet te plannen met behulp van lijmdocumenten, eenvoudigweg onmiddellijk doorgegeven aan alle replica's in het cluster.

Voor dit doel onderhoudt elke server een wachtrij voor replicatiegebeurtenissen waarin lokale wijzigingen worden vastgelegd. Eén keer per seconde bijzondere taak replicatie scant de wachtrij op wijzigingen die moeten worden doorgegeven aan andere servers in het cluster, promoveert deze en verwijdert gebeurtenissen uit de wachtrij.

Alles over Lotus Notes/Domino-replicatie

1
Gedistribueerde databases. De essentie van het replicatiemechanisme
Een van onderscheidende kenmerken Lotus Notes/Domino als ondersteuningsproduct groepswerk (groepssoftware) - de aanwezigheid van een mechanisme voor het ondersteunen van gedistribueerde databases. Termijn Gedistribueerde database in deze context moet worden opgevat als een verzameling van meerdere gelegen op diverse servers Domino- of clientstations "versies" ( replica's) één databank. Deze replica's zijn mogelijk geen exacte spiegels van elkaar (en zijn dat in het algemeen ook niet). Het instellen van toegangsrechten tot de database en het instellen van een selectieve selectie van documenten en replica-ontwerpelementen bieden de mogelijkheid om een ​​subset van documenten voor een specifieke replica te selecteren. Maar replica's hebben, in tegenstelling tot databasekopieën, de mogelijkheid gemeen om wijzigingen uit te wisselen die zijn opgetreden in documenten, of verschenen/verwijderde documenten (houd rekening met de vorige passage, gebruik de term synchronisatie gepast, met enig voorbehoud). Met deze distributie hebben gebruikers toegang tot gegevens van een Domino-server die hen beter bekend is. Of gebruik gewoon de gegevens op het mobiele werkstation en bel slechts af en toe de server om de informatie bij te werken. Dankzij de eenvoud en betrouwbaarheid van het replicatiemechanisme is het mogelijk om het werk effectief te organiseren met middelen voor grote gemeenschappen territoriaal verwijderde vriend van bevriende gebruikers. Het proces van het vinden en delen van veranderingen heet replicatie. De taak is verantwoordelijk voor de ondersteuning van dit proces op de server- en clientstations Replicator
Databasereplica's worden verenigd door dezelfde replica-ID (Replica-ID), die wordt toegewezen wanneer de database wordt gemaakt en van toepassing is op alle replica's ervan. In tegenstelling tot replica's leidt het maken van een kopie van een database (kopieën niet op bestandsniveau, maar in Notes-termen) tot de toewijzing van een andere replica-ID aan de kopie en de uitsluiting van de resulterende kopie van het mechanisme voor het uitwisselen van wijzigingen met de database die het heeft gegenereerd. De replica-ID (code) kunt u zien in het venster Database-eigenschappen

De replica-ID wordt ook gebruikt bij het opgeven van de documentlocatie (document-URL):

Replicaties tussen servers kunnen plaatsvinden volgens een schema (het belangrijkste type replicatietaak, we zullen er later in meer detail op ingaan), door een taak te starten vanaf de serverconsole, door een taak te starten vanaf besturingssysteem het downloaden van het uitvoerbare bestand

• de hoofdreplicatortaak, die geplande replicaties verzorgt, wordt (meestal) geladen wanneer de server start, waarvoor dit wordt aangegeven in de lijst met servertaken - de ServerTasks-variabele ( ServerTasks=takenlijst, replica, takenlijst), en kan slechts één replicatiesessie tegelijk uitvoeren. Als u meerdere replicaties wilt uitvoeren, moet u meerdere taken tegelijkertijd uitvoeren. Dit kan worden bereikt door de Replicators-variabele op te geven of door verschillende Replicator-taken (Replica) op te geven in de lijst met gestarte taken in de ServerTasks-variabele (beide variabelen zijn opgegeven in het NOTES.INI-instellingenbestand)
• Er wordt een extra replicatortaak geladen met de opdracht Replica laden vanaf de serverconsole
• Met de opdracht wordt een extra replicatortaak geladen voor replicatie met een specifieke server

Replica laden<имя сервера> <имя базы данных> (Pull-Push-schema),
Repliceren<имя сервера> <имя базы данных> (hetzelfde als het vorige commando),
Laad trek<имя сервера> <имя базы данных> (Alleen trekken)
of Laad duwen<имя сервера> <имя базы данных> (Alleen push-schema) vanaf de serverconsole. De replicator die door een dergelijke opdracht wordt gestart, wordt beëindigd nadat de replicatie is voltooid. Wanneer u de naam opgeeft van de server die u wilt aanroepen, probeer dan de hiërarchische naam (Canonical of Abbreviated) op te geven, in plaats van de algemene naam (Common). Er is een bekend probleem met betrekking tot verschillen in toegang tot de database waar de opgeroepen server (bij het specificeren ervan canonieke naam) had grote rechten en kon zien groter aantal documenten, terwijl gemeenschappelijke naam doorgegeven als -Default- en als gevolg van een dergelijke replicatie zijn de meeste documenten aan de kant van de opgeroepen server verwijderd

• Het is ook mogelijk om de replicator op besturingssysteemniveau te starten door een bestand te starten programma catalogus Opmerkingen met sleutels:
  xREPLICA servernaam ,
  Waar
  x - I voor OS/2, N voor Windows, V voor Novell. Unix-systemen gebruiken uitvoerbaar bestand zonder hoofdpersoon (alleen REPLICA)
  - optionele parameter die het type replicatie bepaalt (-p - Alleen Pull, -s - Alleen Push, weggelaten - Pull-Push)
  servernaam - naam van de opgeroepen server
  - gerepliceerde databases

Ten slotte moet worden gezegd dat om replicators (hoewel allemaal tegelijk) te verwijderen, het commando Tell Replica Quit wordt gebruikt

Documentbeheersysteem Lotus Notes

Kenmerkend

LotusNotes is een client-server architectuursysteem gericht op een database met een eigen formaat, ontwikkeld door de LotusDevelopment Corporation, die momenteel wordt ontwikkeld en verkocht door IBM. Het systeem draait op verschillende platforms van de Windows- en UNIX-families.

Doel

LotusNotes is oorspronkelijk ontworpen om op lokale netwerken te werken, maar kan nu ook op mondiale netwerken werken, bijvoorbeeld op internet.

Belangrijkste componenten:

• Middelware.

Korte beschrijving van de werking

Elke client of server kan meerdere lokale databases hebben. Elke database is een verzameling aantekeningen. De client is een combinatie van een startsubsysteem en weergavemodules die qua functionaliteit vergelijkbaar zijn met webbrowsers. In tegenstelling tot browsers bieden ze niet alleen de mogelijkheid om informatie te lezen, maar ook om informatie te bewerken.

De belangrijkste functie van de Lotus-server (LotusDomino) is het beheren van een verzameling databases en het verlenen van toegang daartoe aan clients en andere servers.

Replicatie

Replicatie is gebaseerd op verbindingsdocumenten - speciale opmerkingen in de Domino-directory die het tijdstip, de methode (replicatieschema - zie Tabel 5) en het replicatieobject beschrijven.

Tabel 4 Soorten notitie-ID's
Identificatie	zichtbaarheid	Beschrijving
Universele ID (UNID)	Globaal	Globaal unieke identificatiecode toegewezen aan elk biljet
Auteurs-ID (OID)	Globaal	Noteer ID inclusief geschiedenisinformatie
Database-ID	Binnen de server	Tijdstempel voor het maken van een database of het herstellen van een database na een serverstoring
Opmerking-ID	Binnen de databank	Opmerking ID afhankelijk van het DB-exemplaar
Replica-ID	Globaal	Tijdstempel die wordt gebruikt om kopieën van dezelfde database te identificeren

Bewerkingen wijzigen:

documentwijziging;

een document toevoegen;

een document verwijderen.

Het gewijzigde document moet naar alle replica's worden gedistribueerd. Wijzigingen in een notitie resulteren in een wijziging in de OID, waarvan de vorige waarde wordt gekopieerd naar het documentgeschiedenislogboek. Wanneer u een document toevoegt, worden er een nieuwe UNID en OID voor gemaakt. Wanneer een document wordt verwijderd, wordt op zijn plaats in de database een verwijderingsstrookje geplaatst. Het verwijderstrookje wordt pas vernietigd als alle kopieën van het verwijderde document zijn vernietigd.

Tabel 5 Replicatieschema's
	Beschrijving
Extractie-promotie	De replicatietaak leest wijzigingen van de doelserver en verzendt deze daarnaartoe eigen veranderingen
extractie	De replicatietaak leest wijzigingen van de doelserver en brengt zijn eigen wijzigingen daarheen over op basis van zijn verzoeken
Bevordering	De replicatietaak verzendt zijn eigen wijzigingen naar de doelserver zonder op enigerlei wijze te reageren op bestaande wijzigingen
Extractie	De replicatietaak leest wijzigingen van de doelserver zonder te proberen zijn eigen wijzigingen ernaar te pushen

Replicatieconflicten oplossen

Tijdens pull-forward-replicatie wordt voor elke replica een lijst met OID's gemaakt. Vervolgens worden de lijsten van de twee servers vergeleken. Notities met UNID's die niet aanwezig zijn op de andere server (d.w.z. toegevoegd) moeten ernaar worden overgebracht.

Voor notities met dezelfde UNID in de lijsten van servers A en B, maar verschillende OID's, worden de volgende acties uitgevoerd. Bij de replicatietaak wordt naar de geschiedenis van beide notities gekeken. Als een van de verhalen deel uitmaakt van de andere, is er geen conflict: de nieuwere noot vervangt de oudere. Als de wijzigingen betrekking hebben op verschillende elementen van een notitie, zijn er ook geen tegenstrijdige wijzigingen: de meest recente elementen worden overgebracht naar de samengevoegde notitie. In alle andere gevallen is het conflict onoplosbaar. In dit geval kiest Notes één van de documenten als winnaar. Dit wordt de kopie met het grotere serienummer in de OID of (bij gelijke serienummers) met een grotere tijdstempel.

Replicatie in een cluster

In een cluster worden wijzigingen, in plaats van de replicatie expliciet te plannen met behulp van lijmdocumenten, eenvoudigweg onmiddellijk doorgegeven aan alle replica's in het cluster.

Voor dit doel onderhoudt elke server een wachtrij voor replicatiegebeurtenissen waarin lokale wijzigingen worden vastgelegd. Eén keer per seconde scant een speciale replicatietaak de wachtrij op wijzigingen die moeten worden doorgegeven aan andere servers in het cluster, promoveert deze en verwijdert gebeurtenissen uit de wachtrij.