Við kynnum Debezium - CDC fyrir Apache Kafka

Í starfi mínu rekst ég oft á nýjar tæknilausnir / hugbúnaðarvörur, upplýsingar um þær eru frekar af skornum skammti á rússneskumælandi interneti. Með þessari grein mun ég reyna að fylla eitt slíkt skarð með dæmi frá nýlegri æfingu minni, þegar ég þurfti að setja upp sendingu CDC viðburði frá tveimur vinsælum DBMS (PostgreSQL og MongoDB) í Kafka þyrping með Debezium. Ég vona að þessi yfirlitsgrein, sem birtist í kjölfar vinnunnar, nýtist öðrum.

Hvað er Debezium og CDC almennt?

Debezium - Fulltrúi CDC hugbúnaðarflokks (Handtaka gagnabreyting), eða nánar tiltekið, það er sett af tengjum fyrir ýmis DBMS sem eru samhæf við Apache Kafka Connect ramma.

Það opinn uppspretta verkefni, leyfi samkvæmt Apache leyfi v2.0 og styrkt af Red Hat. Þróun hefur verið í gangi síðan 2016 og í augnablikinu veitir hún opinberan stuðning fyrir eftirfarandi DBMS: MySQL, PostgreSQL, MongoDB, SQL Server. Það eru líka tengi fyrir Cassandra og Oracle, en þau eru eins og er í "early access" stöðu og nýjar útgáfur tryggja ekki afturábak eindrægni.

Ef við berum CDC saman við hefðbundna nálgun (þegar forritið les gögn beint úr DBMS), þá eru helstu kostir þess meðal annars útfærsla á streymi gagnabreytinga á röð stigi með lítilli leynd, mikilli áreiðanleika og aðgengi. Síðustu tvö stigin eru náð með því að nota Kafka þyrping sem geymslu fyrir CDC atburði.

Kostirnir fela einnig í sér þá staðreynd að eitt líkan er notað til að geyma atburði, svo lokaforritið þarf ekki að hafa áhyggjur af blæbrigðum þess að reka mismunandi DBMS.

Að lokum, með því að nota skilaboðamiðlara, opnast svigrúm fyrir lárétta mælikvarða á forritum sem fylgjast með breytingum á gögnum. Á sama tíma er áhrifin á gagnagjafann lágmarkað, þar sem gögn berast ekki beint frá DBMS, heldur frá Kafka klasanum.

Um Debezium arkitektúrinn

Notkun Debezium kemur niður á þessu einfalda kerfi:

DBMS (sem gagnagjafi) → tengi í Kafka Connect → Apache Kafka → neytandi

Til skýringar mun ég gefa skýringarmynd af vefsíðu verkefnisins:

Hins vegar líkar mér ekki við þetta kerfi, því það virðist sem aðeins vaskatengi sé mögulegt.

Í raun og veru er staðan önnur: að fylla Data Lake þitt (síðasti hlekkur á skýringarmyndinni hér að ofan) er ekki eina leiðin til að nota Debezium. Viðburðir sem sendir eru til Apache Kafka geta verið notaðir af forritum þínum til að takast á við ýmsar aðstæður. Til dæmis:

• fjarlæging óviðkomandi gagna úr skyndiminni;
• senda tilkynningar;
• leitarvísitöluuppfærslur;
• einhvers konar endurskoðunarskrár;
• ...

Ef þú ert með Java forrit og það er engin þörf/möguleiki að nota Kafka klasa, þá er líka möguleiki á að vinna í gegnum innbyggð tengi. Augljósi plúsinn er að með því geturðu hafnað viðbótarinnviðum (í formi tengis og Kafka). Hins vegar hefur þessi lausn verið úrelt síðan útgáfa 1.1 og er ekki lengur mælt með notkun hennar (hún gæti verið fjarlægð í framtíðarútgáfum).

Þessi grein mun fjalla um arkitektúrinn sem forritarar mæla með, sem veitir bilanaþol og sveigjanleika.

Tengistillingar

Til þess að byrja að fylgjast með breytingum á mikilvægustu gildinu - gögnum - þurfum við:

1. gagnagjafi, sem getur verið MySQL frá útgáfu 5.7, PostgreSQL 9.6+, MongoDB 3.2+ (fullur listi);
2. Apache Kafka þyrping
3. Kafka Connect tilvik (útgáfur 1.x, 2.x);
4. stillt Debezium tengi.

