Looker-Backend-Datenbank zu MySQL migrieren

Standardmäßig verwendet Looker eine speicherresidente HyperSQL-Datenbank zum Speichern der Konfiguration, der Nutzer und anderer Daten. Auf einer stark ausgelasteten Instanz kann diese Datenbank mehrere Gigabyte groß werden, was zu Leistungsproblemen, Java-Speicherbelastung und langen Startzeiten führen kann.

Bei einer vom Kunden gehosteten Instanz empfehlen wir, die HyperSQL-Datenbank durch ein vollständiges MySQL-Datenbank-Backend zu ersetzen, wenn die interne HyperSQL-Datenbank eine Größe von 600 MB überschreitet. So prüfen Sie die Größe der HyperSQL-Datenbank:looker.script

cd looker
cd .db
ls -lah

Wenn die Datei looker.script größer als 600 MB ist, folgen Sie der Anleitung unten, um zu einer externen MySQL-Datenbank zu migrieren.

Hinweis: Bei diesem Verfahren wird von einem Deployment in AWS EC2 ausgegangen. Bei lokalen Bereitstellungen sollten die Systeme vergleichbar mit den entsprechenden AWS-Instanzen dimensioniert werden. Wenn Sie Looker aktualisieren und zu MySQL migrieren, empfehlen wir, das Looker-Update vor der Migration zu MySQL durchzuführen.

MySQL-Instanz und ‑Nutzer bereitstellen

Sie können eine MySQL 8.4.X-Instanz (empfohlen) oder eine MySQL 8.0.X-Instanz als Backend bereitstellen. MySQL-Versionen vor 8.0 werden nicht unterstützt.

Looker 26.6 und höher unterstützt MySQL 8.4.X für die Looker-Backend-Datenbank. Für vom Kunden gehostete Instanzen, die MySQL 8.0.X für die Looker-Backend-Datenbank verwenden, wird empfohlen, auf MySQL 8.4.X zu aktualisieren, sobald Sie Ihre Looker-Instanz auf Version 26.6 oder höher aktualisieren.

In AWS RDS reicht eine Instanz der Klasse db.m5.large wahrscheinlich als Backend für eine einzelne Looker-Instanz aus. Auch wenn die tatsächliche Nutzung der Datenbank wahrscheinlich im Bereich von 5 bis 10 GB liegt, ist es ratsam, 100 bis 150 GB SSD-Speicher bereitzustellen, da die bereitgestellten IOPS auf der angeforderten Speichermenge basieren.

MySQL 8.4.X

Ab Looker 26.6 wird MySQL 8.4.X als interne Datenbank unterstützt. Für MySQL 8.4.X können Sie eines der folgenden MySQL-Authentifizierungs-Plug-ins verwenden, wie in den folgenden Abschnitten beschrieben:

• caching_sha2_password
• mysql_native_password

Hinweis :Wenn Sie das Looker-Backend von MySQL 8.0.X auf MySQL 8.4.X aktualisieren, können Sie den Datenbanknutzer beibehalten, den Sie für MySQL 8.0.X erstellt haben. Bei MySQL 8.0.X müssen sich Datenbanknutzer jedoch mit mysql_native_password authentifizieren. Wenn Sie den Datenbanknutzer aus MySQL 8.0.X behalten möchten, folgen Sie der Anleitung zum Bereitstellen von MySQL 8.4.X mit mysql_native_password, damit sich Ihr vorhandener Nutzer weiterhin authentifizieren kann. Wenn Sie andernfalls einen neuen Nutzer erstellen möchten, wenn Sie MySQL 8.4.X bereitstellen, können Sie die MySQL-Instanz bereitstellen und einen neuen Nutzer mit dem Authentifizierungs-Plug-in caching_sha2_password oder mysql_native_password erstellen.

caching_sha2_password verwenden

In MySQL 8.4.X ist caching_sha2_password das standardmäßige Authentifizierungs-Plug-in. Es gibt zwei Möglichkeiten, das caching_sha2_password-Plug-in in Looker zu verwenden:

1. Bei Verwendung einer SSL-Verbindung für die interne Datenbank:Es ist kein öffentlicher RSA-Schlüssel erforderlich. Looker stellt mit den angegebenen Nutzeranmeldedaten eine sichere Verbindung zur Datenbank her. Informationen zum Einrichten einer SSL-Verbindung zu Ihrer Datenbank finden Sie auf dieser Seite im Abschnitt Datei mit Datenbankanmeldedaten erstellen.
2. Wenn keine Verbindung mit aktivierter SSL hergestellt wird:Looker verwendet standardmäßig die Option --get-server-public-key, um eine Verbindung zur internen Datenbank herzustellen, wenn das caching_sha2_password-Plug-in vom Nutzerkonto verwendet wird, das für Looker bereitgestellt wird. Sorgen Sie dafür, dass die Netzwerkumgebung geschützt ist, wenn SSL nicht aktiviert ist.

Hinweis :Die Angabe einer lokalen Datei als öffentlicher RSA-Schlüssel für die Verbindung wird von Looker nicht unterstützt.

Richten Sie den Nutzer für beide Arten der Verwendung des caching_sha2_password-Plug-ins mit der folgenden Anweisung ein:

CREATE USER 'DB_username' IDENTIFIED WITH caching_sha2_password BY 'password';

Ersetzen Sie Folgendes:

• DB_username: Nutzername
• password: ein eindeutiges, sicheres Passwort

mysql_native_password verwenden

Looker verwendet das mysql_native_password-Plug-in, um sich über den JDBC-Treiber in MySQL-Datenbanken zu authentifizieren. Damit MySQL 8.4.X mit dem mysql_native_password-Plug-in funktioniert, müssen Sie die folgenden zusätzlichen Schritte ausführen:

1. Konfigurieren Sie die MySQL-Datenbank, um das mysql_native_password-Plug-in zu aktivieren. Dafür gibt es verschiedene Vorgehensweisen, die je nach Bereitstellungsvariante der MySQL-Datenbank und Art der Zugriffsberechtigung variieren:

   1. Starten Sie den MySQL-Server mit --mysql-native-password=ON.

   2. Legen Sie das Attribut in der Konfigurationsdatei my.cnf fest:

      [mysqld]
      mysql_native_password=ON
      

   3. Wenn die MySQL-Instanz auf Google Cloud, AWS oder Azure gehostet wird, sollte das mysql_native_password-Plug-in automatisch aktiviert werden. Eine detaillierte Anleitung finden Sie in der Dokumentation Ihres Anbieters.

2. Erstellen Sie den Nutzer:

   CREATE USER 'DB_username' IDENTIFIED WITH mysql_native_password BY 'password';
   

   Ersetzen Sie Folgendes:

   • DB_username: Nutzername
   • password: ein eindeutiges, sicheres Passwort

MySQL 8.0.X

In MySQL 8.0.X ist caching_sha2_password das standardmäßige Authentifizierungs-Plug-in. Looker verwendet das mysql_native_password-Plug-in, um die Authentifizierung über den JDBC-Treiber in der MySQL-Datenbank zu versuchen. Damit MySQL 8.0.X ordnungsgemäß funktioniert, müssen Sie die folgenden zusätzlichen Schritte ausführen:

1. Konfigurieren Sie die MySQL-Datenbank für die Verwendung des mysql_native_password-Plug-ins. Dafür gibt es verschiedene Vorgehensweisen, die je nach Bereitstellungsvariante der MySQL 8-Datenbank und Art der Zugriffsberechtigung variieren:

   • Starten Sie den Prozess mit dem Flag --default-auth=mysql_native_password.

   • Legen Sie das Attribut in der Konfigurationsdatei my.cnf fest:

     [mysqld]
     default-authentication-plugin=mysql_native_password
     

   • Wenn die Datenbankinstanz durch AWS RDS gehostet wird, können Sie den default_authentication_plugin-Parameter durch die Anwendung einer RDS Parameter Group auf die Datenbankinstanz bestimmen.

2. Erstellen Sie den Nutzer:

   CREATE USER 'DB_username' IDENTIFIED WITH mysql_native_password BY 'password';
   

   Ersetzen Sie Folgendes:

   • DB_username: Nutzername
   • password: ein eindeutiges, sicheres Passwort

