sql >> Database >  >> RDS >> Database

Volgerclusters - 3 belangrijke gebruiksscenario's voor het synchroniseren van SQL- en NoSQL-implementaties

Volgersclusters zijn een ScaleGrid-functie waarmee je twee onafhankelijke databasesystemen (van hetzelfde type) gesynchroniseerd kunt houden. In tegenstelling tot klonen of replicatie, kunt u hiermee een actieve, point-in-time kopie van uw productiegegevens behouden. Dit extra cluster, ook wel volgerscluster genoemd, kan worden gebruikt voor meerdere gebruiksscenario's, waaronder voor het analyseren, optimaliseren en testen van uw applicatieprestaties voor MongoDB, MySQL en PostgreSQL. In deze blogpost behandelen we de drie belangrijkste scenario's om volgersclusters voor uw toepassing te gebruiken.

Hoe verschillen volgclusters van replicatie?

In tegenstelling tot een statische kloon, worden deze gegevens volgens een vast schema geïmporteerd, zodat uw volgcluster altijd synchroon loopt met uw productiecluster. Hier zijn een paar belangrijke manieren waarop het verschilt van replicatie:

  • Je kunt bepalen hoe vaak het doelsysteem vanaf de bron synchroniseert:één keer per week, één keer per dag of zelfs minder vaak. Dit helpt de belasting van het bronsysteem te verminderen.
  • Omdat het twee onafhankelijke systemen zijn, heb je veel meer flexibiliteit over de gegevens die worden gesynchroniseerd. U kunt verschillende gebruikersreferenties hebben en zelfs sommige gegevens van de bestemming verwijderen op basis van beveiligingsvereisten (opmerking:dit vereist scripting aan de gebruikerszijde - het is geen ingebouwde functie van volgerclusters).
  • Het 'volger'-systeem is beschrijfbaar, dus je kunt het gebruiken als een staging-omgeving om je applicatiewijzigingen te testen. Dit kun je niet doen op een replicanode.

Opmerking:ScaleGrid implementeert volgclusters met behulp van storage snapshots. Het is niet beschikbaar voor onze in-memory database-aanbiedingen zoals hosting voor Redis™*.

1. Database Dev/Test Setup

We hebben het allemaal meegemaakt:een zogenaamd goed getest stukje code wordt in productie genomen en dan breekt de hel los. Productieworkflows mislukken of zijn zo traag dat ze eigenlijk onbruikbaar zijn. Ingenieurs worden uit hun bed gewekt om een ​​volledige brandbestrijdingsoperatie te starten. Een stel slapeloze nachten later komt die gevreesde oorzaak naar voren.

Applicatie gedraagt ​​zich anders op productie- en technische instellingen.

Met andere woorden, we hebben het getest op "testgegevens". Wat, zo bleek, in niets leek op de productiegegevens. Helemaal niet.

De voor de hand liggende manier om deze situatie te vermijden, is door tests uit te voeren op uw productiegegevens. Geen echte productie natuurlijk - dat zal flirten met rampspoed. Op een gekloonde kopie van de productiegegevens. Hoewel zorgen over privacy en gegevensbeveiliging dit in veel scenario's onuitvoerbaar maken, als de privacyvereisten dit toelaten, is dit de beste oplossing. We hoeven niet langer te vertrouwen op technici die de juiste datasets genereren - als het testgegevens doorgeeft, geeft het productiegegevens door.

Dat wil zeggen, totdat de testgegevens zo ver uit de pas lopen met de productie dat het niet langer een goede benadering is. En we zijn weer bij af.

Dit is waar clusters van volgers van pas komen.

Door volgerclusters te gebruiken, kunt u periodiek gegevens uit uw productiedatabase importeren in de dev/test-database. En aangezien de volledige import wordt uitgevoerd met snapshots van de opslag in plaats van een logische dump, is het proces bijna onmiddellijk. U kunt uw imports eens per 24 uur, eens per week plannen, of op welke frequentie dan ook die bij uw specifieke scenario past.

Met uw ontwikkelings- en QA-clusters zo ingesteld dat ze het productiecluster volgen, kunt u gerust zijn. Als uw applicatie de testdataset doorgeeft, is deze zeker geschikt om in productie te nemen!

