{"id":89872,"date":"2020-07-27T01:42:19","date_gmt":"2020-07-26T23:42:19","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza"},"modified":"2020-07-27T01:42:19","modified_gmt":"2020-07-26T23:42:19","slug":"raspredelyonnye-subd-dlya-enterprajza","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/raspredelyonnye-subd-dlya-enterprajza","title":{"rendered":"Fordelte databaser til enterprise","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

CAP-teoremet er en hj\u00f8rnesten i teorien om distribuerede systemer. Diskussionerne omkring den ebber naturligvis ikke ud: definitionerne er ikke kanoniske, og der findes ingen strenge beviser... Ikke desto mindre, idet vi st\u00e5r fast i vores sund fornuft™, forst\u00e5r vi instinktivt, at teoremet er korrekt.<\/p>\n

\"Fordelte
\n
\nDet eneste, der ikke er \u00e5benlyst, er betydningen af bogstavet \"P\". N\u00e5r en klynge deles, beslutter den, om den ikke vil svare, indtil der er opn\u00e5et quorum, eller om den vil give de data, der er tilg\u00e6ngelige. Afh\u00e6ngigt af resultatet af dette valg klassificeres systemet enten som CP eller AP. Cassandra, for eksempel, kan fungere b\u00e5de som det ene og det andet, afh\u00e6ngigt ikke kun af klyngens indstillinger, men ogs\u00e5 af parametrene for hver enkelt foresp\u00f8rgsel. Men hvis systemet ikke er \"P\", og det deler sig, hvad s\u00e5?<\/p>\n

Svaret p\u00e5 dette sp\u00f8rgsm\u00e5l er lidt overraskende: En CA-klynge kan ikke deles.
\nHvad er det s\u00e5 for en klynge, der ikke kan deles?
\n<\/a><\/noindex>
\nEt uundg\u00e5eligt kendetegn ved en s\u00e5dan klynge er et f\u00e6lles datalagringssystem. I de fleste tilf\u00e6lde betyder det tilslutning via SAN, hvilket begr\u00e6nser anvendelsen af CA-l\u00f8sninger til store virksomheder, der er i stand til at vedligeholde en SAN-infrastruktur. For at flere servere<\/a> kan arbejde med de samme data, er en klynge-filsystem n\u00f8dvendig. S\u00e5danne filsystemer findes i portef\u00f8ljerne fra HPE (CFS), Veritas (VxCFS) og IBM (GPFS). <\/p>\n

Oracle RAC<\/h4>\n

\nReal Application Cluster-optionen blev f\u00f8rste gang introduceret i 2001 med udgivelsen af Oracle 9i. I en s\u00e5dan klynge arbejder flere instanser server<\/a> med den samme database.
\nOracle kan arbejde b\u00e5de med et klynge-filsystem og med sin egen l\u00f8sning - ASM, Automatic Storage Management.<\/p>\n

Hver instans f\u00f8rer sin egen log. En transaktion udf\u00f8res og registreres af \u00e9n instans. I tilf\u00e6lde af nedbrud l\u00e6ser en af de overlevende knuder i klyngen (instanserne) dens log og gendanner de tabte data \u2013 p\u00e5 grund af dette sikres tilg\u00e6ngeligheden.<\/p>\n

Alle instanser underst\u00f8tter deres egen cache, og de samme sider (blokke) kan v\u00e6re til stede samtidig i cachen af flere instanser. Mere end det, hvis en instans har brug for en bestemt side, og den findes i cachen af en anden instans, kan den hente den fra \"naboen\" ved hj\u00e6lp af cache fusion-mekanismen i stedet for at l\u00e6se den fra disken.<\/p>\n

\"Fordelte
\n
\nMen hvad sker der, hvis en af instanserne har brug for at \u00e6ndre data?<\/p>\n

Et tr\u00e6k ved Oracle er, at det ikke har en dedikeret l\u00e5neservice: hvis en server \u00f8nsker at l\u00e5se en r\u00e6kke, bliver l\u00e5seoptegnelsen sat direkte p\u00e5 den hukommelsesside, hvor den l\u00e5ste r\u00e6kke befinder sig. Takket v\u00e6re denne tilgang er Oracle en mester i ydeevne blandt monolitiske databaser: l\u00e5neservice bliver aldrig en flaskehals. Men i en klyngekonfiguration kan en s\u00e5dan arkitektur f\u00f8re til intensiv netv\u00e6rkstrafik og gensidige l\u00e5sninger.<\/p>\n

S\u00e5 snart en optegnelse l\u00e5ses, underretter instansen alle andre instanser om, at siden, der indeholder denne optegnelse, er blevet taget i monopoltilstand. Hvis en anden instans har brug for at \u00e6ndre optegnelsen p\u00e5 samme side, skal den vente, indtil \u00e6ndringerne p\u00e5 siden er blevet bekr\u00e6ftet, dvs. informationen om \u00e6ndringen ikke er blevet skrevet til loggen p\u00e5 disken (mens transaktionen kan forts\u00e6tte). Det kan ogs\u00e5 ske, at siden \u00e6ndres sekventielt af flere instanser, og s\u00e5 m\u00e5 man ved skrivning af siden til disken finde ud af, hvem der har den seneste version af denne side.<\/p>\n

Tilf\u00e6ldige opdateringer af de samme sider gennem forskellige RAC-noder f\u00f8rer til et kraftigt fald i databasens ydeevne \u2013 til det punkt, at klyngens ydeevne kan v\u00e6re lavere end ydeevnen for en enkelt instans.<\/p>\n

Korrekt brug af Oracle RAC indeb\u00e6rer en fysisk opdeling af data (f.eks. ved hj\u00e6lp af mekanismen til partitionerede tabeller) og adgangen til hver sektion gennem en dedikeret node. Hovedform\u00e5let med RAC er ikke horisontal skalering, men at sikre fejltolerance.<\/p>\n

Hvis en node holder op med at svare p\u00e5 heartbeat, starter den node, der opdager dette f\u00f8rst, en afstemningsprocedure p\u00e5 disken. Hvis den manglende node heller ikke registreres her, overtager en af noderne ansvaret for at genoprette data:<\/p>\n