sql >> Database teknologi >  >> RDS >> Database

Ændre på Big Table i RDS Løsning til tabel fuld fejl

Skift på Big Table i RDS Løsning til tabel fuld Fejl. Lad os tage et eksempel, tabeller, der er meget store i størrelse (~> 100 GB til 600 GB). At lave ændringer på så store borde er HØJ hukommelse og CPU-intensiv opgave. Når du forsøger at ændre forespørgslen på en af ​​tabellerne, gav det "FEJL 1114 (HY000):tabel fuld " fejl...

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

  1. 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.
  2. 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.
Hvis du ikke havde råd til at have nedetid i systemet, så brug pt-online-schema-change kommando i stedet for at skalere forekomsten. Dog dokumentation for pt-online-schema-change  siger, vi bør tage en sikkerhedskopi, før vi kører denne kommando. For at undgå tabellåse og fejl under ændring af produktionstabel kan du derfor teste denne kommando på en nøjagtig kopi af applikationsdatabasen med samme RDS-instanstype. Prøv også at tilføje en stor skrivebelastning på tabellen for at efterligne trafikken . For at opnå dette skal du oprette et bash-script, der løbende indsætter en ny række i tabellen. For at få en hurtig nøjagtig kopi af din nuværende DB, tag et øjebliksbillede af RDS DB og gendan det fra snapshot til test.  Før vi kører denne kommando, skal vi indstille log_bin_trust_function_creators til 1 i RDS DB-parametergruppen. Når du er færdig med ALTER-processen, kan du ændre variablen til "0" igen.
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.

Hvorfor skal du bruge pt-online-schema-change-kommandoen, og hvorfor skal du aktivere  “log_bin_trust_function_creators “  i DB-parametergruppen? ?

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:
#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.


  1. 6 problemforespørgsler, der gør din database meget langsommere

  2. Forældede funktioner til at tage ud af din værktøjskasse – Del 1

  3. Sådan opretter du forbindelse til SQL Server Default Instance og SQL Server Navngivne Instances - SQL Server / TSQL Tutorial Del 2

  4. Generering af tidsserier mellem to datoer i PostgreSQL