Unnið er með fyrstu tvo punktana, þ.e. ferlið við að setja upp DBMS og Apache Kafka eru utan gildissviðs greinarinnar. Hins vegar, fyrir þá sem vilja dreifa öllu í sandkassa, þá er tilbúinn í opinberu geymslunni með dæmum docker-compose.yaml.

Við munum einbeita okkur að síðustu tveimur atriðum nánar.

0. Kafka Connect

Hér og síðar í greininni eru öll stillingardæmi skoðuð í samhengi við Docker myndina sem Debezium hönnuðir dreifa. Það inniheldur allar nauðsynlegar viðbætur (tengi) og veitir Kafka Connect stillingar með því að nota umhverfisbreytur.

Ef þú ætlar að nota Kafka Connect frá Confluent þarftu sjálfur að bæta viðbótum nauðsynlegra tengiliða við möppuna sem tilgreind er í plugin.path eða stillt í gegnum umhverfisbreytu CLASSPATH. Stillingarnar fyrir Kafka Connect starfsmanninn og tengin eru skilgreindar í gegnum stillingarskrár sem eru sendar sem rök fyrir byrjunarskipun starfsmanns. Sjá nánar skjöl.

Allt ferlið við að setja upp Debeizum í tengiútgáfunni er framkvæmt í tveimur áföngum. Við skulum íhuga hvert þeirra:

1. Uppsetning Kafka Connect ramma

Til að streyma gögnum í Apache Kafka klasa eru sérstakar færibreytur stilltar í Kafka Connect rammanum, svo sem:

• tengingarstillingar fyrir klasa,
• nöfn efnis þar sem uppsetning tengisins sjálfs verður geymd,
• nafn hópsins sem tengið er í gangi (ef notaður er dreifður hamur).

Opinbera Docker mynd verkefnisins styður stillingar með því að nota umhverfisbreytur - þetta er það sem við munum nota. Svo skulum við hlaða niður myndinni:

docker pull debezium/connect

Lágmarks mengi umhverfisbreyta sem þarf til að keyra tengið er sem hér segir:

• BOOTSTRAP_SERVERS=kafka-1:9092,kafka-2:9092,kafka-3:9092 - upphaflegur listi yfir Kafka klasaþjóna til að fá heildarlista yfir klasameðlimi;
• OFFSET_STORAGE_TOPIC=connector-offsets — efni til að geyma staðsetningar þar sem tengið er nú staðsett;
• CONNECT_STATUS_STORAGE_TOPIC=connector-status - efni til að geyma stöðu tengisins og verkefni þess;
• CONFIG_STORAGE_TOPIC=connector-config - efni til að geyma tengistillingargögn og verkefni þess;
• GROUP_ID=1 — auðkenni hóps starfsmanna sem hægt er að framkvæma tengiverkið á; krafist þegar dreift er notað (dreift) stjórn.

Við byrjum ílátið með þessum breytum:

docker run 
  -e BOOTSTRAP_SERVERS='kafka-1:9092,kafka-2:9092,kafka-3:9092' 
  -e GROUP_ID=1 
  -e CONFIG_STORAGE_TOPIC=my_connect_configs 
  -e OFFSET_STORAGE_TOPIC=my_connect_offsets 
  -e STATUS_STORAGE_TOPIC=my_connect_statuses  debezium/connect:1.2

Athugasemd um Avro

Sjálfgefið er að Debezium skrifar gögn á JSON sniði, sem er ásættanlegt fyrir sandkassa og lítið magn af gögnum, en getur verið vandamál í mikið hlaðnum gagnagrunnum. Annar valkostur við JSON breytirinn er að raðgreina skilaboð með því að nota evru í tvíundarsnið, sem dregur úr álagi á I/O undirkerfið í Apache Kafka.

Til að nota Avro þarftu að dreifa sér skema-skrá (til að geyma skemas). Breyturnar fyrir breytirinn munu líta svona út:

name: CONNECT_VALUE_CONVERTER_SCHEMA_REGISTRY_URL
value: http://kafka-registry-01:8081/
name: CONNECT_KEY_CONVERTER_SCHEMA_REGISTRY_URL
value: http://kafka-registry-01:8081/
name: VALUE_CONVERTER   
value: io.confluent.connect.avro.AvroConverter