MySQL optimieren

Passen Sie die folgenden Einstellungen für Ihre MySQL-Instanz an.

Maximale Paketgröße erhöhen

Die Standardgröße von max_allowed_packet in MySQL ist für die Datenbankmigration zu klein und kann dazu führen, dass die Migration mit dem Fehler PACKET_TOO_LARGE fehlschlägt. Legen Sie max_allowed_packet auf den zulässigen Höchstwert von 1073741824 fest:

max_allowed_packet = 1073741824

Algorithmus für temporäre Tabelle festlegen

In MySQL 8 werden interne temporäre Tabellen anders als in früheren Versionen verarbeitet. Die Standardeinstellungen können Probleme beim Ausführen einiger der für Looker erforderlichen Abfragen verursachen, insbesondere bei Looker-Instanzen mit vielen Nutzern und Projekten. Wir empfehlen, die folgende globale Servereinstellung festzulegen:

internal_tmp_mem_storage_engine = MEMORY

Zeichensätze konfigurieren

Legen Sie die folgenden Standardparameter fest, um UTF8mb4 zu verwenden, das UTF8-Zeichensätze unterstützt. Weitere Informationen finden Sie im Artikel In MySQL, never use "utf8". Weitere Informationen dazu, warum wir die Verwendung von UTF8mb4 (nicht UTF8) mit MySQL empfehlen, finden Sie unter UTF8mb4 verwenden.

character_set_client = utf8mb4
character_set_results = utf8mb4
character_set_connection = utf8mb4
character_set_database = utf8mb4
character_set_server = utf8mb4
collation_connection = utf8mb4_general_ci
collation_server = utf8mb4_general_ci

Bei Amazon RDS-Instanzen wenden Sie diese Einstellung an, indem Sie eine Parametergruppe erstellen oder ändern und die entsprechenden Einstellungen bearbeiten. Wir empfehlen, die aktuelle Parametergruppe zu kopieren und die Änderungen an der Kopie vorzunehmen, insbesondere wenn Sie Parametergruppen für mehrere RDS-Instanzen freigeben. Nachdem Sie die Parametergruppe gespeichert haben, wenden Sie sie auf die RDS-Instanz an. Möglicherweise ist ein Neustart erforderlich.

Replikat-Schema festlegen

Looker ist auf Funktionen angewiesen, die ein mixed- oder row-Binlog erfordern. Wenn Sie Ihre eigene MySQL-Instanz hosten, legen Sie binlog_format mit einem der folgenden Befehle auf mixed oder row fest:

SET GLOBAL binlog_format = 'MIXED';

oder

SET GLOBAL binlog_format = 'ROW';

Datenbank erstellen und Nutzerberechtigungen erteilen

Erstellen Sie eine Datenbank in der Datenbankinstanz:

create database DB_name default character set DB_charset default collate DB_collation;

Erteilen Sie dann Berechtigungen für den Nutzer, den Sie beim Bereitstellen der MySQL-Instanz und des Nutzers erstellt haben:

grant all on DB_name.* to 'DB_username'@'%';
grant all on looker_tmp.* to 'DB_username'@'%';

Ersetzen Sie Folgendes:

• DB_name: Datenbankname
• DB_charset: Der Zeichensatz, der den Einstellungen der RDS-Instanzparametergruppe entspricht. Für echten UTF8-Support empfehlen wir utf8mb4.
• DB_collation: Die Sortierung, die den Einstellungen der RDS-Instanzparametergruppe entspricht. Für echte UTF8-Unterstützung empfehlen wir utf8mb4_general_ci.
• DB_username: Nutzername

Die looker_tmp-Datenbank in der letzten Zeile muss nicht tatsächlich vorhanden sein, aber die grant-Anweisung ist für interne Berichte erforderlich.

Datei mit Datenbankanmeldedaten erstellen

Looker muss wissen, mit welcher MySQL-Datenbank kommuniziert werden soll und welche Anmeldedaten verwendet werden sollen. Erstellen Sie im Looker-Verzeichnis eine Datei namens looker-db.yml mit folgendem Inhalt. Ersetzen Sie dabei DB_hostname, DB_username, DB_password und DB_name durch Werte für Ihre Datenbank:

