ClickHouse "Table is in readonly mode": cēloņi un kā to salabot

Datu ielādes konveijers sāk krist, paneļi joprojām atveras, un žurnālos redzams "Table is in readonly mode". ClickHouse tas gandrīz vienmēr attiecas uz ReplicatedMergeTree tabulu un nozīmē, ka replika ir zaudējusi savienojumu ar koordinācijas servisu (ClickHouse Keeper vai ZooKeeper) vai nevar tur atrast savus metadatus. Dati diskā parasti ir kārtībā. Uzdevums ir saprast, kurš no diviem gadījumiem jums ir, jo labojums atšķiras.

Code: 242. DB::Exception: Table is in readonly mode
(replica path: /clickhouse/tables/01/events/replicas/ch1). (TABLE_IS_READ_ONLY)

Ko šeit nozīmē "tikai lasāms"

Kļūdas kods ir 242, TABLE_IS_READ_ONLY, kā norādīts ClickHouse kļūdu kodos. Replicētai tabulai Keeper vajadzīgs visam, kas maina kopīgo stāvokli: ievietošanai, apvienošanai (merge), mutācijām, ALTER un replikācijas rindai. Glabāšanas dzinēja pirmkods met šo pašu kļūdu, ja tikai lasīšanas režīmā tas nevar atjaunināt rindu, piešķirt apvienošanu vai pabeigt mutācijas.

Ar lasīšanu ir citādi. Replikācijas dokumentācijā teikts, ka ZooKeeper netiek izmantots SELECT vaicājumos, tāpēc vaicājumi uz tabulu turpina strādāt. Tāpēc šis incidents bieži izskatās kā "ievietošana salūzusi, viss pārējais šķiet kārtībā". Ņemiet vērā, ka šajā stāvoklī replika vairs nesaņem jaunus datus no citām replikām, tāpēc rezultāti tajā var novecot.

Kāpēc replika kļūst tikai lasāma

Saskaņā ar system.replicas dokumentāciju tikai lasīšanas režīms ieslēdzas, ja konfigurācijā nav Keeper sadaļas, ja Keeper sesijas atkārtotas inicializācijas laikā rodas nezināma kļūda, un pašas sesijas atkārtotas inicializācijas laikā. Pirmkods pievieno vēl divas situācijas: pēc servera starta tabula paliek tikai lasāma, līdz beidzas tās inicializācija, un tabula, kuras metadati Keeper nav atrasti, arī ir tikai lasāma. Praksē tas dod četrus cēloņus:

1. Keeper nedarbojas vai ir zaudējis kvorumu. Katra replicētā tabula katrā serverī, kas to izmanto, kļūst tikai lasāma aptuveni vienlaikus.
2. Sesija beigusies. Tipiski izraisītāji ir tīkla problēmas vai pārslogots vai iestrēdzis Keeper vai ClickHouse serveris, kas var likt sesijai beigties. Tad ClickHouse to inicializē no jauna, un tikmēr tabulas ir tikai lasāmas.
3. Metadati Keeper ir pazuduši. Kāds izdzēsa ceļu, Keeper tika pārbūvēts no nulles vai tabula norāda uz ceļu, kas nekad nav pastāvējis. Dokumentācijā ir klasisks piemērs: ja Keeper ceļš izmanto makro {table} un jūs pārdēvējat tabulu, makro izvēršas citā ceļā, kas neeksistē, un tabula kļūst tikai lasāma.
4. Konfigurācijā nav Keeper. Pēc konfigurācijas maiņas vai jaunizveidotā serverī esošās replicētās tabulas būs tikai lasāmas, un jaunas izveidot nevarēs.

1. solis: kuras tabulas un kopš kura laika

SELECT database, table, is_readonly, readonly_start_time,
       is_session_expired, active_replicas, total_replicas,
       zookeeper_exception
FROM system.replicas
WHERE is_readonly
ORDER BY readonly_start_time;

readonly_start_time parāda, kad tas sākās; salīdziniet to ar Keeper un tīkla notikumiem. zookeeper_exception satur pēdējo kļūdu no Keeper un bieži ir ātrākā norāde uz cēloni. is_session_expired dokumentācijas vārdiem ir "basically the same as is_readonly", tāpēc pārāk daudz no tā nesecinieties. Arī kļūdas ziņojums var to pateikt tieši: "Table is in readonly mode since table metadata was not found in zookeeper" nozīmē 3. gadījumu.

Noderīga ir arī aina kopumā. Ja katra replicētā tabula katrā serverī kļuva tikai lasāma tajā pašā minūtē, vaina ir Keeper (1. gadījums). Ja skarts viens serveris, skatieties šī servera savienojumu (2. gadījums). Ja skarta viena tabula un pārējās ir kārtībā, turiet aizdomās tās metadatus vai ceļu (3. gadījums).

2. solis: pārbaudiet savienojumu ar Keeper

SELECT name, host, port, connected_time,
       session_uptime_elapsed_seconds, is_expired
FROM system.zookeeper_connection;

SELECT value FROM system.metrics WHERE metric = 'ReadonlyReplica';

