Database
 sql >> Datenbank >  >> RDS >> Database

Ändern Sie die große Tabelle in der RDS-Lösung in den Fehler „Tabelle voll“.

Auf Big Table in RDS ändern Lösung für den Fehler „Tabelle voll“. Nehmen wir ein Beispiel:sehr große Tabellen (~> 100 GB bis 600 GB). Die Durchführung von Änderungen an solch großen Tabellen ist eine HOCH speicher- und CPU-intensive Aufgabe. Wenn Sie versuchen, die Abfrage für eine der Tabellen zu ändern, wurde „ERROR 1114 (HY000):table full“ ausgegeben ” Fehler…

Warum ist dieses Problem aufgetreten, obwohl das Amazon Aurora-Speichervolumen automatisch auf 64 TB anwächst?

Zuerst werden wir die Speicherung in RDS Aurora. verstehen Es gibt 2 Speicherarten in Aurora. Instanzspeicher ist der lokale Speicher, in dem temporäre Objekte gespeichert werden, und der Hauptspeicher für Daten. Wenn Sie ALTER für eine Tabelle ausführen, wird daher eine temporäre Tabelle generiert, und RDS Aurora würde Instanzspeicher verwenden, um die temporäre Tabelle zu speichern. Ihre Instanz, die db.r3.large-Instanz, verfügt über 1 × 32 GB lokalen Speicher. Wenn Ihre temporären Objekte auf der Instanz also größer als diese Größe werden, erhalten Sie den Fehler „Tabelle voll“. Außerdem unterscheidet sich das lokale Speicherlimit vom Gesamtspeichervolumen verfügbar für Ihre Aurora-Instance und basierend auf Ihrer Datenbanknutzung wird Ihr Amazon Aurora-Speichervolumen automatisch in 10-GB-Schritten auf bis zu 64 TB anwachsen.

Auf großer Tabelle in RDS  ändern Lösung für den Fehler „Tabelle voll“

  1. Um das Problem zu lösen, können Sie die Instanz hochskalieren, um mehr lokalen Speicher zum Ausführen Ihres ALTER zu erhalten, die Tabelle ändern und dann den Instanztyp herunterskalieren. Dies führt zu einigen Ausfallzeiten während des Upgrade-/Downgrade-Instanztyps.
  2. Sie können auch den Befehl „pt-online-schema-change“ verwenden, wenn Sie diesen Befehl verwenden, wird die ursprüngliche Tabelle weiterhin ohne Ausfallzeit zur Verwendung verfügbar oder keine Tabellensperre.
Wenn Sie sich keine Ausfallzeit im System leisten können, verwenden Sie den Befehl pt-online-schema-change, anstatt die Instanz zu skalieren. Allerdings Dokumentation von pt-online-schema-change  sagt, sollten wir ein Backup erstellen, bevor wir diesen Befehl ausführen. Um Tabellensperren und Fehler während der Änderung der Produktionstabelle zu vermeiden, können Sie diesen Befehl daher mit einer exakten Kopie der Anwendungsdatenbank mit demselben RDS-Instance-Typ testen. Versuchen Sie außerdem, der Tabelle eine hohe Schreiblast hinzuzufügen, um den Datenverkehr nachzuahmen . Erstellen Sie dazu ein Bash-Skript, das fortlaufend eine neue Zeile in die Tabelle einfügt. Um schnell eine exakte Kopie Ihrer aktuellen DB zu erhalten, erstellen Sie einen Snapshot der RDS-DB und stellen Sie ihn zum Testen aus dem Snapshot wieder her.  Bevor wir diesen Befehl ausführen, müssen wir in der RDS-DB-Parametergruppe log_bin_trust_function_creators auf 1 setzen. Nachdem Sie mit dem ALTER-Prozess fertig sind, können Sie die Variable wieder auf „0“ ändern.
Ergebnisse:
Wenn Sie die Tabelle mit pt ändern -online-schema-change  Befehl ein  Bei einer Tabelle mit einer Größe von 35-40 GB kann es ungefähr 30 Stunden dauern.

Warum sollte der Befehl pt-online-schema-change verwendet und aktiviert werden  “log_bin_trust_function_creators “  in DB-Parametergruppe? ?

pt-online-schema-change  sperrt die Tabelle nicht. Dieser Befehl erstellt Trigger für die ursprüngliche Tabelle. Aber dafür braucht es Superuser-Rechte. Wenn Sie die Store-Prozedur verwenden, erhalten Sie den Fehler:
#1419 – Sie haben nicht das SUPER-Privileg und die binäre Protokollierung ist aktiviert (Sie *möglicherweise* möchten die weniger sichere Variable log_bin_trust_function_creators verwenden
Grund:  Dieser Fehler tritt auf RDS-Instanzen auf, wenn Sie versuchen, „Stored Procedures“ zu verwenden. Sie werden bald feststellen, dass das Gewähren des Super-Privilegs für einen Benutzer nicht funktioniert. Die einzige Möglichkeit, die Dinge zum Laufen zu bringen, besteht darin, log_bin_trust_function_creators auf 1 zu setzen.   Gemäß Percona-Dokumenten: Unter dem Strich erfordert das Erstellen von Triggern auf einem Server mit aktivierten Binärprotokollen einen Benutzer mit SUPER-Berechtigungen (was in Amazon RDS nicht möglich ist). Die Fehlermeldung gibt die Problemumgehung an. Wir müssen die Variable in der DB-Parametergruppe „log_bin_trust_function_creators“ aktivieren. Es zu aktivieren ist wie zum Server zu sagen: "Ich vertraue den Auslösern und Funktionen normaler Benutzer und dass sie keine Probleme verursachen, also erlauben Sie meinen Benutzern, sie zu erstellen." Da sich die Datenbankfunktionalität nicht ändert, müssen Sie Ihren Benutzern vertrauen. log_bin_trust_function_creators ist eine globale Variable, die dynamisch geändert werden kann. Versuchen Sie, mehr Details zu „Super_priv“ zu finden, wenn Sie die Berechtigungen der Benutzer in der Benutzertabelle der MySQL-Datenbank überprüfen. Sie konnten sehen, dass Super_priv für niemanden außer dem Benutzer rdsadmin festgelegt ist. 
MySQL> select User,Super_priv from user;
+-----------+------------+
| User | Super_priv |
+-----------+------------+
| rdsadmin | Y |
| root | N |
| dbuser | N |
+-----------+------------+
3 rows in set (0.00 sec)

Hier ist „root“ der Master-Benutzer und „dbuser“ der DB-Benutzer. Diese Benutzer werden von uns erstellt, und der Benutzer „rdsadmin“ wird automatisch von AWS erstellt, auf den wir keinen Zugriff haben. rdsadmin MySQL-Benutzer wird von Amazon für Wartungs- und Verwaltungsarbeiten verwendet.

Dies ist das Ende des Tutorials, wie man eine große Tabelle in der RDS-Lösung ändert, um einen Fehler bei voller Tabelle zu erhalten.