Dieses Dokument ist Teil einer Reihe, die wichtige Informationen und Anleitungen im Zusammenhang mit der Planung und Durchführung von Oracle® 11g/12c-Datenbankmigrationen zu Cloud SQL for MySQL Version 5.7 (Instanzen der zweiten Generation) enthält. Die Reihe besteht aus folgenden Teilen:
- Oracle-Nutzer zu Cloud SQL for MySQL migrieren: Terminologie und Funktionalität
- Oracle-Nutzer zu Cloud SQL for MySQL migrieren: Datentypen, Nutzer und Tabellen
- Oracle-Nutzer zu Cloud SQL for MySQL migrieren: Abfragen, gespeicherte Verfahren, Funktionen und Trigger
- Oracle-Nutzer zu Cloud SQL for MySQL migrieren: Sicherheit, Vorgänge, Monitoring und Logging (dieses Dokument)
Sicherheit
In diesem Abschnitt werden die Unterschiede bei der Datenverschlüsselung zwischen Oracle und Cloud SQL for MySQL sowie die Prüfung der Zugriffssteuerung von Cloud SQL for MySQL erläutert.
Datenverschlüsselung in Oracle
Neben der grundlegenden Nutzerauthentifizierung und der Verwaltung von Nutzerrechten bietet Oracle den TDE-Mechanismus (Transparent Data Encryption), um für die Sicherheit inaktiver Daten eine zusätzliche Verschlüsselungsebene auf Betriebssystemebene hinzuzufügen. Nach der Konfiguration wird Oracle TDE automatisch vom System implementiert und erfordert keine manuelle Interaktion durch Nutzer. Für die Implementierung von Oracle TDE empfehlen wir, es explizit (per Befehl) für die erforderlichen und unterstützten Datenbankobjekte zu konfigurieren, die diese Art von Verschlüsselung akzeptieren, z. B. Tablespace, Tabelle oder Spalte. Für die Sicherheit von Daten bei der Übertragung empfehlen wir die Implementierung einer Netzwerksicherheitslösung.
Datenverschlüsselung in Cloud SQL for MySQL
Google Cloud bietet mehrere Verschlüsselungsebenen zum Schutz inaktiver Kundendaten in Google Cloud-Produkten, einschließlich Cloud SQL. Cloud SQL wird mit AES-128- oder AES-256-Verschlüsselung verschlüsselt. Weitere Informationen finden Sie unter Verschlüsselung inaktiver Daten. Im Gegensatz zur Oracle-Verschlüsselung, die mithilfe einer Konfiguration implementiert werden muss, verschlüsselt Google Cloud inaktive Kundendaten ohne Nutzeraktion automatisch. Aus Sicht der Schemakonvertierung sind keine Maßnahmen erforderlich und die Verschlüsselung bleibt für den Nutzer transparent.
Weitere Informationen dazu, wie Google Cloud die Verschlüsselung von Daten bei der Übertragung handhabt, finden Sie unter Verschlüsselung von Daten bei der Übertragung.
Audit
Oracle bietet verschiedene Prüfmethoden, wie die standardmäßige und die detaillierte Prüfung. Im Gegensatz dazu bietet MySQL standardmäßig keine entsprechenden Prüflösungen. Diese Einschränkung können Sie mit Google Cloud-Dashboards und -Monitoring umgehen. Zur Erfassung von DML-/DDL-Vorgängen in der Datenbank können Sie hingegen die Logs für langsame Abfragen, allgemeine Logs und Fehlerlogs als stabilere Prüflösung verwenden.
Zur Implementierung dieser Lösung empfehlen wir die Verwendung der Instanz-FLAGS, um das Log für langsame Abfragen und das allgemeine Log zu aktivieren. Darüber hinaus sollten Sie die Aufbewahrung dieser Logs entsprechend Ihren Geschäftsanforderungen verwalten.
Sie können Audit-Logs von Google Cloud verwenden, um Auditinformationen zu erfassen. Diese Logs decken drei Hauptebenen ab:
- Audit-Logs zur Administratoraktivität (standardmäßig aktiviert)
- Audit-Logs zum Datenzugriff (standardmäßig deaktiviert)
- Lesen Sie, wie Sie Datenzugriffslogs konfigurieren können
- Beachten Sie, dass Audit-Logs zum Datenzugriff keine Datenzugriffsvorgänge für Ressourcen aufzeichnen, auf die ohne Anmeldung in Google Cloud zugegriffen werden kann
- Audit-Logs zu Systemereignissen (standardmäßig aktiviert)
Audit-Logs in Google Cloud ansehen
So greifen Sie auf Audit-Logs zu: Google Cloud Console > Startseite > Aktivität
Sie können den Detaillierungsgrad zwischen den Audit-Ebenen filtern. Der folgende Screenshot zeigt ein Audit zu Administratoraktivitäten.
Die Cloud Logging-Seite
Zugriffspfad zur Logging-Seite: Google Cloud Console > Cloud Logging
Sie können den Detaillierungsgrad zwischen den Logtypen filtern. Der folgende Screenshot zeigt ein Audit allgemeiner Logs (Audit-Daten für Nutzer, Host und SQL-Anweisung).
Zugriffssteuerung bei Cloud SQL for MySQL
Nutzer können eine Verbindung zur Cloud SQL for MySQL-Instanz herstellen, wenn sie einen MySQL-Client mit einer autorisierten statischen IP-Adresse oder den Cloud SQL-Proxy verwenden, ähnlich wie bei jeder anderen Datenbankverbindung. Für andere Verbindungsquellen wie App Engine oder Compute Engine haben Nutzer mehrere Optionen, z. B. die Verwendung des Cloud SQL-Proxys. Diese Optionen werden unter Instanzzugriffssteuerung ausführlicher beschrieben.
Betrieb
In diesem Abschnitt werden der Export und Import, die Sicherung und Wiederherstellung auf Instanzebene, der MySQL-Ereignisplaner (für Datenbankjobs), Standby-Instanzen für schreibgeschützte Vorgänge sowie die Notfallwiederherstellung beschrieben.
Export und Import
Die Hauptmethode von Oracle für logische Export- und Importvorgänge ist die Verwendung des Dienstprogramms Data Pump unter Verwendung der Befehle EXPDP / IMPDP (eine ältere Version der Export-/Importfunktion von Oracle enthielt die Befehle exp und imp). Die entsprechenden MySQL-Befehle sind die Dienstprogramme mysqldump und mysqlimport, die Dumpdateien generieren und dann den Import auf Datenbank- oder Objektebene vornehmen (einschließlich des Exports und Imports von Metadaten).
Es gibt keine MySQL-Lösung, die direkt dem Oracle-Dienstprogramm DBMS_DATAPUMP entspricht (die Oracle-Methode zum Anwenden der Funktion EXPDP/IMPDP, die direkt mit dem Paket DBMS_DATAPUMP interagiert). Verwenden Sie zum Konvertieren von PL/SQL-Code DBMS_DATAPUMP aus Oracle alternativen Code (z. B. Bash oder Python), um logische Elemente zu implementieren, und verwenden Sie MySQL mysqldump und mysqlimport, um die Export-/Importvorgänge auszuführen.
Die MySQL-Dienstprogramme mysqldump und mysqlimport werden auf Clientebene ausgeführt (als Teil von MySQL-Client-Programmen) und stellen eine Remote-Verbindung zur Cloud SQL for MySQL-Instanz her. Dumpdateien werden clientseitig erstellt.
mysqldump:
Ein Clientdienstprogramm führt logische Sicherungen und Datenimporte als sql aus. Dies erzeugt eine Reihe von SQL-Anweisungen, die ausgeführt werden können, um die ursprünglichen Datenbankobjektdefinitionen und Tabellendaten zu reproduzieren. Das Dienstprogramm mysqldump kann auch eine Ausgabe im CSV-Format, in anderem durch Trennzeichen getrennten Text oder im XML-Format generieren. Der Hauptvorteil dieses Ausgabeformats besteht darin, dass Sie die Exportausgabe vor der Wiederherstellung anzeigen oder bearbeiten können, da es sich um eine Textdatei handelt. Der Hauptnachteil hingegen besteht darin, dass es nicht als schnelle oder skalierbare Lösung zum Sichern großer Datenmengen gedacht ist.
Verwendung von mysqldump:
-- Single database backup & specific tables backup # mysqldump database_name > outpitfile.sql # mysqldump database_name tbl1 tbl2 > outpitfile.sql -- Back up all databases # mysqldump --all-databases > all_databases.sql -- Ignore a given table # mysqldump --databases db1 --ignore-table db1.tbl > outpitfile.sql -- Back up metadata only - Schema only # mysqldump --no-data db1 > bck.sql -- Include stored procedures and functions (routines) # mysqldump db1 --routines > db1.sql -- Back up only rows by a given WHERE condition # mysqldump db1 tbl1 --where="col1=1" > bck.sql -- Include triggers for each dumped table (default) # mysqldump db1 tbl1 —triggers > bck.sql
mysqlimport:
Dies ist ein Clientprogramm, das eine Befehlszeile als Schnittstelle zur SQL-Anweisung LOAD
DATA INFILE bietet. mysqlimport wird häufig verwendet, um Daten aus Text- oder CSV-Dateien in eine MySQL-Tabelle mit einer entsprechenden Struktur zu importieren.
Oracle SQL*Loader kann in mysqlimport konvertiert werden, da die Funktionsweise zum Laden von Daten aus einer externen Datei bei beiden Programmen identisch ist.
Verwendung von mysqlimport:
-- Example of loading data from a CSV file into a table:
-- Create a table named csv_file
mysql> create table file(col1 int, col2 varchar(10));
-- Create a CSV file (delimited by tab)
# echo 1 A > file.csv
# echo 2 B >> file.csv
# echo 3 C >> file.csv
-- Import the CSV file into the csv_file table
-- Note that the file and table name must be named identically
# mysqlimport -u USER -p -h HOSTNAME/IP DB_NAME --local file.csv
csv_file: Records: 3 Deleted: 0 Skipped: 0 Warnings: 0
-- Verify
# mysql -u USER -p -h HOSTNAME/IP DB_NAME -e "SELECT * FROM file"
+------+------+
| col1 | col2 |
+------+------+
| 1 | A |
| 2 | B |
| 3 | C |
+------+------+
-- Example of using LOAD DATA INFILE to load a CSV file (using the same
table from the previous example, with the CSV delimiter defined by
comma)
mysql> LOAD DATA LOCAL INFILE 'file.csv' INTO TABLE file
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n' (col1, col2);
mysql> SELECT * FROM file;
+------+------+
| col1 | col2 |
+------+------+
| 1 | A |
| 2 | B |
| 3 | C |
+------+------+
Export/Import aus/in Cloud SQL for MySQL:
In der folgenden verlinkten Dokumentation wird gezeigt, wie Sie die gcloud-CLI verwenden, um mit der Cloud SQL-Instanz und mit Cloud Storage zu interagieren, um Export- und Importvorgänge durchzuführen.
Auf Instanzebene sichern und wiederherstellen
Die Migration von Oracle RMAN oder DataPump ist einfach und Sie können in Cloud SQL for MySQL zusätzliche Sicherungs- und Wiederherstellungsoptionen hinzufügen (z. B. VM-Snapshots, Cold Backups oder Drittanbietertools). Es sind weder Code noch zusätzliche Kenntnisse erforderlich. Sie können diesen Prozess über die Google Cloud Console oder die Google Cloud CLI verwalten. (Die vorstehenden Beispiele wurden mit Cloud SQL-Instanzen der zweiten Generation kompiliert.)
MySQL-Datenbanksicherungsmethoden sind On-Demand-Sicherungen und automatische Sicherungen.
Sie können die Wiederherstellung von Cloud SQL for MySQL-Datenbankinstanzen verwenden, um Daten auf derselben Instanz wiederherzustellen, indem die vorhandenen Daten überschrieben werden, oder auf einer anderen Instanz wiederherzustellen. Mit Cloud SQL for MySQL können Sie auch mithilfe von Binär-Logging mit aktivierter automatischer Sicherungsoption eine MySQL-Datenbank auf den Stand eines bestimmten Zeitpunkts wiederherstellen.
Cloud SQL for MySQL bietet die Möglichkeit, eine unabhängige Version der Quelldatenbank zu klonen. Dieses Feature gilt nur für die primäre (Master-)Datenbank oder einen anderen Klon und kann nicht aus einer Instanz mit Lesereplikat übernommen werden. Sie können dieses Feature auch verwenden, um eine MySQL-Instanz auf dem Stand eines bestimmten Zeitpunkts wiederherzustellen und so bei Bedarf die Datenwiederherstellung zu ermöglichen. Sie können die Wiederherstellung von Cloud SQL for MySQL-Datenbanken mithilfe der Google Cloud Console oder der gcloud CLI vornehmen.
MySQL-Ereignisplaner (Datenbankjobs)
Die Funktionsweise zum Starten vordefinierter Datenbankvorgänge des MySQL-Ereignisplaners entspricht der von Oracle DBMS_JOBS oder Oracle DBMS_SCHEDULER. Der Datenbankparameter event_scheduler ist standardmäßig auf OFF festgelegt. Bei Bedarf kann dieser mithilfe von Cloud SQL-Flags auf ON umgestellt werden.
Sie können den MySQL-Ereignisplaner verwenden, um einen expliziten DML/DDL-Befehl auszuführen oder ein gespeichertes Verfahren bzw. eine gespeicherte Funktion für eine bestimmten Zeit und mit einer bestimmten Logik zu planen.
Hinweis zur Konvertierung von Oracle DBMS_JOBS oder DBMS_SCHEDULER:
Alle Oracle-Jobs müssen manuell oder mit handelsüblichen PL/SQL-Konvertierungstools für die Syntax und Funktionsweise von MySQL konvertiert werden.
Verwenden Sie die folgende Anweisung, um den aktuellen Parameterwert event_scheduler aus einer Clientausführung zu prüfen:
mysql> SHOW VARIABLES LIKE '%event_s%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| event_scheduler | ON |
+-----------------+-------+
Beispiele für den Ereignisplaner:
Oracle DBMS_SCHEDULER
SQL> BEGIN DBMS_SCHEDULER.CREATE_JOB ( job_name => 'job_sessions_1d_del', job_type => 'PLSQL_BLOCK', job_action => 'BEGIN DELETE FROM sessions WHERE session_date < SYSDATE - 1; END;', start_date => SYSTIMESTAMP, repeat_interval => 'FREQ=DAILY', end_date => NULL, enabled => TRUE, comments => 'Deletes last day data from the sessions table'); END; /MySQL EVENT-Umwandlung:
mysql> CREATE EVENT job_sessions_1d_del ON SCHEDULE EVERY 1 DAY COMMENT 'Deletes last day data from the sessions table' DO DELETE FROM sessions WHERE session_date < DATE_SUB(SYSDATE(), INTERVAL 1 DAY);Metadaten des MySQL-Ereignisplaners:
mysql> SELECT * FROM INFORMATION_SCHEMA.EVENTS \G; -- OR mysql> SHOW EVENTS FROM HR;
Standby-Instanzen für schreibgeschützte Vorgänge und die Implementierung der Notfallwiederherstellung
Mit Oracle Active Data Guard kann eine Standby-Instanz als schreibgeschützter Endpunkt dienen, während neue Daten weiterhin über die Redo- und Archivierungslogs angewendet werden. Sie können auch Oracle GoldenGate verwenden, um eine zusätzliche Instanz mit Lesezugriff zu aktivieren, während Datenänderungen in Echtzeit angewendet werden. Dies dient als CDC-Lösung (Change Data Capture).
Cloud SQL for MySQL unterstützt die Lese-/Schreibtrennung durch die Verwendung von Lesereplikaten, um Lesevorgänge oder analytische Arbeitslasten von einer primären Quelle nahezu in Echtzeit an eine alternative replizierte Quelle weiterzuleiten. Sie können die Einstellungen für Cloud SQL for MySQL-Lesereplikate in der Google Cloud Console oder über die gcloud CLI anwenden.
Cloud SQL for MySQL unterstützt zusätzliche Replikationsoptionen: die Replikation auf eine externe MySQL-Instanz und die Replikation von einer externen MySQL-Instanz.
Sie können Oracle Active Data Guard und Oracle GoldenGate als Notfallwiederherstellungslösung implementieren. Fügen Sie hierfür eine Standby-Instanz hinzu, die bereits mit der primären Instanz synchronisiert ist.
Lesereplikate von Cloud SQL for MySQL sind nicht als Standby-Instanzen für die Notfallwiederherstellung konzipiert. Cloud SQL bietet zu diesem Zweck die Möglichkeit, eine MySQL-Instanz für Hochverfügbarkeit zu konfigurieren (über die Google Cloud Console oder die gcloud CLI).
Für einige Vorgänge ist möglicherweise ein Neustart der Instanz erforderlich, z. B. wenn Hochverfügbarkeit an einer vorhandenen primären Instanz aktiviert werden soll. Wenn die primäre Instanz aus Sicht eines Hochverfügbarkeits-SLA etwa 60 Sekunden lang nicht reagiert, ist die hochverfügbare Standby-Instanz nach dem erneuten Verbinden verfügbar. Informationen zum Aktivieren der Hochverfügbarkeit in Cloud SQL for MySQL finden Sie in der folgenden Anleitung.
Logging und Monitoring
Die Warn-Logdatei von Oracle ist die Hauptquelle für die Identifizierung allgemeiner System- und Fehlerereignisse. Sie ist hilfreich, um den Lebenszyklus von Oracle-Datenbankinstanzen zu verstehen und enthält hauptsächlich Ereignisse fehlgeschlagener Fehlerbehebungen und Fehlerereignisse.
Das Oracle-Benachrichtigungslog enthält Informationen zu Folgendem:
- Fehler und Warnungen von Oracle-Datenbankinstanzen (
ORA-+ Fehlernummer) - Ereignisse beim Starten und Herunterfahren einer Oracle-Datenbankinstanz
- Netzwerk- und Verbindungsprobleme
- Änderungsereignisse in Redo-Logs von Datenbanken
- Oracle-Trace-Dateien können mit einem Link zu weiteren Details zu einem bestimmten Datenbankereignis erwähnt werden.
Darüber hinaus bietet Oracle dedizierte Logdateien für verschiedene Dienste wie LISTENER, ASM und Enterprise Manager (OEM), für die es in Cloud SQL for MySQL keine entsprechenden Komponenten gibt.
Logtypen in Cloud SQL for MySQL:
| MySQL-Logtyp | Beschreibung | Hinweise |
|---|---|---|
| Aktivitäts-Log | Enthält Daten zu API-Aufrufen oder anderen administrativen Vorgängen, die die Konfiguration oder Metadaten einer Cloud SQL for MySQL-Instanz ändern. | Dieses Log ist eines der drei Logs in der Cloud-Audit-Log-Gruppe. |
| Datenzugriffslog | Enthält Daten zu API-Aufrufen, die die Konfiguration oder Metadaten von Ressourcen lesen, sowie nutzergesteuerte API-Aufrufe, mit denen vom Nutzer bereitgestellte Ressourcendaten erstellt, geändert oder gelesen werden. | Dieses Log ist eines der drei Logs in der Cloud-Audit-Log-Gruppe. In diesem Log werden nur Datenzugriffe auf MySQL-Instanzen für Ereignisse aufgezeichnet, auf die ohne Anmeldung in Google Cloud zugegriffen werden kann. |
mysql.err |
Dies ist die primäre MySQL-Logdatei , die mit dem Benachrichtigungslog von Oracle vergleichbar ist. Beide Logs enthalten Ereigniseinträge von Datenbankinstanzen, wie das Hoch- und Herunterfahren sowie Fehler und Warnungen. | Leitfaden zu Fehlermeldungen in MySQL 5.7 |
mysql-slow.log |
Das langsame MySQL-Abfragelog erfasst Daten zu Abfragen, die die vordefinierte Konfiguration überschreiten, z. B. Abfragen mit einer Laufzeit von mehr als 2 Sekunden (Standardwert ist 10 Sekunden). | Standardmäßig deaktiviert. Legen Sie zum Aktivieren dieses Logs die folgenden Variablen (Datenbankparameter) fest:
|
mysql-general.log |
Dieses Log erfasst Daten zu aufgebauten und getrennten Clientverbindungen sowie zu allen SQL-Anweisungen, die auf der MySQL-Datenbankinstanz ausgeführt werden. Dieses Log ist für die Fehlerbehebung nützlich und wird in der Regel nach Abschluss des Vorgangs auf OFF gesetzt. |
Standardmäßig deaktiviert, zum Aktivieren die Variablen general_log auf ON setzen. |
| Binäres Log | Der MySQL-Server verwendet das binäre Logging, um alle Anweisungen zu protokollieren, mit denen Daten geändert wurden. Dieses Log wird hauptsächlich für Sicherungen und Replikate verwendet. | Der Parameter für das binäre Logging ist in Cloud SQL for MySQL standardmäßig aktiviert, um die Wiederherstellung und die Bereitstellung von Lesereplikaten zu ermöglichen.
Setzen Sie zum Aktivieren des binären Loggings den Konfigurationsparameter log_bin auf ON. |
| Relay-Log | Enthält Anweisungen, die von den binären Logs der primären Instanz empfangen wurden, um alle Datenänderungen auf der untergeordneten Instanz (Lesereplikat) zu übernehmen | Gilt nur für sekundäre (untergeordnete) Instanzen und Lesereplikate |
Vorgangslogs von Cloud SQL für MySQL ansehen
Die Hauptplattform für die Anzeige aller Logdetails ist Cloud Logging. Sie können verschiedene Logs auswählen und nach der Ebene des Logereignisses filtern (z. B. "Kritisch", "Fehler" oder "Warnung"). Außerdem können die Ereignisse nach Zeiträumen und mit freier Texteingabe gefiltert werden.
Beispiel
Der folgende Screenshot zeigt, wie Sie in der Datei mysql-slow.log eine bestimmte Abfrage mithilfe eines benutzerdefinierten Zeitraums als Filterkriterium finden.
Monitoring einer MySQL-Datenbankinstanz
Die wichtigsten Monitoring-Dashboards von Oracle sind Bestandteile der OEM- und Grid/Cloud Control-Produkte (z. B. Top Activity Graphs) und nützlich für das Echtzeit-Monitoring von Datenbankinstanzen auf Sitzungs- oder SQL-Anweisungsebene. Cloud SQL for MySQL bietet ähnliche Monitoring-Funktionen über die Google Cloud Console. Sie können zusammengefasste Informationen zu den Datenbankinstanzen von Cloud SQL for MySQL mit mehreren Monitoringmesswerten anzeigen lassen, wie CPU-Auslastung, Speichernutzung, Arbeitsspeicherauslastung, Lese-/Schreibvorgänge, eingehende/ausgehende Byte, aktive Verbindungen und mehr.
Cloud Logging unterstützt zusätzliche Monitoringmesswerte für Cloud SQL for MySQL. Der folgende Screenshot zeigt ein Diagramm der MySQL-Abfragen der letzten 12 Stunden.
Monitoring eines MySQL-Lesereplikats
Sie können Lesereplikate auf ähnliche Weise wie eine primäre Instanz überwachen. Verwenden Sie dazu die Monitoring-Messwerte der Google Cloud Console (wie oben beschrieben). Darüber hinaus gibt es einen dedizierten Monitoring-Messwert zum Überwachen der Replikationsverzögerung. Dieser gibt Auskunft über die Zeitverzögerung zwischen der primären Instanz und der Instanz des Lesereplikats in Sekunden (kann in der Google Cloud Console im Tab mit der Übersicht zur Lesereplikat-Instanz überwacht werden).
Mit der gcloud CLI können Sie den Replikationsstatus abrufen:
gcloud sql instances describe REPLICA_NAME
Das Monitoring der Replikate ist auch mithilfe von Befehlen in einem MySQL-Client möglich, der einen Status für die primären und die untergeordneten Datenbanken sowie für das Binär- und Relay-Log bereitstellt.
Mit der folgenden SQL-Anweisung können Sie den Status des Lesereplikats prüfen:
mysql> SHOW SLAVE STATUS;
MySQL-Monitoring
In diesem Abschnitt werden grundlegende MySQL-Monitoringmethoden beschrieben, die als Routineaufgaben von einem DBA (Oracle oder MySQL) ausgeführt werden.
Monitoring einer Sitzung
Die Sitzungsüberwachung in Oracle erfolgt durch Abfrage der dynamischen Leistungsansichten, die als "V$-Ansichten" bezeichnet werden. Die Ansichten V$SESSION und V$PROCESS werden in der Regel verwendet, um mithilfe von SQL-Anweisungen Echtzeitinformationen zur aktuellen Datenbankaktivität abzurufen. In MySQL können Sie die Sitzungsaktivitäten mithilfe von Befehlen und SQL-Anweisungen überwachen. Der MySQL-Befehl SHOW PROCESSLIST stellt beispielsweise die folgenden Details zur Sitzungsaktivität bereit:
mysql> SHOW PROCESSLIST;
Sie können die Ergebnisse von SHOW PROCESSLIST auch mit einer SELECT-Anweisung abfragen und filtern:
mysql> SELECT * FROM information_schema.processlist;
Monitoring einer langen Transaktion
Wenn Sie in Echtzeit lange andauernde Transaktionen identifizieren möchten, die zu Leistungsproblemen führen können, können Sie die dynamische Ansicht information_schema.innodb_trx abfragen. In dieser Ansicht werden nur Datensätze offener Transaktionen angezeigt, die auf der MySQL-Datenbankinstanz ausgeführt werden.
Sperrungsmonitoring
Datenbanksperrungen können Sie mit der dynamischen Ansicht information_schema.innodb_locks überwachen. In dieser Ansicht werden Echtzeitinformationen zu Sperrvorgängen angezeigt, die zu Leistungsproblemen führen können.