system.zookeeper_connection parāda, ar kuru Keeper mezglu šis serveris ir savienots, kopš kura laika un vai savienojums ir beidzies. Metrika ReadonlyReplica ir to replicēto tabulu skaits, kas pašlaik ir tikai lasāmas atkārtotas inicializācijas dēļ pēc sesijas zuduma vai starta bez konfigurēta Keeper. Tieši par šo skaitli ir vērts iestatīt brīdinājumu.

Tad pajautājiet pašam Keeper, izmantojot četru burtu komandas tā klienta portā (Keeper piemēros pēc noklusējuma 9181):

echo ruok | nc keeper1 9181          # imok = process darbojas (nav kvoruma pierādījums)
echo mntr | nc keeper1 9181 | grep zk_server_state   # leader / follower
echo isro | nc keeper1 9181          # rw vai ro

Viens dokumentēts slazds: imok no ruok nozīmē tikai to, ka process darbojas un klausās. Tas nenozīmē, ka mezgls ir pievienojies kvorumam. Pārbaudiet zk_server_state izvadē mntr: veselā ansamblī ir tieši viens leader, pārējie ir follower.

A risinājums: Keeper atkal darbojas, tabula joprojām tikai lasāma

Kad Keeper ir vesels, replikas parasti pašas inicializē sesijas no jauna, un ReadonlyReplica atgriežas pie nulles. Ja tabula paliek tikai lasāma, inicializējiet to ar roku:

SYSTEM RESTART REPLICA analytics.events;
-- vai visām replicētajām tabulām šajā serverī
SYSTEM RESTART REPLICAS;

SYSTEM komandu dokumentācijā SYSTEM RESTART REPLICA aprakstīts kā tabulas Keeper sesijas stāvokļa atkārtota inicializācija: tas salīdzina lokālo stāvokli ar Keeper kā patiesības avotu un, ja vajag, pievieno uzdevumus rindai, tāpat kā pie ATTACH TABLE. Uz īsu brīdi tabula nav pieejama nevienai operācijai, tāpēc noslogotā serverī dariet to tabulu pa tabulai, nevis ar RESTART REPLICAS pašā slodzes maksimumā.

B risinājums: metadati Keeper ir zaudēti

Ja replikas vai visas tabulas ceļš Keeper vairs neeksistē, restartēšana nepalīdzēs: replikai nav, kur pieslēgties. Šim gadījumam ClickHouse ir SYSTEM RESTORE REPLICA:

SYSTEM RESTART REPLICA analytics.events;
SYSTEM RESTORE REPLICA analytics.events;
-- izpildiet katrā replikā vai:
SYSTEM RESTORE REPLICA analytics.events ON CLUSTER main;

Ko par to saka dokumentācija:

• Tā darbojas tikai uz tikai lasāmām ReplicatedMergeTree tabulām un ir paredzēta Keeper saknes, /replicas ceļa vai vienas replikas ceļa zudumam.
• Replika pievieno lokāli atrastās daļas (parts) un nosūta informāciju par tām uz Keeper. Daļas, kas bija pirms zuduma, netiek atkārtoti lejupielādētas no citām replikām, ja vien tās nav novecojušas, tāpēc atjaunošana nenozīmē visu datu lejupielādi tīklā.
• Visu stāvokļu daļas tiek pārvietotas uz mapi detached/, un daļas, kas pirms zuduma bija aktīvas, tiek pievienotas atpakaļ.
• Dokumentētajā piemērā komanda tiek izpildīta katrā replikā vai vienreiz ar ON CLUSTER.

Ja cēlonis bija pārdēvēta tabula ar makro {table} ceļā, tīrāks risinājums var būt pārdēvēt to atpakaļ, lai tabula atkal norādītu uz savu sākotnējo, neskarto ceļu. Pirms kaut ko atjaunojat, pārbaudiet, kas Keeper eksistē.

Kā novērst nākamo reizi

• Darbiniet Keeper kā pilnvērtīgu ansambli: trīs vai pieci mezgli uz saviem diskiem, nevis kopā ar ClickHouse serveri, kas aizņemts ar smagām apvienošanām. Monitorējiet mntr izvadi (vai ir leader, latentums, neapstrādātie pieprasījumi).
• Iestatiet brīdinājumu, ja ReadonlyReplica ir virs nulles ilgāk par minūti vai divām. Tas noķer visus četrus cēloņus, parasti pirms datu ielādes komanda to pamana.
• Uztveriet Keeper ceļus kā daļu no shēmas. Esiet uzmanīgi ar pārdēvēšanu, ja ceļā ir makro {table} vai {database}, un nekad nedzēsiet ceļus Keeper ar roku darbojošā klasterī.
• Turiet rakstīšanas slodzi saprātīgu. Katrs ievietošanas bloks izveido ierakstus Keeper; replikācijas dokumentācija lēš ap desmit uz bloku. Milzīgs skaits sīku ievietojumu noslogo gan Keeper, gan apvienošanas procesu; mūsu raksts par "Too many parts" skaidro, kā tos apvienot partijās.
• Sekojiet līdzi arī atmiņai ClickHouse pusē. Serveris lielā atmiņas spiedienā var iestrēgt pietiekami ilgi, lai palaistu garām Keeper sirdspukstus; skatiet mūsu ceļvedi par "Memory limit exceeded", lai uzzinātu, kādus limitus iestatīt.