Först kommer vi att förstå lagringen i RDS Aurora. Det finns 2 typer av förvaring i Aurora. Instansbutik är lokal lagring där temporära objekt lagras och huvudlagringen för data. Därför, när du kör ALTER på en tabell, kommer den att generera en temptabell och RDS aurora skulle använda instanslagring för att lagra temptabellen. För din instans som är db.r3.large-instans har den 1×32 GB lokal lagring så om dina tillfälliga objekt på instansen blir större än den här storleken får du felet "tabell full". Dessutom skiljer sig den lokala lagringsgränsen från den totala lagringsvolymen tillgänglig för din Aurora-instans, och baserat på din databasanvändning kommer din Amazon Aurora-lagringsvolym automatiskt att växa, upp till 64 TB, i steg om 10 GB.Varför detta problem uppstod även om Amazon Aurora-lagringsvolymen automatiskt kommer att växa upp till 64TB.?
Alter på stort bord i RDS lösning till tabellen full Fel
- För att lösa problemet kan du skala upp instansen för att få mer lokal lagring för att köra din ALTER, ändra tabellen och sedan skala ner instanstypen. Detta resulterar i att du har en viss driftstopp när du uppgraderar/nedgraderar instanstypen.
- Du kan också använda kommandot "pt-online-schema-change", om du använder detta kommando gör det att den ursprungliga tabellen fortfarande är tillgänglig att använda utan driftstopp eller inget bordslås.
Resultat:
Om du ändrar tabellen med pt -online-schema-change kommando på ett bord som har storleken 35-40GB så kan det ta nästan 30 timmar.pt-online-schema-change låser inte bordet. Detta kommando skapar utlösare på den ursprungliga tabellen. Men för detta behöver den superanvändarprivilegier. när du använder butiksproceduren får du felet:Varför ska man använda kommandot pt-online-schema-change och varför man aktiverar “log_bin_trust_function_creators “ i DB-parametergruppen? ?
#1419 – Du har inte SUPER-privilegiet och binär loggning är aktiverad (du *kanske* vill använda den mindre säkra log_bin_trust_function_creators-variabelnOrsak: Det här felet uppstår på RDS-instanser när du försöker använda "Lagrade procedurer". Du kommer snart att få reda på att det inte fungerar att ge superprivilegiet för en användare. Så det enda sättet att få saker att fungera är att ställa in log_bin_trust_function_creators till 1. I enlighet med Percona-dokument: Slutet är att skapa triggers på en server med binära loggar aktiverade kräver en användare med SUPER-privilegier (vilket är omöjligt i Amazon RDS). Felmeddelandet anger lösningen. Vi måste aktivera variabeln i DB-parametergruppen " log_bin_trust_function_creators". Att aktivera det är som att säga till servern: "Jag litar på vanliga användares triggers och funktioner och att de inte kommer att orsaka problem, så låt mina användare skapa dem." Eftersom databasfunktionaliteten inte kommer att förändras, blir det en fråga om att lita på dina användare. log_bin_trust_function_creators är en global variabel som kan ändras dynamiskt. Försöker hitta mer information om "Super_priv", När du kontrollerar användarnas behörigheter i användartabellen i MySQL-databasen. du kunde se att Super_priv inte är inställt för någon förutom rdsadmin-användaren.
MySQL> select User,Super_priv from user; +-----------+------------+ | User | Super_priv | +-----------+------------+ | rdsadmin | Y | | root | N | | dbuser | N | +-----------+------------+ 3 rows in set (0.00 sec)
Här är "root" huvudanvändaren och "dbuser" är DB-användaren som dessa användare skapas av oss och "rdsadmin"-användaren skapas automatiskt av AWS som vi inte har åtkomst till denna användare. rdsadmin MySQL-användare används av Amazon för underhålls- och hanteringsarbete.
Det här är slutet på handledningen, hur man ändrar på Big Table i RDS Lösning för att tabell fullt fel.