Upplýsingar um notkun Avro og uppsetningu skrásetningar fyrir það eru utan gildissviðs greinarinnar - frekar, til glöggvunar, munum við nota JSON.

2. Uppsetning á tenginu sjálfu

Nú geturðu farið beint í uppsetningu tengisins sjálfs, sem mun lesa gögn frá upprunanum.

Við skulum skoða dæmið um tengi fyrir tvö DBMS: PostgreSQL og MongoDB, sem ég hef reynslu af og þar er munur á (að vísu lítill, en í sumum tilfellum verulegur!).

Stillingunni er lýst í JSON nótunum og hlaðið upp á Kafka Connect með POST beiðni.

2.1. PostgreSQL

Dæmi um tengistillingu fyrir PostgreSQL:

{
  "name": "pg-connector",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "plugin.name": "pgoutput",
    "database.hostname": "127.0.0.1",
    "database.port": "5432",
    "database.user": "debezium",
    "database.password": "definitelynotpassword",
    "database.dbname" : "dbname",
    "database.server.name": "pg-dev",
    "table.include.list": "public.(.*)",
    "heartbeat.interval.ms": "5000",
    "slot.name": "dbname_debezium",
    "publication.name": "dbname_publication",
    "transforms": "AddPrefix",
    "transforms.AddPrefix.type": "org.apache.kafka.connect.transforms.RegexRouter",
    "transforms.AddPrefix.regex": "pg-dev.public.(.*)",
    "transforms.AddPrefix.replacement": "data.cdc.dbname"
  }
}

Meginreglan um notkun tengisins eftir þessa stillingu er frekar einföld:

• Við fyrstu ræsingu tengist það gagnagrunninum sem tilgreint er í stillingunum og byrjar í ham fyrstu skyndimynd, að senda til Kafka upphafssett af gögnum sem berast með skilyrt SELECT * FROM table_name.
• Eftir að frumstillingunni er lokið fer tengið í stillingu til að lesa breytingar úr PostgreSQL WAL skrám.

Um valkostina sem notaðir eru:

• name — heiti tengisins sem uppsetningin sem lýst er hér að neðan er notuð fyrir; í framtíðinni er þetta nafn notað til að vinna með tenginu (þ.e. skoða stöðuna / endurræsa / uppfæra stillinguna) í gegnum Kafka Connect REST API;
• connector.class — DBMS tengiflokkurinn sem verður notaður af stillta tenginu;
• plugin.name er nafn viðbótarinnar fyrir rökrétta afkóðun gagna úr WAL skrám. Hægt að velja úr wal2json, decoderbuffs и pgoutput. Fyrstu tvær krefjast uppsetningar á viðeigandi viðbótum í DBMS, og pgoutput fyrir PostgreSQL útgáfu 10 og nýrri krefst ekki frekari aðgerða;
• database.* — valkostir til að tengjast gagnagrunninum, hvar database.server.name - nafn PostgreSQL tilviksins sem notað er til að mynda nafn efnisins í Kafka þyrpingunni;
• table.include.list - listi yfir töflur þar sem við viljum fylgjast með breytingum; gefið upp í formi schema.table_name; ekki hægt að nota með table.exclude.list;
• heartbeat.interval.ms — bil (í millisekúndum) sem tengið sendir hjartsláttarboð í sérstakt efni;
• heartbeat.action.query - beiðni sem verður framkvæmd við sendingu hvers hjartsláttarskilaboða (valkosturinn hefur birst síðan útgáfa 1.1);
• slot.name — heiti afritunarraufarinnar sem verður notað af tenginu;
• publication.name - Nafn Birting í PostgreSQL sem tengið notar. Ef það er ekki til mun Debezium reyna að búa það til. Ef notandinn sem tengingin er gerð undir hefur ekki næg réttindi fyrir þessa aðgerð mun tengilinn hætta með villu;
• transforms ákvarðar hvernig nákvæmlega á að breyta heiti markefnisins:
  • transforms.AddPrefix.type gefur til kynna að við munum nota reglulegar segðir;
  • transforms.AddPrefix.regex — gríma þar sem nafn markefnisins er endurskilgreint;
  • transforms.AddPrefix.replacement - beint það sem við endurskilgreinum.

Meira um hjartslátt og umbreytingar