2. Gegevensanalyse

Als je als DBA hebt gewerkt, heb je waarschijnlijk een gesprek met je team gehad over de systeemprestaties die op bepaalde momenten 'mysterieus' langzamer gaan werken. In de meeste gevallen blijkt de boosdoener een analysetaak te zijn die toegang heeft tot tonnen gegevens en uiteindelijk het hele systeem vertraagt.

Als DBaaS-leverancier hebben we dit gesprek meerdere keren met onze klanten gevoerd. Dit zijn de twee opties die we gewoonlijk voorstellen:

  • Als de analysetaak wordt uitgevoerd op de primaire/masterserver, verplaats deze dan naar een secundaire/replicaserver.
  • Als de analysetaak al wordt uitgevoerd op een secundair knooppunt en de prestatievermindering onaanvaardbaar is, raden we aan de taken naar een speciaal analysecluster te verplaatsen.

Met onze functie voor volgclusters is het heel eenvoudig om een ​​analysecluster up-to-date te houden met actuele productiegegevens. U kunt een volgschema maken om de nieuwste gegevens uit de productie te synchroniseren net voordat uw analysetaak begint.

Het beste deel? Volgersynchronisatie voert geen bewerkingen op databaseniveau uit - het herstelt alleen de nieuwste momentopname! Er is dus geen enkele impact op uw productiecluster.

3. Rapportage

Een ander veelvoorkomend gebruik waarbij onze klanten de functie voor volgerclusters gebruiken, is het genereren van rapporten. Rapportageprocessen worden doorgaans niet vaak uitgevoerd, maar hebben toegang tot grote hoeveelheden gegevens en nemen de meeste bronnen van een databasecluster in beslag. Als de prestatievermindering onaanvaardbaar is, raden we onze klanten aan de rapportagewerklast naar een nieuw cluster te verplaatsen.

Aangezien rapportagebewerkingen niet vaak voorkomen, geven veel van onze klanten er de voorkeur aan om onze pauze-/hervatfunctie te gebruiken om rapportageclusters te 'pauzeren' wanneer ze niet in gebruik zijn. Dit helpt enorm te besparen op infrastructuurkosten. Doorgaans zijn rapportageclusters ook veel "kleiner" (minder CPU/RAM), om de kosten te helpen verlagen.

Nadat u een volgercluster heeft gemaakt vanuit onze gebruikersinterface, kunt u deze workflow gebruiken om uw rapportagestroom te automatiseren:

  1. Gebruik onze CV API om het cluster te hervatten.
  2. Wacht tot het cluster weer actief is (u kunt hiervoor uw get-status API gebruiken).
  3. Maak indien nodig een back-up op uw productiecluster (meestal, als er regelmatige back-ups zijn gepland voor uw productie, kunt u deze stap overslaan. Als u echter wilt dat uw rapportage op de nieuwste gegevens draait, is dit essentieel).
  4. Wacht tot de back-up is voltooid.
  5. Activeer een synchronisatietaak op de volger - dit vindt de laatste momentopname op het broncluster en herstelt naar de bestemming.
  6. Wacht tot de synchronisatietaak is voltooid.
  7. Voer uw rapportagetaken uit.
  8. Gebruik onze pauze-API om het cluster te pauzeren tot uw volgende rapportagetaak!

Denkt u dat volgersclusters geschikt zijn voor uw specifieke gebruikerscase? U kunt alles leren over het implementeren en beheren van volgerclusters voor MongoDB, MySQL en PostgreSQL in onze helpdocumenten!

Als u niet zeker weet of volgclusters de juiste oplossing zijn voor uw gebruik, laat dan een reactie achter of neem contact met ons op via [email protected] – wij bespreken graag welke functie het beste bij uw wensen past.


  1. Waarom is IS NOT NULL false bij het controleren van een rijtype?

  2. Databasevragen:hoe vind je een naald in een hooiberg?

  3. Verschillen tussen MySql en MySqli in PHP

  4. mysql-updatekolom met waarde uit een andere tabel