dialect: mysql_8
host: DB_hostname
username: DB_username
password: DB_password
database: DB_name
port: 3306

Wenn für Ihre MySQL-Datenbank eine SSL-Verbindung erforderlich ist, fügen Sie looker-db.yml die folgende Zeile hinzu:

ssl: true

Wenn Sie auch die Überprüfung des SSL-Zertifikats aktivieren möchten, fügen Sie looker-db.yml die folgende Zeile hinzu:

verify_ssl: true

Optional können Sie auch alle anderen zusätzlichen JDBC-Parameter angeben, die vom MariaDB-JDBC-Treiber unterstützt werden, indem Sie jdbc_additional_params hinzufügen. Wenn Sie beispielsweise eine bestimmte Trust Store-Datei verwenden müssen, können Sie dem MySQL JDBC-Verbindungsstring den folgenden Parameter hinzufügen:

jdbc_additional_params: trustStore=/path/to/my/truststore.jks&keyStore=/path/to/my/keystore.jks

Bei von Kunden gehosteten Installationen können Sie optional die maximale Anzahl der Verbindungen angeben, die Looker mit Ihrer Datenbank herstellen kann, indem Sie max_connections hinzufügen. Wenn Sie beispielsweise die Anzahl der gleichzeitigen Verbindungen zu Ihrer Datenbank auf 10 begrenzen möchten, fügen Sie Folgendes hinzu:

max_connections: 10

Wichtig :Beachten Sie die Best Practices für die Sicherheit, wenn Sie Anmeldedaten in einer Datei speichern. Idealerweise legen Sie die Berechtigungen für die Datei looker-db.yml auf 600 fest. Die Datei sollte dem Linux-Nutzerkonto gehören, unter dem die Looker-Anwendung ausgeführt wird. Diese Datei sollte niemals in ein Git-Repository eingecheckt werden.

Gemäß dem Verschlüsselungsschema von Looker werden alle sensiblen Daten in der Datenbank im Ruhezustand verschlüsselt. Selbst wenn jemand Zugriff auf Klartext-Datenbankanmeldedaten erhält und auf die Datenbank zugreift, verschlüsselt oder hasht Looker sensible Daten, bevor sie gespeichert werden. Das gilt für Elemente wie Passwörter, Anmeldedaten für die Analysedatenbank und den Abfragecache. Wenn Sie das Klartextpasswort für diese Konfiguration jedoch nicht in der Datei looker-db.yml auf dem Laufwerk speichern möchten, können Sie die Umgebungsvariable LOOKER_DB so konfigurieren, dass sie eine Liste von Schlüsseln und Werten für jede Zeile in der Datei looker-db.yml enthält. Beispiel:

export LOOKER_DB="dialect=mysql_8&host=localhost&username=root&password=&database=looker&port=3306"

Wichtig: Beschränken Sie die Verwendung Ihres MySQL-Nutzerkontos auf die IP-Adresse, die von Ihrem Looker-Server verwendet wird.

Sichern Sie das Verzeichnis .db.

Sichern Sie das Verzeichnis .db, das die Dateien enthält, die zum Erstellen der In-Memory-HyperSQL-Datenbank erforderlich sind, falls Sie HyperSQL wiederherstellen müssen:

cp -r .db .db-backup
tar -zcvf db-backup.tar.gz ./.db-backup

Datenbank migrieren

Die Migration der Datenbank zu MySQL kann auf einer mittelgroßen oder großen Instanz Stunden dauern, insbesondere wenn die HyperSQL-Datenbank mindestens 1 GB groß ist. Wir empfehlen, die EC2-Instanz während der Migration vorübergehend auf m5.2xlarge zu aktualisieren (mit 32 GB RAM, um den in den Schritten angegebenen Heap von 26 GB zu ermöglichen). Dadurch wird die erforderliche Zeit auf etwa 10 Minuten verkürzt.

1. Auf dem Looker-Host:

   cd looker
   ./looker stop
   vi looker
   

