index të papërdorur kërkojnë kontrolle në çdo node replica të bazës së të dhënave
index të papërdorur në bazën relacionale open-source të të dhënave që përdoret nga shumë aplikacione web nuk mund të vlerësohen në mënyrë të sigurt vetëm nga primary server kur replica përpunojnë një pjesë të workload të leximit. Një index, një strukturë të dhënash që e ndihmon serverin e bazës së të dhënave të gjejë rreshta pa shqyrtuar një tabelë të tërë, mund të mos ketë asnjë lexim në primary, ndërkohë që mbetet thelbësor për query të raportimit, dashboard ose batch diku tjetër. index të panevojshëm vazhdojnë të kenë kosto: serveri i bazës së të dhënave duhet t’i përditësojë gjatë operacioneve INSERT dhe UPDATE, ata konsumojnë memorien e buffer pool, zmadhojnë backup dhe mund të zgjasin ndryshimet në schema.
Që nga versioni 5.7, sys schema ka përfshirë `sys.schema_unused_indexes`, një view që paraqet index pa lexime të regjistruara që nga nisja e serverit. Provat e tij vijnë nga Performance Schema, mekanizmi i brendshëm i serverit të bazës së të dhënave për mbledhjen e matjeve operacionale. Këta counter janë lokalë për secilin server. Ata nuk tregojnë se një reporting replica përdor një index për punët e fundmuajit, se një Aurora reader u shërben kërkesave të dashboard, ose se një load balancer dërgon query të caktuara te një anëtar i Galera apo Percona XtraDB Cluster. Heqja e një index të tillë përmes DDL të replikuar, komandat që ndryshojnë strukturat e bazës së të dhënave, mund ta shndërrojë një query të shpejtë në replica në një full table scan që shqyrton çdo rresht.
Restart krijojnë një tjetër pikë të verbër, sepse counter kthehen në zero. Një server ku është instaluar patch të martën mund të mos ketë vëzhguar ende një proces batch javor ose një raport tremujor. Prandaj uptime ka rëndësi, por asnjë numër universal ditësh nuk provon se një index është i tepërt. Periudha e vëzhgimit duhet të përfshijë ngjarjet e biznesit dhe scheduled job që e bëjnë workload përfaqësues.
Percona zhvilloi script open-source në Python `check_unused_indexes` për të ndërthurur prova në të gjithë një replication topology, bashkësia e lidhur e primary, replica dhe cluster peer që mbajnë të dhëna të ndërlidhura. Duke marrë një inventory dhe një primary të përcaktuar, ai lidhet me çdo server të listuar dhe lexon `SHOW REPLICA STATUS`, ose `SHOW SLAVE STATUS` në versionet më të vjetra, së bashku me `@@wsrep_cluster_name`, `information_schema.replica_host_status` të Aurora kur është i disponueshëm dhe variablën e statusit `Uptime`. Më pas ai ndjek replication downstream, duke përfshirë replication zinxhir dhe rrethor, dhe shton peer të Galera ose Percona XtraDB Cluster. Aurora reader lidhen përmes server ID ose një konvente alias.
Entry në inventory që nuk lidhen me primary e zgjedhur përjashtohen, duke lejuar që një file të përshkruajë një fleet më të madh. Përputhja e host bëhet si plain text: nëse `Source_Host` përmban `db-primary.internal`, inventory duhet të përdorë atë hostname dhe jo një IP address. Një inventory mund të përmbajë një entry `alias=host:port` për çdo rresht, duke përdorur port 3306 kur ai lihet pa specifikuar. Serverët mund të jepen edhe drejtpërdrejt me `--primary` dhe `--replicas`.
Pas përcaktimit të topology, script ekzekuton query ndaj `sys.schema_unused_indexes` në çdo node të përfshirë. Ai shpërfill gjithmonë `sys`, schema e sistemit të vetë serverit të bazës së të dhënave, `performance_schema` dhe `information_schema`. Ai përjashton gjithashtu një index kur kolona e tij e parë merr pjesë në një foreign key, një rregull që lidh vlera ndërmjet tabelave, sepse serveri i bazës së të dhënave kërkon index mbështetës për këto constraint. Operatorët mund ta ngushtojnë kontrollin me `--include-schema` dhe `--include-table`, ose të shtojnë përjashtime me `--ignore-schema`.
Hapi i fundit gjen prerjen e rezultateve, duke mbajtur vetëm index që raportohen si të palexuar në çdo node të kontrolluar. Në shembullin e Percona, primary raportoi 12 kandidatë, një replica raportoi tetë dhe një tjetër raportoi pesë. Uptime përkatëse ishin 42.1 ditë, 42.1 ditë dhe 14.0 ditë. Vetëm dy index, `app_db.orders.idx_legacy_status` dhe `app_db.users.idx_created_at`, rezultuan të papërdorur në të tre serverët. 10 kandidatët e tjerë nga primary u shërbenin leximeve diku tjetër. Opsioni `-qs` ose `--quiet-summary` afishon vetëm komandat e gjeneruara për përdorim në një ticket ose kërkesë ndryshimi.
Script është qëllimisht konservator ndaj provave që mungojnë. Dështimi për t’u lidhur me primary gjatë discovery është fatal. Entry të paarritshme në inventory prodhojnë paralajmërime me emra, sepse script nuk mund të kontrollojë statusin e tyre të replication ose të dijë nëse i përkasin topology. Nëse primary zhduket gjatë mbledhjes së të dhënave për index, përpunimi ndalet menjëherë. Nëse një replica ose cluster peer i identifikuar dështon në atë fazë, script përfundon, përveçse kur jepet `--force`. Rezultatet e detyruara kufizohen shprehimisht te node që u përgjigjën dhe nuk duhet të përdoren vetëm për të anashkaluar një problem të përkohshëm të rrjetit.
Node nën uptime minimal gjenerojnë një paralajmërim pas kontrollit. Pragu standard është shtatë ditë dhe mund të konfigurohet me `-u`; vendosja e tij në zero e çaktivizon paralajmërimin. Opsioni i testimit `--pause-seconds` vendos një vonesë ndërmjet discovery dhe mbledhjes, duke bërë të mundur ndalimin e qëllimshëm të një replica dhe konfirmimin se programi përfundon me kodin 1. Percona rekomandon testimin e kësaj rruge dështimi përpara se script të përdoret në production.
Instalimi kërkon Python 3.6 ose më të ri dhe Python client library për serverin e bazës së të dhënave. Credentials lexohen në mënyrë standarde nga `~/.my.cnf`, ose nga një database option file tjetër i zgjedhur me `-c`. E njëjta llogari vetëm për lexim duhet të ekzistojë në çdo node dhe i nevojitet leje për të lexuar `sys.schema_unused_indexes` dhe `information_schema`, si edhe për të ekzekutuar `SHOW REPLICA STATUS`. Vetë script nuk ndryshon asgjë. Projekti i tij me një file të vetëm publikohet sipas licencës Apache 2.0.
Komandat e gjeneruara janë propozime, jo veprime të automatizuara. Si standard, output i versionit 8.0 e bën secilin kandidat një invisible index. optimizer, komponenti i serverit të bazës së të dhënave që planifikon query, ndalon së përzgjedhuri një invisible index, por baza e të dhënave vazhdon ta mirëmbajë gjatë shkrimeve. Ndryshimi i visibility është një operacion metadata dhe mund të zhbëhet brenda pak sekondash, ndërsa heqja dhe rindërtimi i mëvonshëm i një index të madh mund të zgjasë me orë. `--action drop` afishon komandat e heqjes, ndërsa `--action both` afishon format për visibility dhe heqje.
Një rollout i kujdesshëm shqyrton fillimisht çdo kandidat dhe më pas i bën index e përzgjedhur invisible në primary, në mënyrë që ndryshimi të replikohet në të gjithë topology. Operatorët duhet të vëzhgojnë të paktën një cikël të plotë biznesi, duke përfshirë batch javore dhe job të fundmuajit, ndërkohë që monitorojnë metrikat e query dhe slow query log. Nëse performance përkeqësohet, `ALTER INDEX ... VISIBLE` rikthen aksesin e optimizer. Versioni 8.0 i lejon gjithashtu një session të vetëm të vendosë `use_invisible_indexes=on` në `optimizer_switch`, përfshirë përmes `SET_VAR`, për të testuar nëse një query i caktuar do të zgjidhte index e fshehur pa ia ekspozuar atë aplikacionit.
Mbeten disa kufizime të rëndësishme. Kontrollohen vetëm serverët e listuar në inventory. Performance Schema duhet të jetë aktivizuar. `sys.schema_unused_indexes` i lë jashtë primary key, por mund të raportojë UNIQUE index, të cilët mund të zbatojnë rregulla biznesi edhe kur nuk marrin lexime, ndaj kandidatët duhet të kontrollohen me `SHOW CREATE TABLE`. Grupimi i Aurora varet nga server ID ose alias si `aurora-reader-1`.