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