Sjálfgefið er að tengilinn sendir gögn til Kafka fyrir hverja færslu og skrifar LSN (Log Sequence Number) þess á þjónustuefnið offset. En hvað gerist ef tengið er stillt til að lesa ekki allan gagnagrunninn, heldur aðeins hluta af töflunum hans (þar sem gögn eru uppfærð sjaldan)?

• Tengið mun lesa WAL skrár og greina ekki viðskiptaskuldbindingar í þeim í töflurnar sem það fylgist með.
• Þess vegna mun það ekki uppfæra núverandi stöðu sína hvorki í efninu né í afritunarrofinu.
• Þetta mun aftur á móti valda því að WAL skrárnar verða „fastar“ á disknum og munu líklega klárast af plássi.

Og hér koma valkostir til bjargar. heartbeat.interval.ms и heartbeat.action.query. Með því að nota þessa valkosti í pörum er hægt að framkvæma beiðni um að breyta gögnum í sérstakri töflu í hvert sinn sem hjartsláttarskilaboð eru send. Þannig er LSN sem tengið er núna staðsett á (í afritunarraufinni) stöðugt uppfært. Þetta gerir DBMS kleift að fjarlægja WAL skrár sem ekki er lengur þörf á. Fyrir frekari upplýsingar um hvernig valkostir virka, sjá skjöl.

Annar valkostur sem verðskuldar nánari athygli er transforms. Þó það snúist meira um þægindi og fegurð ...

Sjálfgefið, Debezium býr til efni með því að nota eftirfarandi nafnastefnu: serverName.schemaName.tableName. Þetta er kannski ekki alltaf þægilegt. Valmöguleikar transforms með því að nota reglulegar segðir geturðu skilgreint lista yfir töflur þar sem beina þarf atburðum á efni með ákveðnu nafni.

Í uppsetningu okkar þökk sé transforms eftirfarandi gerist: allir CDC atburðir úr rakta gagnagrunninum fara í efnið með nafninu data.cdc.dbname. Annars (án þessara stillinga), myndi Debezium sjálfgefið búa til efni fyrir hverja töflu á eyðublaðinu: pg-dev.public.<table_name>.

Tengitakmarkanir

Í lok lýsingarinnar á tengistillingunni fyrir PostgreSQL er þess virði að tala um eftirfarandi eiginleika / takmarkanir á starfi þess:

1. Tengivirknin fyrir PostgreSQL byggir á hugmyndinni um rökræna afkóðun. Því hann rekur ekki beiðnir um að breyta uppbyggingu gagnagrunnsins (DDL) - í samræmi við það verða þessi gögn ekki í umræðunum.
2. Þar sem afritunarrauf eru notuð er tenging tengisins möguleg aðeins til aðal DBMS tilviksins.
3. Ef notandinn þar sem tengið tengist gagnagrunninum hefur skrifvarinn rétt, þá þarftu að búa til afritunarrauf handvirkt fyrir fyrstu ræsingu og birta í gagnagrunninum.

Að beita stillingu

Svo skulum við hlaða uppsetningu okkar í tengið:

curl -i -X POST -H "Accept:application/json" 
  -H  "Content-Type:application/json"  http://localhost:8083/connectors/ 
  -d @pg-con.json

Við athugum hvort niðurhalið hafi tekist og tengið hafi byrjað:

$ curl -i http://localhost:8083/connectors/pg-connector/status 
HTTP/1.1 200 OK
Date: Thu, 17 Sep 2020 20:19:40 GMT
Content-Type: application/json
Content-Length: 175
Server: Jetty(9.4.20.v20190813)

{"name":"pg-connector","connector":{"state":"RUNNING","worker_id":"172.24.0.5:8083"},"tasks":[{"id":0,"state":"RUNNING","worker_id":"172.24.0.5:8083"}],"type":"source"}

Frábært: það er sett upp og tilbúið til notkunar. Nú skulum við þykjast vera neytandi og tengjumst Kafka, eftir það bætum við við og breytum færslu í töflunni:

$ kafka/bin/kafka-console-consumer.sh 
  --bootstrap-server kafka:9092 
  --from-beginning 
  --property print.key=true 
  --topic data.cdc.dbname

postgres=# insert into customers (id, first_name, last_name, email) values (1005, 'foo', 'bar', '[email protected]');
INSERT 0 1
postgres=# update customers set first_name = 'egg' where id = 1005;
UPDATE 1

Í efni okkar mun þetta birtast sem hér segir:

Mjög langt JSON með breytingunum okkar

{
"schema":{
"type":"struct",
"fields":[
{
"type":"int32",
"optional":false,
"field":"id"
}
],
"optional":false,
"name":"data.cdc.dbname.Key"
},
"payload":{
"id":1005
}
}{
"schema":{
"type":"struct",
"fields":[
{
"type":"struct",
"fields":[
{
"type":"int32",
"optional":false,
"field":"id"
},
{
"type":"string",
"optional":false,
"field":"first_name"
},
{
"type":"string",
"optional":false,
"field":"last_name"
},
{
"type":"string",
"optional":false,
"field":"email"
}
],
"optional":true,
"name":"data.cdc.dbname.Value",
"field":"before"
},
{
"type":"struct",
"fields":[
{
"type":"int32",
"optional":false,
"field":"id"
},
{
"type":"string",
"optional":false,
"field":"first_name"
},
{
"type":"string",
"optional":false,
"field":"last_name"
},
{
"type":"string",
"optional":false,
"field":"email"
}
],
"optional":true,
"name":"data.cdc.dbname.Value",
"field":"after"
},
{
"type":"struct",
"fields":[
{
"type":"string",
"optional":false,
"field":"version"
},
{
"type":"string",
"optional":false,
"field":"connector"
},
{
"type":"string",
"optional":false,
"field":"name"
},
{
"type":"int64",
"optional":false,
"field":"ts_ms"
},
{
"type":"string",
"optional":true,
"name":"io.debezium.data.Enum",
"version":1,
"parameters":{
"allowed":"true,last,false"
},
"default":"false",
"field":"snapshot"
},
{
"type":"string",
"optional":false,
"field":"db"
},
{
"type":"string",
"optional":false,
"field":"schema"
},
{
"type":"string",
"optional":false,
"field":"table"
},
{
"type":"int64",
"optional":true,
"field":"txId"
},
{
"type":"int64",
"optional":true,
"field":"lsn"
},
{
"type":"int64",
"optional":true,
"field":"xmin"
}
],
"optional":false,
"name":"io.debezium.connector.postgresql.Source",
"field":"source"
},
{
"type":"string",
"optional":false,
"field":"op"
},
{
"type":"int64",
"optional":true,
"field":"ts_ms"
},
{
"type":"struct",
"fields":[
{
"type":"string",
"optional":false,
"field":"id"
},
{
"type":"int64",
"optional":false,
"field":"total_order"
},
{
"type":"int64",
"optional":false,
"field":"data_collection_order"
}
],
"optional":true,
"field":"transaction"
}
],
"optional":false,
"name":"data.cdc.dbname.Envelope"
},
"payload":{
"before":null,
"after":{
"id":1005,
"first_name":"foo",
"last_name":"bar",
"email":"[email protected]"
},
"source":{
"version":"1.2.3.Final",
"connector":"postgresql",
"name":"dbserver1",
"ts_ms":1600374991648,
"snapshot":"false",
"db":"postgres",
"schema":"public",
"table":"customers",
"txId":602,
"lsn":34088472,
"xmin":null
},
"op":"c",
"ts_ms":1600374991762,
"transaction":null
}
}{
"schema":{
"type":"struct",
"fields":[
{
"type":"int32",
"optional":false,
"field":"id"
}
],
"optional":false,
"name":"data.cdc.dbname.Key"
},
"payload":{
"id":1005
}
}{
"schema":{
"type":"struct",
"fields":[
{
"type":"struct",
"fields":[
{
"type":"int32",
"optional":false,
"field":"id"
},
{
"type":"string",
"optional":false,
"field":"first_name"
},
{
"type":"string",
"optional":false,
"field":"last_name"
},
{
"type":"string",
"optional":false,
"field":"email"
}
],
"optional":true,
"name":"data.cdc.dbname.Value",
"field":"before"
},
{
"type":"struct",
"fields":[
{
"type":"int32",
"optional":false,
"field":"id"
},
{
"type":"string",
"optional":false,
"field":"first_name"
},
{
"type":"string",
"optional":false,
"field":"last_name"
},
{
"type":"string",
"optional":false,
"field":"email"
}
],
"optional":true,
"name":"data.cdc.dbname.Value",
"field":"after"
},
{
"type":"struct",
"fields":[
{
"type":"string",
"optional":false,
"field":"version"
},
{
"type":"string",
"optional":false,
"field":"connector"
},
{
"type":"string",
"optional":false,
"field":"name"
},
{
"type":"int64",
"optional":false,
"field":"ts_ms"
},
{
"type":"string",
"optional":true,
"name":"io.debezium.data.Enum",
"version":1,
"parameters":{
"allowed":"true,last,false"
},
"default":"false",
"field":"snapshot"
},
{
"type":"string",
"optional":false,
"field":"db"
},
{
"type":"string",
"optional":false,
"field":"schema"
},
{
"type":"string",
"optional":false,
"field":"table"
},
{
"type":"int64",
"optional":true,
"field":"txId"
},
{
"type":"int64",
"optional":true,
"field":"lsn"
},
{
"type":"int64",
"optional":true,
"field":"xmin"
}
],
"optional":false,
"name":"io.debezium.connector.postgresql.Source",
"field":"source"
},
{
"type":"string",
"optional":false,
"field":"op"
},
{
"type":"int64",
"optional":true,
"field":"ts_ms"
},
{
"type":"struct",
"fields":[
{
"type":"string",
"optional":false,
"field":"id"
},
{
"type":"int64",
"optional":false,
"field":"total_order"
},
{
"type":"int64",
"optional":false,
"field":"data_collection_order"
}
],
"optional":true,
"field":"transaction"
}
],
"optional":false,
"name":"data.cdc.dbname.Envelope"
},
"payload":{
"before":{
"id":1005,
"first_name":"foo",
"last_name":"bar",
"email":"[email protected]"
},
"after":{
"id":1005,
"first_name":"egg",
"last_name":"bar",
"email":"[email protected]"
},
"source":{
"version":"1.2.3.Final",
"connector":"postgresql",
"name":"dbserver1",
"ts_ms":1600375609365,
"snapshot":"false",
"db":"postgres",
"schema":"public",
"table":"customers",
"txId":603,
"lsn":34089688,
"xmin":null
},
"op":"u",
"ts_ms":1600375609778,
"transaction":null
}
}

