Sie sehen sich die Dokumentation für Looker 22.16 an. Die aktuelle Dokumentation finden Sie hier.

Back-End-Datenbank von Looker zu MySQL migrieren

Standardmäßig verwendet Looker eine HyperSQL-In-Memory-Datenbank, um seine Konfiguration, Nutzer und andere Daten zu speichern. Bei einer ausgelasteten Instanz kann diese Datenbank in der Größenordnung von mehreren Gigabyte anwachsen. Dies kann zu Leistungsproblemen, einer hohen Java-Arbeitsspeicherauslastung und langen Startzeiten führen.

Wir empfehlen, die HyperSQL-Datenbank durch ein vollständiges MySQL-Datenbank-Back-End zu ersetzen, wenn die interne HyperSQL-Datenbank 600 MB überschreitet. Prüfen Sie die Größe der Datei looker.script, um die Größe der HyperSQL-Datenbank zu prüfen:

cd looker
cd .db
ls -lah

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

Bei diesem Verfahren wird von einer Bereitstellung in AWS EC2 ausgegangen. Bei lokalen Bereitstellungen sollten die Systeme den entsprechenden AWS-Instanzen entsprechen.

Kunden, die von Looker 6.6 oder höher auf Looker 6.6 oder höher aktualisieren, können die Looker-Aktualisierung nicht gleichzeitig ausführen und zu einer MySQL-Back-End-Datenbank migrieren. Wenn Sie Looker aktualisieren und zu MySQL migrieren, sollten Sie vor der Migration zu MySQL das Looker-Update abschließen.

MySQL-Instanz bereitstellen

Stellen Sie eine MySQL 8.0.x-Instanz bereit, die als Back-End verwendet werden soll. Looker unterstützt auch die MySQL-Version 5.7.x.

MySQL-Versionen vor 5.7.x werden nicht unterstützt, da sie keine UTF8mb4-Codierung unterstützen.

In AWS RDS reicht eine Instanz der Klasse db.m5.large wahrscheinlich als Back-End für eine einzelne Looker-Instanz aus. Obwohl die tatsächliche Nutzung der Datenbank wahrscheinlich im Bereich von 5–10 GB liegt, empfiehlt es sich, 100–150 GB SSD-Speicher bereitzustellen, da die bereitgestellten IOPS auf dem angeforderten Speicherplatz basieren.

MySQL anpassen

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

max_allowed_packet = 1073741824

Legen Sie außerdem die folgenden Standardparameter zur Verwendung von UTF8mb4 fest, das UTF8-Zeichensätze unterstützt. Weitere Informationen finden Sie im Artikel In MySQL niemals "utf8" verwenden. Wenn Sie wissen möchten, warum wir für MySQL die Verwendung von UTF8mb4 statt UTF8 empfehlen, verwenden Sie "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

Bei Amazon RDS-Instanzen wenden Sie diese Einstellung an, indem Sie eine Parametergruppe erstellen oder ändern und die entsprechenden Einstellungen bearbeiten. Wir empfehlen Ihnen, die aktuelle Parametergruppe zu kopieren und die Änderungen daran 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 eine eigene MySQL-Instanz hosten, legen Sie binlog_format mit dem folgenden Befehl auf mixed oder row fest:

SET GLOBAL binlog_format = 'MIXED';

oder

SET GLOBAL binlog_format = 'ROW';

Datenbank und Nutzer erstellen

Erstellen Sie einen Nutzer und eine Datenbank auf der Datenbankinstanz. Ersetzen Sie dabei <DB_username>, <DB_name> und <DB_password> durch die tatsächlichen Werte des Nutzers und der Datenbank. Ersetzen Sie außerdem <DB_charset> und <DB_collation> durch den ausgewählten Zeichensatz und die Sortierung, die den Einstellungen der Gruppenparameterparameter für die RDS-Instanz entsprechen. Für eine echte UTF8-Unterstützung empfehlen wir utf8mb4 und utf8mb4_general_ci.

create user <DB_username>;
set password for <DB_username> = password ('<DB_password>');
create database <DB_name> default character set <DB_charset> default collate <DB_collation>;
grant all on <DB_name>.* to <DB_username>@'%';
grant all on looker_tmp.* to '<DB_username>'@'%';

Die Datenbank looker_tmp in der letzten Zeile muss nicht vorhanden sein. Für interne Berichte ist jedoch die Anweisung grant erforderlich.

Datei mit Datenbankanmeldedaten erstellen

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

dialect: mysql
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 die folgende Zeile zu looker-db.yml hinzu:

ssl: true

Wenn Sie auch die Bestätigung des SSL-Zertifikats aktivieren möchten, fügen Sie die folgende Zeile zu looker-db.yml hinzu:

verify_ssl: true

Optional können Sie noch jdbc_additional_params weitere JDBC-Parameter angeben, die vom JDBC-Treiber von MariaDB unterstützt werden. 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

Für vom Kunden gehostete Installationen können Sie optional die maximale Anzahl von Verbindungen angeben, die Looker mit Ihrer Datenbank aufbauen kann, indem Sie max_connections hinzufügen. Beispiel: Fügen Sie Folgendes hinzu, um die Anzahl der gleichzeitigen Verbindungen zu Ihrer Datenbank auf zehn zu beschränken:

max_connections: 10

Sicherheitsempfehlung: Beachten Sie beim Speichern von Anmeldedaten in einer Datei die Best Practices für die Sicherheit. Idealerweise sollten Sie die Berechtigungen für die Datei looker-db.yml auf 600 festlegen. Diese gehören dem Linux-Konto, unter dem die Looker-Anwendung ausgeführt wird. Diese Datei sollte nie in ein Git-Repository eingecheckt werden.

Beim Verschlüsselungsschema von Looker werden alle sensiblen Daten in der Datenbank verschlüsselt. Selbst wenn jemand Zugriff auf die Nur-Text-Datenbankanmeldedaten und den Zugriff auf die Datenbank erhält, verschlüsselt oder hasht Looker sensible Daten vor dem Speichern. Dies gilt für Passwörter, Anmeldedaten für die Analysedatenbank, den Abfragecache usw. 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 mit Schlüsseln/Werten für jede Zeile in der Datei looker-db.yml enthält. Beispiel:

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

Sicherheitsempfehlung: Beschränken Sie die Nutzung Ihres MySQL-Nutzerkontos auf die IP-Adresse Ihres Looker-Servers.

Verzeichnis `.db` sichern

Sichern Sie das Verzeichnis .db mit den Dateien, die zum Erstellen der speicherinternen 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 Stunden auf einer mittleren oder großen Instanz dauern, insbesondere wenn die HyperSQL-Datenbank mindestens 1 GB groß ist. Wir empfehlen Ihnen, während der Migration ein Upgrade der EC2-Instanz auf ein m5.2xlarge mit 32 GB RAM durchzuführen, um den in den Schritten angegebenen 26 GB Heap zuzulassen. Dadurch benötigen Sie etwa 10 Minuten.

Auf dem Looker-Host:

    cd looker
    ./looker stop
    vi looker

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

    exit

Beenden Sie die Instanz in der AWS-Konsole. Ändern Sie anschließend die Größe der EC2-Instanz in m5.2xlarge. Starten Sie die Instanz anschließend wieder.
Stellen Sie als Looker-Nutzer eine SSH-Verbindung zum Host her. Prüfen Sie, ob Java ausgeführt wird. Führen Sie dann folgenden Befehl aus:

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

When running the `migrate_internal_data` step, `libcrypt` may not be found and a stack trace will appear, starting with this:

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

If this happens, set the `LD_LIBRARY_PATH` manually before executing the Java command:

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

Beenden Sie anschließend die Instanz über die AWS-Konsole.
Sie können jetzt die ursprüngliche Größe der Instanz wiederherstellen.
Starten Sie die Instanz noch einmal.

Looker starten

Bearbeiten Sie das Looker-Startskript und löschen Sie die Zeile exit, die Sie zuvor hinzugefügt haben.
Achten Sie darauf, dass im Startskript keine Argumente in LOOKERARGS definiert sind. Alle Argumente sollten in die Datei lookerstart.cfg verschoben werden, damit sie nicht durch neue Versionen des Startskripts überschrieben werden. Speichern und beenden Sie das Startskript.
lookerstart.cfg bearbeiten Dies sollte in etwa wie folgt aussehen:

    LOOKERARGS="-d looker-db.yml"

If there were any other arguments in the Looker startup script, add them to the `lookerstart.cfg` file.

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

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

Starten Sie Looker:

    ./looker start

Überprüfen, ob Looker die neue Datenbank verwendet

Wenn Looker das MySQL-Back-End erfolgreich verwendet, sollten Sie Netzwerkverbindungen zwischen der Looker-Instanz und der neuen Datenbankinstanz sehen. Führen Sie dazu den folgenden Befehl auf der Looker-Instanz aus:

netstat -na | grep 3306

Es sollten einige Verbindungen zur Datenbankinstanz angezeigt werden. Das folgende Beispiel zeigt eine DB-Instanz 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-Back-End 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. Das Verzeichnis looker/log/ kann aus den Dateisystemsicherungen ausgeschlossen werden. Weitere Informationen finden Sie auf der Dokumentationsseite Sicherungen erstellen.