sql >> Databasteknik >  >> RDS >> Database

Ändra på Big Table i RDS Lösning till tabell fullt fel

Ändra på Big Table i RDS Lösning på tabellen full Fel. Låt oss ta ett exempel, tabeller som är mycket stora (~> 100 GB till 600 GB). Att göra ändringar på så stora tabeller är HÖGT minne och CPU-intensiv uppgift. När du försöker ändra frågan på en av tabellerna gav det "ERROR 1114 (HY000):tabellen full " fel ...

Varför detta problem uppstod även om Amazon Aurora-lagringsvolymen automatiskt kommer att växa upp till 64TB.?

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.

Alter på stort bord i RDS  lösning till tabellen full Fel

  1. 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.
  2. 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.
Om du inte hade råd att ha någon driftstopp i systemet använder du pt-online-schema-change kommandot istället för att skala instansen. Dock dokumentation av pt-online-schema-change  säger, vi bör ta en säkerhetskopia innan vi kör det här kommandot. För att undvika eventuella tabelllåsningar och fel under ändring av produktionstabell kan du testa detta kommando på en exakt kopia av applikationsdatabasen, med samma RDS-instanstyp. Försök också att lägga till en stor skrivbelastning på tabellen för att efterlikna trafiken . För att uppnå detta, skapa ett bash-skript som kontinuerligt infogar en ny rad i tabellen. För att få en snabb exakt kopia av din nuvarande DB, ta en ögonblicksbild av RDS DB och återställ den från ögonblicksbilden för testning.  Innan vi kör det här kommandot måste vi ställa in log_bin_trust_function_creators till 1 i RDS DB-parametergruppen. När du är klar med ALTER-processen kan du ändra variabeln till "0" igen.
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.

Varför ska man använda kommandot pt-online-schema-change och varför man aktiverar  “log_bin_trust_function_creators “  i DB-parametergruppen? ?

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


  1. finns det en PRODUKT-funktion som det finns en SUM-funktion i Oracle SQL?

  2. PLSQL Infoga i med subquery och returnerande klausul

  3. Hur man lägger till tid till ett Datetime-värde i MySQL

  4. Skapa visuell databas med MySQL Workbench