Looker-Backend-Datenbank zu MySQL migrieren

Standardmäßig verwendet Looker eine speicherresidente HyperSQL-Datenbank, um die Konfiguration, Nutzer und andere Daten zu speichern. Auf einer stark ausgelasteten Instanz kann diese Datenbank mehrere Gigabyte groß werden, was zu Leistungsproblemen, Java-Arbeitsspeicherdruck und langen Startzeiten führen kann.

Auf einer vom Kunden gehosteten Instanz empfehlen wir, die HyperSQL-Datenbank durch ein vollständiges MySQL-Datenbank-Backend zu ersetzen, wenn die interne HyperSQL-Datenbank größer als 600 MB ist. So prüfen Sie die Größe der HyperSQL-Datenbank: Sehen Sie sich die Größe der Datei looker.script an:

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 dieser Anleitung wird von einem Deployment in AWS EC2 ausgegangen. Bei lokalen Deployments sollten die Systeme vergleichbar mit den entsprechenden AWS-Instanzen dimensioniert sein. Wenn Sie Looker aktualisieren und zu MySQL migrieren, empfehlen wir, das Looker-Update abzuschließen, bevor Sie die Migration zu MySQL durchführen.

MySQL-Instanz und -Nutzer bereitstellen

Sie können eine MySQL 8.4.X- (empfohlen) oder 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, empfehlen wir, auf MySQL 8.4.X zu aktualisieren, sobald Sie Ihre Looker-Instanz auf Version 26.6 oder höher aktualisieren.

In AWS RDS ist eine Instanz der Klasse db.m5.large wahrscheinlich als Backend für eine einzelne Looker-Instanz ausreichend. Obwohl die tatsächliche Nutzung der Datenbank wahrscheinlich im Bereich von 5 bis 10 GB liegen wird, ist es ratsam, 100 bis 150 GB SSD-Speicher bereitzustellen, da die bereitgestellten IOPS auf der Menge des angeforderten Speichers basieren.

MySQL 8.4.X

Looker unterstützt ab Version 26.6 die Verwendung von MySQL 8.4.X als interne Datenbank. 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 Ihr 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 von MySQL 8.0.X beibehalten möchten, folgen Sie der Anleitung, um MySQL 8.4.X mit mysql_native_password bereitzustellen, damit sich Ihr vorhandener Nutzer weiterhin authentifizieren kann. Wenn Sie beim Bereitstellen von MySQL 8.4.X einen neuen Nutzer erstellen möchten, können Sie die MySQL-Instanz bereitstellen und einen neuen Nutzer mit dem caching_sha2_password oder dem mysql_native_password Authentifizierungs-Plug-in erstellen.

caching_sha2_password verwenden

In MySQL 8.4.X ist caching_sha2_password das standardmäßige Authentifizierungs-Plug-in. Looker bietet zwei Möglichkeiten, das Plug-in caching_sha2_password 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 Anmeldedaten eine sichere Verbindung zur Datenbank her. Im Abschnitt Datei mit Anmeldedaten für die Datenbank erstellen auf dieser Seite erfahren Sie, wie Sie eine SSL-Verbindung zu Ihrer Datenbank einrichten.
2. Wenn keine Verbindung mit aktiviertem SSL hergestellt wird: Looker verwendet standardmäßig die Option --get-server-public-key, um eine Verbindung zur internen Datenbank herzustellen, wenn das Plug-in caching_sha2_password vom Nutzerkonto verwendet wird, das Looker zur Verfügung gestellt wird. Achten Sie darauf, dass die Netzwerkumgebung gesichert ist, wenn SSL nicht aktiviert ist.

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

Für beide Möglichkeiten zur Verwendung des Plug-ins caching_sha2_password richten Sie den Nutzer mit der folgenden Anweisung ein:

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

Ersetzen Sie Folgendes:

• DB_username: Nutzername
• password: eindeutiges, sicheres Passwort

mysql_native_password verwenden

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

1. Konfigurieren Sie die MySQL-Datenbank so, dass das Plug-in mysql_native_passwordaktiviert ist. 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 die Eigenschaft in der my.cnf Konfigurationsdatei fest:

      [mysqld]
      mysql_native_password=ON
      

   3. Wenn die MySQL-Instanz auf Google CloudAWS oder Azure gehostet wird, sollte das mysql_native_password Plug-in automatisch aktiviert sein. 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: 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 Plug-in mysql_native_password, um sich über den JDBC-Treiber in MySQL-Datenbanken zu authentifizieren. Damit diese Version von MySQL ordnungsgemäß funktioniert, müssen Sie die folgenden zusätzlichen Schritte durchführen:

1. Konfigurieren Sie die MySQL-Datenbank so, dass das Plug-in mysql_native_password verwendet wird. 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 die Eigenschaft in der my.cnf Konfigurationsdatei fest:

     [mysqld]
     default-authentication-plugin=mysql_native_password
     

   • Wenn die Datenbankinstanz durch AWS RDS gehostet wird, können Sie den Parameter default_authentication_plugin durch die Anwendung einer RDS-Parametergruppe 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: eindeutiges, sicheres Passwort