Í báðum tilfellum samanstanda færslurnar af lyklinum (PK) færslunnar sem var breytt, og kjarna breytinganna: hvað skráin var á undan og hvað hún varð eftir.

• Í tilviki INSERT: gildi áður (before) jafngildir nullfylgt eftir með strengnum sem var settur inn.
• Í tilviki UPDATE: í payload.before fyrra ástand línunnar birtist og í payload.after - nýtt með kjarna breytinga.

2.2 MongoDB

Þetta tengi notar staðlaða MongoDB afritunarbúnaðinn, les upplýsingar úr oplog aðalhnút DBMS.

Líkt og þegar lýst er tenglinum fyrir PgSQL, einnig hér, við fyrstu ræsingu, er skyndimynd frumgagna tekin, eftir það skiptir tengið yfir í oplog lestrarham.

Dæmi um stillingar:

{
"name": "mp-k8s-mongo-connector",
"config": {
"connector.class": "io.debezium.connector.mongodb.MongoDbConnector",
"tasks.max": "1",
"mongodb.hosts": "MainRepSet/mongo:27017",
"mongodb.name": "mongo",
"mongodb.user": "debezium",
"mongodb.password": "dbname",
"database.whitelist": "db_1,db_2",
"transforms": "AddPrefix",
"transforms.AddPrefix.type": "org.apache.kafka.connect.transforms.RegexRouter",
"transforms.AddPrefix.regex": "mongo.([a-zA-Z_0-9]*).([a-zA-Z_0-9]*)",
"transforms.AddPrefix.replacement": "data.cdc.mongo_$1"
}
}

Eins og þú sérð eru engir nýir valmöguleikar miðað við fyrra dæmi, heldur hefur aðeins fækkað þeim valmöguleikum sem bera ábyrgð á tengingu við gagnagrunninn og forskeytum þeirra.

Stillingar transforms að þessu sinni gera þeir eftirfarandi: breyta nafninu á markefninu úr kerfinu <server_name>.<db_name>.<collection_name> в data.cdc.mongo_<db_name>.

bilanaþol

Vandamálið um bilanaþol og mikið aðgengi á okkar tímum er áleitnari en nokkru sinni fyrr - sérstaklega þegar við tölum um gögn og viðskipti, og gagnabreytingarannsókn er ekki á hliðarlínunni í þessu máli. Við skulum skoða hvað getur farið úrskeiðis í grundvallaratriðum og hvað verður um Debezium í hverju tilviki.

