slon - Online in de cloud

PROGRAMMA:

NAAM

slon - Slony-I-daemon

KORTE INHOUD

slon [optie]... [clusternaam] [conninfo]

PRODUCTBESCHRIJVING

slon is de daemon-toepassing die Slony-I-replicatie 'draait'. Een slon-instantie moet zijn
uitvoeren voor elk knooppunt in een Slony-I-cluster.

OPTIES

-d Log niveau
De Log niveau specificeert welke niveaus van foutopsporingsberichten slon moet weergeven wanneer:
zijn activiteit loggen.

De negen niveaus van loggen zijn:

· Fataal

· Fout

· Waarschuwen

· Configuratie

· Informatie

· Foutopsporing1

· Foutopsporing2

· Foutopsporing3

· Foutopsporing4

De eerste vijf niet-foutopsporingslogniveaus (van Fatal tot Info) zijn: altijd weergegeven in de
logboeken. In vroege versies van Slony-I was de 'aanbevolen' Log niveau waarde was 2, wat zou?
lijstuitvoer op alle niveaus tot foutopsporingsniveau 2. In Slony-I versie 2 is het:
aanbevolen om in te stellen Log niveau naar 0; de meeste constant interessante loginformatie is:
gegenereerd op niveaus hoger dan dat.

-s SYNC controle interval
De synchronisatie-interval, gemeten in milliseconden, geeft aan hoe vaak slon moet controleren
om te zien of een SYNC geïntroduceerd moeten worden. Standaard is 2000 ms. De hoofdlus in
sync_Thread_main() slaapt met tussenpozen van synchronisatie-interval milliseconden tussen
iteraties.

Korte synchronisatiecontrole-intervallen houden de oorsprong aan een 'korte lijn', waardoor de
abonnees vaker. Als u herhaalde sequenties heeft die vaak voorkomen
bijgewerkt zonder er zijn tabellen die worden beïnvloed, dit zorgt ervoor dat er geen is
tijden waarop alleen sequenties worden bijgewerkt, en daarom geen synchronisaties vinden plaats

Als het knooppunt geen oorsprong is voor een replicatieset, dus er komen geen updates binnen,
het is enigszins verkwistend dat deze waarde veel lager is dan de sync_interval_timeout
waarde.

-t SYNC interval time-out
Aan het einde van elk sync_interval_timeout time-out periode, a SYNC wordt gegenereerd
op het 'lokale' knooppunt, zelfs als er geen repliceerbare gegevens zijn bijgewerkt die zouden
hebben veroorzaakt SYNC te genereren.

Als de applicatie-activiteit stopt, hetzij omdat de applicatie is afgesloten, of
omdat menselijke gebruikers naar huis zijn gegaan en zijn gestopt met het introduceren van updates, slon(1)
zal herhalen, elke keer wakker worden synchronisatie-interval milliseconden, en, aangezien er geen updates zijn
worden gemaakt, nee SYNC gebeurtenissen zouden ontstaan. Zonder deze time-outparameter,
geen SYNC gebeurtenissen zouden worden gegenereerd, en het lijkt erop dat de replicatie viel
achter.

De sync_interval_timeout waarde zal uiteindelijk leiden tot het genereren van a SYNCZelfs
hoewel er geen echt replicatiewerk moest worden gedaan. Hoe lager deze parameter
is ingesteld, hoe vaker slon(1) zal genereren SYNC gebeurtenissen wanneer de toepassing
genereert geen repliceerbare activiteit; dit heeft twee effecten:

· Het systeem zal meer replicatiewerk doen.