MySQL optimieren

Passen Sie die folgenden Einstellungen auf Ihrer MySQL-Instanz an.

Maximale Paketgröße erhöhen

Die standardmäßige max_allowed_packet Größe von MySQL ist für die Datenbankmigration zu klein und kann dazu führen, dass die Migration mit einem PACKET_TOO_LARGE Fehler fehlschlägt. Legen Sie max_allowed_packet auf den maximal zulässigen Wert 1073741824 fest:

max_allowed_packet = 1073741824

Algorithmus für temporäre Tabellen festlegen

MySQL 8 verarbeitet interne temporäre Tabellen anders als frühere Versionen. 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". Informationen dazu, warum wir die Verwendung von UTF8mb4 anstelle von UTF8 mit MySQL empfehlen, finden Sie unter Use "utf8mb4".

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

Auf 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.

Replikatschema festlegen

Looker verwendet Funktionen, 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 Nutzerberechtigung erteilen

Erstellen Sie eine Datenbank auf 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 Parametergruppe der RDS-Instanz entspricht. Für echte UTF8-Unterstützung empfehlen wir utf8mb4.
• DB_collation: Die Sortierung, die den Einstellungen der Parametergruppe der RDS-Instanz entspricht. Für echte UTF8-Unterstützung empfehlen wir utf8mb4_general_ci.
• DB_username: Nutzername

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

Datei mit Anmeldedaten für die Datenbank erstellen

Looker muss wissen, mit welcher MySQL-Datenbank kommuniziert werden soll und welche Anmeldedaten verwendet werden müssen. Erstellen Sie im Looker-Verzeichnis eine Datei mit dem Namen looker-db.yml mit dem folgenden Inhalt und ersetzen Sie 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 vom Kunden gehosteten Installationen können Sie optional die maximale Anzahl von Verbindungen angeben, die Looker mit Ihrer Datenbank herstellen kann, indem Sie max_connections hinzufügen. Wenn Sie beispielsweise die Anzahl gleichzeitiger Verbindungen zu Ihrer Datenbank auf 10 beschränken 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 und weisen sie dem Linux-Nutzerkonto zu, 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 vertraulichen Daten in der Datenbank im inaktiven Zustand verschlüsselt. Selbst wenn jemand Zugriff auf Anmeldedaten für die Datenbank im Klartext erhält und auf die Datenbank zugreift, verschlüsselt oder hasht Looker vertrauliche Daten vor dem Speichern. Dies gilt für Elemente wie Passwörter, Anmeldedaten für Analysedatenbanken und den Abfragecache. Wenn Sie das Passwort im Klartext 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.

Verzeichnis .db sichern

Sichern Sie das Verzeichnis .db, das die Dateien enthält, die zum Erstellen der speicherresidenten 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 1 GB oder mehr umfasst. Wir empfehlen, die EC2-Instanz während der Migration vorübergehend auf m5.2xlarge (mit 32 GB RAM, um den in den Schritten angegebenen Heap von 26 GB zu ermöglichen) zu aktualisieren. Dadurch wird die erforderliche Zeit auf etwa 10 Minuten reduziert.

1. Auf dem Looker-Host:

   cd looker
   ./looker stop
   vi looker
   

2. Erstellen Sie im Looker-Startskript eine neue zweite Zeile in der Datei:

   exit
   

3. Beenden Sie die Instanz in der AWS-Konsole. Ändern Sie nach dem Beenden die Größe der EC2-Instanz 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 nicht ausgeführt wird, und führen Sie dann Folgendes aus:

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

   Beim Ausführen des Schritts migrate_internal_data wird libcrypt möglicherweise nicht gefunden und ein Stacktrace wird 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
   

   In diesem Fall 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. Nachdem der Vorgang abgeschlossen ist, beenden Sie die Instanz in der AWS-Konsole.

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

7. Starten Sie die Instanz neu.

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 und beenden Sie das Startskript.

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

   LOOKERARGS="-d looker-db.yml"
   

   Wenn im Looker-Startskript weitere Argumente vorhanden waren, 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. Starten Sie Looker:

   ./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 vorhanden sein. Führen Sie dazu den folgenden Befehl auf der Looker-Instanz aus:

netstat -na | grep 3306

Sie sollten einige Verbindungen zur Datenbankinstanz sehen. Hier ein Beispiel für eine Ausgabe, die eine Datenbankinstanz mit der IP-Adresse 10.0.3.155 zeigt:

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, mindestens nächtliche Sicherungen der MySQL-Datenbank sowie nächtliche Dateisystemsicherungen des Looker-Arbeitsverzeichnisses durchzuführen. Das Verzeichnis looker/log/ kann von den Dateisystemsicherungen ausgeschlossen werden. Weitere Informationen finden Sie auf der Dokumentationsseite Sicherungen erstellen.