Yn ôfwachting fan it begjin fan in nije ynskriuwing foar de kursus Wy bliuwe in searje artikels publisearje oer fersifering yn MySQL.
Yn it foarige artikel yn dizze searje () wy hawwe it oer kaaiferwulften. Yn dit artikel sille wy sjen nei hoe't de masterkaai wurdt brûkt en beprate de foardielen en neidielen fan envelope fersifering.
It idee efter envelope-fersifering is dat de kaaien dy't brûkt wurde foar fersifering (de tablespace-kaaien) fersifere wurde mei in oare kaai (de masterkaai). Tafelromte-kaaien wurde eins brûkt om gegevens te fersiferjen. Grafysk kin it sa werjûn wurde:
De haadkaai leit yn 'e kaairing, en de tabelromte-kaaien binne yn' e fersifere tablespace-koppen (op side 0 fan 'e tabelromte).
Op de foto hjirboppe:
-
Tabel A is fersifere mei kaai 1 (Kaai 1). Kaai 1 is fersifere mei de masterkaai en wurdt fersifere opslein yn 'e kop fan tabel A.
-
Tabel B is fersifere mei kaai 2. Kaai 2 is fersifere mei de masterkaai (maskerkaai) en wurdt fersifere opslein yn 'e kop fan tabel B.
-
En sa op.
As de tsjinner tabel A moat ûntsiferje, hellet de masterkaai út opslach, lêst fersifere kaai 1 út 'e kop fan tabel A en ûntsiferet kaai 1. De ûntsifere kaai 1 wurdt yn it ûnthâld fan de tsjinner bewarre en wurdt brûkt om tabel A te ûntsiferjen .
InnoDB
Yn InnoDB wurdt de eigentlike fersifering en dekodearring dien by de I/O-laach. Dat is, de side wurdt fersifere krekt foardat it wurdt flushed nei skiif en ûntsiferje fuortendaliks neidat it is lêzen fan skiif.
Yn InnoDB wurket fersifering allinich op it tabelromtenivo. En standert wurde alle tabellen makke yn aparte tabelromten (). Mei oare wurden, in tabelromte wurdt makke dy't mar ien tabel befetsje kin. Hoewol jo ek tabellen kinne oanmeitsje yn 'e haadtafelromte (). Mar yn alle gefallen leit de tafel altyd yn guon tafelromte. En om't fersifering wurdt útfierd op it tablespace-nivo, is it of folslein fersifere of it is it net. Dat is, it is ûnmooglik om mar in diel fan 'e tabellen yn' e haadtafelromte te fersiferjen.
As jo om ien of oare reden triem-per-tabel útskeakele hawwe, dan wurde alle tabellen makke binnen de systeemtafelromte. YN jo kinne de systeemtafelromte fersiferje mei de innodb-fariabelesystablespacefersiferje of gebrûk fan fersiferingsthreads, mar dit is noch altyd in eksperimintele funksje. MySQL hat dit net.
Foardat wy fierder geane, moatte wy nei de struktuer fan 'e masterkaai-ID sjen. It bestiet út UUID, KEYID en foarheaksel "INNODBKey". It sjocht der sa út: INNODBKey-UUID-KEYID.
UUID is de uuid fan de tsjinner mei de fersifere tabelromte. KAAIID is gewoan in hieltyd tanimmende wearde. By it meitsjen fan de masterkaai KEY foar de earste kearID is 1. Under kaai rotation, doe't in nije master kaai wurdt oanmakke, KEYID = 2 ensafuorthinne. Wy sille mear prate oer masterkaairotaasje yn 'e folgjende artikels yn dizze searje.
No't wy witte hoe't in master-kaai-identifikaasje derút sjocht, litte wy nei de fersifere tabelromte-header sjen. As in tabelromte fersifere is, wurdt fersiferingsynformaasje tafoege oan de koptekst. It sjocht der sa út:
KEY ID is KEYID fan 'e masterkaai-ID dy't wy al besprutsen hawwe. UUID is de uuid fan 'e tsjinner, dy't ek brûkt wurdt yn 'e masterkaai-identifikaasje. TABLESPACE KEY - in tabel romte kaai, dy't bestiet út 256 bits willekeurich oanmakke troch de tsjinner. De inisjalisaasjevektor (IV) bestiet ek út 256 willekeurich oanmakke bits (hoewol't it moat wêze 128 bits). IV wurdt brûkt om AES-fersifering en dekodearring te initialisearjen (fan 256 bits wurde allinich 128 brûkt). Oan 'e ein is d'r in CRC32 kontrôlesum foar TABLESPACE KEY en IV.
Al dizze tiid ferienfâldige ik in bytsje troch te sizzen dat de koptekst de fersifere kaai fan 'e tabelromte befettet. Yn feite wurde de tabelromte-kaai en inisjalisaasjevektor opslein en fersifere tegearre mei de masterkaai. Unthâld dat foar it fersiferjen fan de tabelromte-kaai en inisjalisaasjevektor, wurdt in CRC32 foar har berekkene.
Wêrom is CRC32 nedich?
Yn in notedop, om de jildigens fan 'e masterkaai te garandearjen. Nei it ûntsiferjen fan de tabelromte-kaai en inisjalisaasjevektor, wurdt de kontrôlesum berekkene en fergelike mei de CRC32 opslein yn 'e koptekst. As de kontrôlesummen oerienkomme, dan hawwe wy de juste haadkaai en tabelromte-kaai. Oars wurdt de tabelromte markearre as ûntbrekt (wy kinne it dochs net ûntsiferje).
Jo kinne freegje: op hokker punt wurdt de kaaiferifikaasje útfierd? It antwurd is as de tsjinner begjint. In tsjinner mei fersifere tabellen / tabelromten lêst UUID, KEY by it opstartenID fan 'e koptekst en genereart de masterkaai-ID. It krijt dan de fereaske haadkaai fan 'e kaairing, ûntsiferet de tabelromte-kaai, en ferifiearret de kontrôlesum. Nochris, as de kontrôlesum oerienkomt, dan is alles goed, as net, wurdt de tabelromte markearre as ûntbrekt.
As jo it foarige artikel yn dizze searje lêze (), dan kinne jo ûnthâlde dat by it brûken fan in server-basearre kaai winkel, de tsjinner by it opstarten krijt allinnich in list fan kaai identifiers, of leaver, kaai id en brûkers id, sûnt dit pear unyk identifisearret de kaai. No sis ik dat as de tsjinner begjint, hy alle kaaien ûntfangt dy't it nedich is om te kontrolearjen dat it de tafelromte-kaaien kin ûntsiferje. Dus wêrom tidens inisjalisaasje, yn it gefal fan serveropslach, wurdt allinich kaai ladenid en brûkerid, en net alle kaaien? Om't jo miskien net alle kaaien nedich binne. Dit komt benammen troch master kaai rotaasje. As in master kaai wurdt rotearre, in nije master kaai wurdt makke yn it ferwulft, mar de âlde kaaien wurde net wiske. Sa kinne jo in protte kaaien hawwe yn 'e tsjinner keystore dy't de tsjinner net nedich hat en dus net ophelle wurde as de tsjinner begjint.
It is tiid om in bytsje te praten oer de foar- en neidielen fan fersifering fan masterkaaien. It grutste foardiel is dat jo mar ien fersiferingskaai (de masterkaai) nedich binne, dy't apart wurde opslein fan jo fersifere gegevens. Dit makket it opstarten fan tsjinner fluch en opslach lyts, wêrtroch it maklik te behearjen is. En ek de single master-kaai is maklik te regenerearjen.
Master-kaaifersifering hat lykwols ien grut nadeel: ienris in tabelromte is fersifere mei tablespace_key, bliuwt it altyd fersifere mei deselde kaai. It draaien fan de masterkaai helpt hjir net. Wêrom is dit in neidiel? Wy witte dat MySQL bugs hat dy't liede kinne ta in hommelse crash en it meitsjen fan in kearnbestân. Sûnt de kearnbestân befettet in tsjinner ûnthâld dump, kin it barre dat de dump befettet de ûntsifere tablespace kaai. Om it noch slimmer te meitsjen, wurde de ûntsifere tafelromte-kaaien yn it ûnthâld opslein, dy't kinne wurde wiksele nei skiif. Jo kinne sizze dat dit gjin neidiel is, om't jo rootrjochten nedich hawwe om tagong te krijen ta dizze bestannen en de swap-partysje. Ja. Mar root is mar in skoft nedich. Sadree't immen tagong hat ta de ûntsifere tafelromte-kaai, kin hy / sy trochgean mei it brûken om gegevens te ûntsiferjen, sels sûnder root-privileezjes. Dêrneist kin de skiif stellen wurde, en de swap-partition / kearnbestannen kinne wurde lêzen mei help fan tredden ark. It doel fan TDE is om it net lêsber te meitsjen sels as de skiif stellen is. YN It is mooglik om de tabelromte opnij te fersiferjen mei nije oanmakke kaaien. Dizze funksje wurdt fersiferingsthreads neamd en is noch altyd eksperiminteel op it momint fan skriuwen.
Lês mear:
Boarne: www.habr.com