Það eru þrír valkostir til að afþakka:

1. Kafka Connect bilun. Ef Connect er stillt til að virka í dreifðri stillingu, krefst þetta margra starfsmanna til að stilla sama group.id. Síðan, ef eitt þeirra mistekst, verður tengið endurræst á hinum starfsmanninum og haldið áfram að lesa frá síðustu skuldbundnu stöðunni í efninu í Kafka.
2. Tap á tengingu við Kafka þyrpinguna. Tengið mun einfaldlega hætta að lesa á þeim stað sem það tókst ekki að senda til Kafka og reyna reglulega að senda það aftur þar til tilraunin heppnast.
3. Gagnagjafi ekki tiltækur. Tengið mun reyna að tengjast upprunanum aftur í samræmi við uppsetninguna. Sjálfgefið er 16 tilraunir að nota veldisvísis bakslag. Eftir 16. misheppnaða tilraun verður verkefnið merkt sem mistókst og það verður að endurræsa það handvirkt í gegnum Kafka Connect REST viðmótið.
   • Í tilviki PostgreSQL gögn munu ekki glatast, vegna þess að notkun afritunarraufa kemur í veg fyrir eyðingu WAL skráa sem ekki eru lesnar af tenginu. Í þessu tilviki er galli: ef nettengingin milli tengisins og DBMS er trufluð í langan tíma, þá er möguleiki á að diskplássið klárast og það getur leitt til bilunar í öllu DBMS.
   • Í tilviki MySQL binlog skrám er hægt að snúa með DBMS sjálfu áður en tenging er endurheimt. Þetta mun valda því að tengið fer í bilað ástand og það verður að endurræsa það í fyrstu skyndimyndaham til að halda áfram að lesa úr binlogs til að endurheimta eðlilega virkni.
   • á MongoDB. Skjölin segja: hegðun tengisins ef log/oplog skrám hefur verið eytt og tengið getur ekki haldið áfram að lesa frá þeim stað þar sem frá var horfið er sú sama fyrir öll DBMS. Það liggur í því að tengið mun fara inn í ríkið mistókst og mun krefjast endurræsingar í ham fyrstu skyndimynd.

     Hins vegar eru undantekningar. Ef tengið var í ótengdu ástandi í langan tíma (eða gat ekki náð í MongoDB tilvikið), og oplog var snúið á þessum tíma, þá mun tengið halda áfram að lesa gögn frá fyrstu tiltæku stöðu þegar tengingin er endurheimt. , sem er ástæðan fyrir sumum gagna í Kafka ekki mun slá.

Ályktun

Debezium er fyrsta reynsla mín af CDC kerfum og hefur verið mjög jákvæð í heildina. Verkefnið mútaði stuðningi helstu DBMS, auðveldri stillingu, stuðningi við klasagerð og virku samfélagi. Fyrir þá sem hafa áhuga á æfingum mæli ég með því að þú lesir leiðbeiningarnar fyrir Kafka Connect и Debezium.

Í samanburði við JDBC tengið fyrir Kafka Connect er helsti kosturinn við Debezium að breytingar eru lesnar úr DBMS logs, sem gerir kleift að taka á móti gögnum með lágmarks töf. JDBC tengið (útvegað af Kafka Connect) leitar í rakta töfluna með föstu millibili og (af sömu ástæðu) býr ekki til skilaboð þegar gögnum er eytt (hvernig er hægt að spyrjast fyrir um gögn sem eru ekki til staðar?).

Til að leysa svipuð vandamál geturðu veitt eftirfarandi lausnum eftirtekt (auk Debezium):

• JDBC tengi Kafka Connect
• Nokkrar MySQL eingöngu lausnir:
  • MySQL straumspilari;
  • Maxwell;
  • Spinal Tap;
• Oracle Golden Gate, en þetta er allt annar „þyngdarflokkur“.

PS

Lestu líka á blogginu okkar:

• «Ákvarðu viðeigandi stærð fyrir Kafka þyrping í Kubernetes»;
• «Hagnýtar sögur úr SRE daglegu lífi okkar. 2. hluti»;
• «Stutt yfirlit yfir PostgreSQL yfirlýsingar fyrir Kubernetes, val okkar og reynslu'.

Heimild: www.habr.com