PostgreSQL Antipatterns: breyttu gögnum framhjá kveikju

Fyrr eða síðar standa margir frammi fyrir þörfinni að gera stórfelldar breytingar á töflufærslum. Ég hef nú þegar... sagði mér hvernig ég ætti að gera þetta betur, en það er betra að gera það ekki þannig. Í dag ætla ég að tala um annan þátt fjöldauppfærslunnar— um að kveikja.

Til dæmis hangir illkvittnisleg kveikja á borðinu þar sem þú þarft að leiðrétta eitthvað. ON UPDATE, sem flytur allar breytingar yfir á ákveðnar samantektir. Og þú þarft að uppfæra allt (til dæmis frumstilla nýjan reit) svo vandlega að þessar samantektir verði ekki fyrir áhrifum.

Slökkvum bara á kveikjunum!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
  UPDATE ...; -- тут долго-долго
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

Það er í raun allt og sumt. allt er nú þegar að hanga.

Vegna ALTER TABLE leggur á Aðgangur eingöngu- lás sem enginn keyrir samsíða undir, jafnvel einföld lás SELECT, mun ekki geta lesið neitt úr töflunni. Þetta þýðir að þangað til þessari færslu er lokið, þá þurfa allir sem vilja „bara lesa“ að bíða. Og við höfum í huga að UPDATE við höfum laaaangt...

Slökkvum fljótt á því og kveikjum svo fljótt á því!

BEGIN;
  ALTER TABLE ... DISABLE TRIGGER ...;
COMMIT;

UPDATE ...;

BEGIN;
  ALTER TABLE ... ENABLE TRIGGER ...;
COMMIT;

Ástandið er nú þegar betra hér, biðtíminn er mun styttri. En aðeins tvö vandamál spilla fegurðinni:

• ALTER TABLE bíður eftir öllum öðrum aðgerðum á borðinu, þar á meðal löngum aðgerðum SELECT
• Meðan kveikjan er slökkt, allar breytingar munu líða hjá Í töflunni er það ekki einu sinni okkar. Og það kemst bara ekki í samanlagða töluna, jafnvel þótt það ætti að gera það. Þvílík hörmung!

Stjórnun lotubreyta

Í fyrri útgáfunni rákumst við á lykilatriði: við þurfum einhvern veginn að kenna kveikjunni að greina á milli breytinga sem eru „okkar“ í töflunni og breytinga sem eru „ekki okkar“. Hún ætti að sleppa „okkar“ eins og hún er og virkjast við „ekki okkar“. Til þess getum við notað lotubreytur.

hlutverk_afritunar_lotu

Við skulum lesa handbók:

Stillingarbreytan hefur einnig áhrif á kveikjukerfið hlutverk_afritunar_lotuKveikjur sem eru virkjaðar án frekari tilgreininga (sjálfgefið) munu virkjast þegar afritunarhlutverkið er „uppruni“ (sjálfgefið) eða „staðbundið“. Kveikjur sem eru virkjaðar með því að tilgreina ENABLE REPLICA, mun aðeins virka ef núverandi lotuhamur — „afrit“ og kveikjur virkjaðar með því að tilgreina ENABLE ALWAYS, verður virkjað óháð núverandi afritunarstillingu.

Ég vil sérstaklega leggja áherslu á að stillingin á ekki við um alla í einu, þar sem ALTER TABLE, en aðeins við okkar sérstaka tengingu. Til að koma í veg fyrir að forritavirkjar verði virkjaðir:

SET session_replication_role = replica; -- выключили триггеры
UPDATE ...;
SET session_replication_role = DEFAULT; -- вернули в исходное состояние

Ástand inni í kveikjunni

En valkosturinn hér að ofan virkar fyrir alla kveikjur í einu (eða við þurfum að „breyta“ þeim kveikjum sem við viljum ekki slökkva á fyrirfram). Og ef við þurfum „slökkva á“ einum ákveðnum kveikju?

Þetta mun hjálpa okkur „notandi“ lotubreyta:

Nöfn viðbótabreyta eru rituð á eftirfarandi hátt: viðbótarnafnið, punktur og síðan breytunafnið sjálft, svipað og fullgild hlutanöfn í SQL. Til dæmis: plpgsql.variable_conflict.
Þar sem hægt er að stilla breytur sem ekki eru kerfisbreytur í ferlum sem hlaða ekki inn samsvarandi viðbótareiningu, þá samþykkir PostgreSQL gildi fyrir öll nöfn með tveimur íhlutum.

Fyrst breytum við kveikjunni, eitthvað á þessa leið:

BEGIN
    -- процессу конвертации можно делать все
    IF current_setting('mycfg.my_table_convert_process') = 'TRUE' THEN
        IF TG_OP IN ('INSERT', 'UPDATE') THEN
            RETURN NEW;
        ELSE
            RETURN OLD;
        END IF;
    END IF;
...

Með því sagt, þetta er hægt að gera „í beinni“ án þess að blokka, í gegnum CREATE OR REPLACE fyrir kveikjufallið. Og svo í sérstöku tengingunni setjum við upp breytuna „okkar“:

SET mycfg.my_table_convert_process = 'TRUE';
UPDATE ...;
SET mycfg.my_table_convert_process = ''; -- вернули в исходное состояние

Veistu um aðrar aðferðir? Deildu þeim í athugasemdunum.

Heimild: www.habr.com