(Natuurlijk, aangezien er geen applicatiebelasting op de database is en er geen gegevens zijn om
repliceren, zal deze belasting heel gemakkelijk te hanteren zijn.

· Replicatie lijkt meer 'up-to-date' te worden gehouden.

(Natuurlijk, aangezien er geen repliceerbare activiteit gaande is, is het 'beter zijn'
date' is iets van een luchtspiegeling.)

De standaardwaarde is 10000 ms en het maximum is 120000 ms. Standaard kunt u van elk knooppunt verwachten dat:
'meld je aan' met een SYNC elke 10 seconden.

Merk op dat SYNC gebeurtenissen worden ook gegenereerd op abonneeknooppunten. Aangezien ze eigenlijk niet zijn
het genereren van gegevens om te repliceren naar andere knooppunten, deze SYNC evenementen zijn niet erg
veel waarde.

-g groep lengte van de duwkabel
Dit regelt het maximum SYNC groepsgrootte, sync_group_maxsize; standaard ingesteld op 6. Dus,
als een bepaald knooppunt 200 . achter ligt SYNCs, het zal proberen ze samen te groeperen
in groepen van maximaal sync_group_maxsize. Dit zal naar verwachting afnemen
transactieoverhead door minder transacties te hebben COMMIT.

De standaardwaarde van 6 is waarschijnlijk geschikt voor kleine systemen die slechts zeer
beperkte stukjes geheugen voor slon. Als je genoeg geheugen hebt, zou het zijn
redelijk is om dit te verhogen, omdat het de hoeveelheid werk die in elk wordt gedaan zal vergroten
transactie, en zal een abonnee die veel achterstand heeft in staat stellen meer in te halen
snel.

Slon-processen blijven meestal vrij klein; zelfs met een grote waarde voor deze optie,
slon zou naar verwachting slechts enkele MB's groot worden.

Het grote voordeel bij het verhogen van deze parameter komt van het verminderen van de
aantal transacties COMMITs; het verplaatsen van 1 naar 2 zal aanzienlijk opleveren
voordeel, maar de voordelen zullen geleidelijk afnemen zodra de transacties
verwerkt redelijk groot worden. Er is waarschijnlijk geen materiaal
verschil in prestatie tussen 80 en 90; op dat moment, of 'groter is'
beter' zal afhangen van de vraag of de grotere set van SYNCs maakt de LOG cursor gedraagt ​​zich
slecht omdat het meer geheugen verbruikt en meer tijd nodig heeft om te sorteren.

In Slony-I versie 1.0 zal slon altijd proberen te groeperen SYNCs samen om dit
maximaal, die zal niet ideaal zijn als de replicatie enigszins is gedestabiliseerd door
er zijn zeer grote updates (bv - een enkele transactie die honderden bijwerkt
van duizenden rijen) of door SYNCs wordt verstoord op een oorsprongsknooppunt met als resultaat
dat er een paar zijn SYNCs die erg groot zijn. U kunt het probleem tegenkomen dat:
groepering van een aantal zeer grote SYNCs slaat een slon-proces om. Wanneer het pakt
weer op, zal het proberen om dezelfde grote gegroepeerde set van . te verwerken SYNCs, en loop tegen
hetzelfde probleem keer op keer totdat een beheerder dit onderbreekt en verandert
the -g waarde om deze 'impasse' te doorbreken.

In Slony-I versie 1.1 en latere versies 'loopt de slon adaptief op'
van het doen van 1 SYNC tegelijk richting de maximale groepsgrootte. Als gevolg hiervan, als er
zijn een paar SYNCs die problemen veroorzaken, zal de slon (met eventuele relevante
waakhondassistentie) altijd in staat zijn om het punt te bereiken waarop het de
lastig SYNCs één voor één, waardoor assistentie van de operator hopelijk overbodig wordt.

-o gewenste sync Time to
Een 'maximale' tijd gepland voor gegroepeerd SYNCs.

Als de replicatie achterloopt, zal slon het aantal SYNCs
gegroepeerd, gericht op dat (op basis van de tijd die nodig is voor de laatste groep van
SYNCs) ze mogen niet meer nemen dan de gespecificeerde gewenste_synchronisatietijd waarde.

De standaardwaarde voor gewenste_synchronisatietijd is 60000 ms, gelijk aan één minuut.

Op die manier kun je verwachten (of in ieder geval hopen!) dat je een COMMIT ongeveer een keer
per minuut.

Dat is het niet helemaal voorspelbaar, aangezien het heel goed mogelijk is voor iemand om een
zeer Grote werken, allemaal als één transactie, die de lengte van de kan 'opblazen'
verkregen SYNC bijna willekeurig lang zijn. In een dergelijk geval zal de heuristische wil
terug uit voor de volgende groep.

Het algehele effect is dat Slony-I beter in staat is om te gaan met variaties in
verkeer. Door te beginnen met 1 SYNC, en geleidelijk naar meer, zelfs als er een ommekeer is
variaties zijn die groot genoeg zijn om PostgreSQL-backends te laten crashen, Slony-I
gaat terug naar beneden om met één synchronisatie per keer te beginnen, indien nodig, zodat als het is
als het maar enigszins mogelijk is om de replicatie te laten vorderen, zal dat ook gebeuren.

-c schoonmaken cycli
De waarde vac_frequentie geeft aan hoe vaak u VACUÜM in opruimcycli.

Stel dit in op nul om slon-geïnitieerd stofzuigen uit te schakelen. Als je iets gebruikt
zoals pg_autovacuum om stofzuigers te starten, heb je misschien geen slon nodig om te starten
zelf stofzuigt. Als u dat niet bent, zijn er enkele tabellen die Slony-I gebruikt die een
lot van dode tuples die vaak moeten worden gestofzuigd, met name: pg_luisteraar.

In Slony-I versie 1.1 verandert dit een beetje; de opruimthread-tracks, van
iteratie naar iteratie, de vroegste transactie-ID die nog actief is in het systeem. Indien
dit verandert niet, van de ene iteratie naar de andere, dan is een oude transactie
nog steeds actief, en daarom a VACUÜM zal geen goed doen. De opruimthread in plaats daarvan
doet alleen maar ANALYSE op deze tabellen om de statistieken bij te werken in pg_statistieken.

-p PID bestandsnaam
pid_bestand bevat de bestandsnaam waarin de PID (proces-ID) van de slon is opgeslagen.

Dit kan het gemakkelijker maken om scripts te construeren om meerdere slon-processen te monitoren
draait op een enkele host.

-f config filet
Bestand waaruit de slon-configuratie moet worden gelezen.

Deze configuratie wordt verder besproken in Slon Runtime-configuratie [“Run-time
Configuratie” [niet beschikbaar als man-pagina]]. Als er een complexe set van
configuratieparameters, of als er parameters zijn die u niet zichtbaar wilt hebben
in de procesomgevingsvariabelen (zoals wachtwoorden), kan het handig zijn om:
teken veel of alle parameters uit een configuratiebestand. Je zou ofwel common . kunnen zetten
parameters voor alle slon-processen in een veelgebruikt configuratiebestand, waardoor:
de opdrachtregel om weinig anders op te geven dan de verbindingsinformatie. Alternatief,
u kunt voor elk knooppunt een configuratiebestand maken.

-a archief directory
archief_dir geeft een map aan waarin een reeks van moet worden geplaatst SYNC archief
bestanden voor gebruik in log verzending [“Log Shipping - Slony-I with Files” [niet beschikbaar
als een man-pagina]] modus.

-x commando naar lopen on inloggen archief
command_on_logarchive geeft een opdracht aan die moet worden uitgevoerd telkens wanneer een SYNC-bestand wordt uitgevoerd
succesvol gegenereerd.

Zie meer details over "slon_conf_command_on_log_archive" [niet beschikbaar als man
bladzijde].

-q ophouden gebaseerde on SYNC leverancier
quit_sync_provider geeft aan in welke provider's werkthread moet worden gekeken
om te beëindigen na een bepaalde gebeurtenis. Dit moet worden gebruikt in combinatie met de
-r optie hieronder...

Hierdoor kun je een slon laten stoppen met repliceren na een bepaald punt.

-r ophouden at gebeurtenis aantal
quit_sync_finalsync geeft het gebeurtenisnummer aan waarna de thread van de externe werknemer
voor bovenstaande aanbieder dient te beëindigen. Dit moet worden gebruikt in combinatie met de
-q optie hierboven...

-l achterblijven interval
lag_interval geeft een intervalwaarde aan zoals 3 minuten or 4 uur or 2 dagen
dat geeft aan dat dit knooppunt zijn providers zal achterlopen met het gespecificeerde interval van
tijd. Dit zorgt ervoor dat gebeurtenissen worden genegeerd totdat ze de leeftijd hebben bereikt die overeenkomt met:
het interval.
waarschuwing

Er is een bijkomend nadeel aan deze vertraging; gebeurtenissen waarvoor alle knooppunten moeten
synchroniseren, zoals gewoonlijk gebeurt met SLONIK FAIL-OVER(7) en SLONIK MOVE SET(7)
zal moeten wachten op dit achterblijvende knooppunt.

Dat is misschien niet ideaal gedrag tijdens een failover-tijd, of op het moment dat u dat wilt
lopen SLONIK UITVOEREN SCRIPT(7).

EXIT STATUS

slon retourneert 0 naar de shell als het normaal is geëindigd. Het keert terug via uitgang(-1) (welke zal
waarschijnlijk een retourwaarde van 127 of 255 geven, afhankelijk van uw systeem) als het
een fatale fout tegenkomt.

Gebruik slon online met onworks.net-services