Hvorfor dette problem opstod, selvom Amazon Aurora-lagervolumen automatisk vil vokse op til 64 TB.?
Først vil vi forstå lagringen i RDS Aurora. Der er 2 typer opbevaring i Aurora. Forekomstbutik er lokalt lager, hvor midlertidige objekter er gemt og hovedlageret for data. Derfor, når du kører ALTER på en tabel, vil den generere en temp-tabel, og RDS aurora ville bruge instanslager til at gemme temp-tabellen. For din instans, som er db.r3.large instans, har den 1×32 GB lokal lagerplads, så hvis dine midlertidige objekter på instansen bliver større end denne størrelse, får du fejlen "tabel fuld". Den lokale lagergrænse er også forskellig fra den samlede lagervolumen tilgængelig for din Aurora-instans, og baseret på din databasebrug vil din Amazon Aurora-lagervolumen automatisk vokse, op til 64 TB, i trin på 10 GB.Alter på stort bord i RDS løsning til tabel fuld Fejl
- For at løse problemet kan du skalere instansen op for at få mere lokal lagring til at køre din ALTER, ændre tabellen og derefter nedskalere instanstypen. Dette resulterer i, at du har en vis nedetid, mens du opgraderer/nedgraderer forekomsttypen.
- Du kan også bruge kommandoen "pt-online-schema-change", hvis du bruger denne kommando, gør den den originale tabel stadig tilgængelig til brug uden nedetid eller ingen bordlås.
Resultater:
Hvis du ændrer tabellen med pt -online-schema-change kommando på et bord, som har størrelsen 35-40GB, så kan det tage næsten 30 timer.pt-online-schema-change låser ikke bordet. Denne kommando opretter udløsere på den originale tabel. Men til dette har den brug for superbrugerrettigheder. når du bruger butiksproceduren får du fejlen:Hvorfor skal du bruge pt-online-schema-change-kommandoen, og hvorfor skal du aktivere “log_bin_trust_function_creators “ i DB-parametergruppen? ?
#1419 – Du har ikke SUPER-privilegiet, og binær logning er aktiveret (du *måske* vil bruge den mindre sikre log_bin_trust_function_creators-variabelÅrsag: Denne fejl opstår på RDS-forekomster, når du forsøger at bruge "Lagrede procedurer". Du vil snart finde ud af, at det ikke vil virke at give superprivilegiet til en bruger. Så den eneste måde at få tingene til at fungere på er at indstille log_bin_trust_function_creators til 1. I henhold til Percona-dokumenter: Bundlinjen er at skabe triggere på en server med binære logfiler aktiveret, kræver en bruger med SUPER-privilegier (hvilket er umuligt i Amazon RDS). Fejlmeddelelsen angiver løsningen. Vi skal aktivere variablen i DB-parametergruppen "log_bin_trust_function_creators". At aktivere det er som at sige til serveren: "Jeg stoler på almindelige brugeres triggere og funktioner, og at de ikke vil forårsage problemer, så tillad mine brugere at oprette dem." Da databasefunktionaliteten ikke ændres, bliver det et spørgsmål om at stole på dine brugere. log_bin_trust_function_creators er en global variabel, der kan ændres dynamisk. Forsøger at finde flere detaljer om "Super_priv", når du tjekker brugernes tilladelser i brugertabellen i MySQL-databasen. du kunne se, at Super_priv ikke er indstillet til andre end rdsadmin-brugeren.
MySQL> select User,Super_priv from user; +-----------+------------+ | User | Super_priv | +-----------+------------+ | rdsadmin | Y | | root | N | | dbuser | N | +-----------+------------+ 3 rows in set (0.00 sec)
Her er "root" Master-brugeren og "dbuser" er DB-brugeren, disse brugere er oprettet af os, og "rdsadmin"-brugeren oprettes automatisk af AWS, som vi ikke har adgang til denne bruger. rdsadmin MySQL-bruger bruges af Amazon til vedligeholdelses- og administrationsarbejde.
Dette er slutningen af selvstudiet, hvordan man ændrer på Big Table i RDS Solution to table full Error.