Eerst zullen we de opslag in RDS Aurora begrijpen. Er zijn 2 soorten opslag in Aurora. Instantiewinkel is lokale opslag waar tijdelijke objecten worden opgeslagen en de hoofdopslag voor gegevens. Daarom zal het, wanneer u ALTER op een tabel uitvoert, een tijdelijke tabel genereren en RDS aurora zou instantieopslag gebruiken om de tijdelijke tabel op te slaan. Voor uw instantie die db.r3.large is, heeft deze 1 × 32 GB aan lokale opslag, dus als uw tijdelijke objecten op de instantie groter worden dan deze grootte, krijgt u de foutmelding 'tabel vol'. Ook verschilt de lokale opslaglimiet van het totale opslagvolume beschikbaar voor uw Aurora-instantie, en op basis van uw databasegebruik, groeit uw Amazon Aurora-opslagvolume automatisch, tot 64 TB, in stappen van 10 GB.Waarom deed dit probleem zich voor, ook al groeit het Amazon Aurora-opslagvolume automatisch tot 64 TB.?
Wijzigen op grote tafel in RDS oplossing voor tabel vol Fout
- Om dit probleem op te lossen, kunt u de instantie opschalen om meer lokale opslag te krijgen om uw ALTER uit te voeren, de tabel wijzigen en vervolgens het instantietype verkleinen. Dit leidt tot enige downtime tijdens het type upgrade/downgrade.
- U kunt ook de opdracht "pt-online-schema-change" gebruiken. Als u deze opdracht gebruikt, blijft de originele tabel beschikbaar voor gebruik zonder downtime of geen tafelslot.
Resultaten:
Als u de tabel wijzigt met pt -online-schema-change commando op een tafel met een grootte van 35-40 GB, dan kan het ongeveer 30 uur duren.pt-online-schema-change vergrendelt de tafel niet. Met deze opdracht worden triggers gemaakt op de oorspronkelijke tabel. Maar hiervoor heeft het superuser-privileges nodig. wanneer je de winkelprocedure gebruikt, krijg je de foutmelding:Waarom de opdracht pt-online-schema-change gebruiken en waarom inschakelen "log_bin_trust_function_creators" in DB-parametergroep? ?
#1419 – Je hebt niet het SUPER-privilege en binaire logboekregistratie is ingeschakeld (je *misschien* wil de minder veilige log_bin_trust_function_creators variabelegebruiken Reden: Deze fout treedt op bij RDS-instanties wanneer u "Opgeslagen procedures" probeert te gebruiken. U zult snel ontdekken dat het verlenen van het superprivilege voor een gebruiker niet werkt. Dus de enige manier om dingen te laten werken, is door log_bin_trust_function_creators in te stellen op 1. Volgens Percona-documenten: Het komt erop neer dat het creëren van triggers op een server met binaire logboeken ingeschakeld een gebruiker met SUPER-rechten vereist (wat onmogelijk is in Amazon RDS). Het foutbericht geeft de tijdelijke oplossing aan. We moeten de variabele inschakelen in de DB-parametergroep " log_bin_trust_function_creators". Het inschakelen is hetzelfde als tegen de server zeggen: "Ik vertrouw op de triggers en functies van gewone gebruikers en dat ze geen problemen veroorzaken, dus laat mijn gebruikers ze maken." Aangezien de databasefunctionaliteit niet verandert, wordt het een kwestie van vertrouwen in uw gebruikers. log_bin_trust_function_creators is een globale variabele die dynamisch kan worden gewijzigd. Ik probeer meer details te vinden over "Super_priv", wanneer u de machtigingen van de gebruikers controleert in de gebruikerstabel van de MySQL-database. je zou kunnen zien dat de Super_priv voor niemand is ingesteld, behalve voor de rdsadmin-gebruiker.
MySQL> select User,Super_priv from user; +-----------+------------+ | User | Super_priv | +-----------+------------+ | rdsadmin | Y | | root | N | | dbuser | N | +-----------+------------+ 3 rows in set (0.00 sec)
Hier is "root" de hoofdgebruiker en "dbuser" is de DB-gebruiker, deze gebruikers zijn door ons gemaakt en de "rdsadmin" -gebruiker wordt automatisch gemaakt door AWS waar we geen toegang toe hebben. rdsadmin MySQL-gebruiker wordt door Amazon gebruikt voor onderhouds- en beheerwerkzaamheden.
Dit is het einde van de tutorial, hoe je een grote tafel in de RDS-oplossing kunt wijzigen in een volledige fout.