2. Fügen Sie im Looker-Startscript eine neue zweite Zeile in die Datei ein:

   exit
   

3. Stoppen Sie die Instanz in der AWS-Konsole. Wenn die Instanz beendet ist, ändern Sie die EC2-Instanzgröße in m5.2xlarge. Starten Sie die Instanz dann wieder.

4. Stellen Sie eine SSH-Verbindung zum Host als Looker-Nutzer her. Prüfen Sie zuerst, ob Java ausgeführt wird, und führen Sie dann Folgendes aus:

   cd looker
   java -Xms26000m -Xmx26000m -jar looker.jar migrate_internal_data  looker-db.yml
   

   Wenn Sie den Schritt migrate_internal_data ausführen, wird libcrypt möglicherweise nicht gefunden und es wird ein Stacktrace angezeigt, der mit Folgendem beginnt:

   NotImplementedError: getppid unsupported or native support failed to load
   ppid at org/jruby/RubyProcess.java:752
   ppid at org/jruby/RubyProcess.java:749
   

   Wenn dies der Fall ist, legen Sie LD_LIBRARY_PATH manuell fest, bevor Sie den Java-Befehl ausführen:

   export LD_LIBRARY_PATH=$HOME/looker/.tmp/:$LD_LIBRARY_PATH
   

5. Wenn der Vorgang abgeschlossen ist, beenden Sie die Instanz über die AWS-Konsole.

6. Sie können die Instanz jetzt auf ihre ursprüngliche Größe zurücksetzen.

7. Starten Sie die Instanz noch einmal.

Looker starten

1. Bearbeiten Sie das Looker-Startskript und löschen Sie die zuvor hinzugefügte Zeile exit.

2. Achten Sie darauf, dass im Startskript keine Argumente in LOOKERARGS definiert sind. Stattdessen sollten alle Argumente in die lookerstart.cfg-Datei verschoben werden, damit sie nicht durch neue Versionen des Startskripts überschrieben werden. Speichern Sie das Startskript und beenden Sie es.

3. lookerstart.cfg bearbeiten Dies sollte in etwa wie folgt aussehen:

   LOOKERARGS="-d looker-db.yml"
   

   Wenn das Looker-Startskript weitere Argumente enthielt, fügen Sie sie der Datei lookerstart.cfg hinzu.

4. Archivieren Sie das Verzeichnis .db, falls es noch nicht archiviert ist.

   mv .db .db-backup
   tar -zcvf db-backup.tar.gz ./.db-backup
   rm -rf ./.db-backup/
   

5. Looker starten:

   ./looker start
   

Prüfen, ob Looker die neue Datenbank verwendet

Wenn Looker das Backend-MySQL erfolgreich verwendet, sollten Netzwerkverbindungen zwischen der Looker-Instanz und der neuen Datenbankinstanz zu sehen sein. Führen Sie zur Überprüfung den folgenden Befehl in der Looker-Instanz aus:

netstat -na | grep 3306

Sie sollten einige Verbindungen zur Datenbankinstanz sehen. Im Folgenden finden Sie eine Beispielausgabe für eine Datenbankinstanz mit der IP-Adresse 10.0.3.155:

looker@instance1:~$ netstat -na | grep 3306
tcp6       0      0 10.0.5.131:56583        10.0.3.155:3306         ESTABLISHED
tcp6       0      0 10.0.5.131:56506        10.0.3.155:3306         ESTABLISHED
tcp6       0      0 10.0.5.131:56582        10.0.3.155:3306         ESTABLISHED
tcp6       0      0 10.0.5.131:56508        10.0.3.155:3306         ESTABLISHED

Looker sichern

Nach der Migration zu einem MySQL-Backend funktionieren die automatischen S3-Sicherungen von Looker nicht mehr. Wir empfehlen, die MySQL-Datenbank mindestens jede Nacht zu sichern und das Looker-Arbeitsverzeichnis jede Nacht im Dateisystem zu sichern. Das Verzeichnis looker/log/ ist möglicherweise von den Dateisystem-Back-ups ausgeschlossen. Weitere Informationen finden Sie auf der Dokumentationsseite Back-ups erstellen.