Par défaut, Looker utilise une base de données en mémoire HyperSQL pour stocker sa configuration, ses utilisateurs et d'autres données. Sur une instance chargée, la taille de cette base de données peut atteindre plusieurs gigaoctets, ce qui peut entraîner des problèmes de performances, une pression sur la mémoire Java et de longs temps de démarrage.
Sur une instance hébergée par un client, nous vous recommandons de remplacer la base de données HyperSQL par un backend de base de données MySQL complet lorsque la base de données HyperSQL interne dépasse 600 Mo. Pour vérifier la taille de la base de données HyperSQL, affichez la taille du fichier looker.script
:
cd looker
cd .db
ls -lah
Si la taille du fichier looker.script
dépasse 600 Mo, procédez comme suit pour migrer vers une base de données MySQL externe.
Provisionner une instance MySQL
Provisionnez une instance MySQL 8.0.x à utiliser comme backend. Les versions de MySQL antérieures à la version 8.0 ne sont pas compatibles.
Dans AWS RDS, une instance de la classe db.m5.large
est probablement suffisante en tant que backend pour une seule instance Looker. Même si l'utilisation réelle de la base de données est probablement comprise entre 5 et 10 Go, il est recommandé de provisionner entre 100 et 150 Go de stockage SSD, car les IOPS provisionnées sont basées sur la quantité de stockage demandée.
MySQL 8.0.X : modifier le plug-in d'authentification par défaut
Dans MySQL 8.0.X, le plug-in d'authentification par défaut est caching_sha2_password
. Looker utilise le plug-in mysql_native_password
pour tenter de s'authentifier auprès des bases de données MySQL via le pilote JDBC. Pour que cette version de MySQL fonctionne correctement, vous devez effectuer les étapes supplémentaires suivantes:
Configurez la base de données MySQL pour utiliser le plug-in
mysql_native_password
. Pour cela, plusieurs options sont possibles, selon la manière dont votre base de données MySQL 8 est déployée le type d'accès dont vous disposez pour la configuration :Démarrer le processus avec l'indicateur
--default-auth=mysql_native_password
Définissez la propriété dans le fichier de configuration
my.cnf
:[mysqld] default-authentication-plugin=mysql_native_password
Si votre instance de base de données est hébergée via AWS RDS, définissez le paramètre
default_authentication_plugin
via un groupe de paramètres RDS appliqué à cette instance de base de données.
Émettez les instructions suivantes, en remplaçant
some_password_here
par un mot de passe unique et sécurisé:CREATE USER looker IDENTIFIED WITH mysql_native_password BY 'some_password_here'; GRANT SELECT ON database_name.* TO 'looker'@'%';
Régler MySQL
Ajustez les paramètres suivants sur votre instance MySQL.
Augmenter la taille maximale des paquets
La taille max_allowed_packet
par défaut de MySQL est trop petite pour migrer la base de données et peut entraîner l'échec de la migration et une erreur PACKET_TOO_LARGE
. Définissez max_allowed_packet
sur la valeur maximale autorisée de 1073741824
:
max_allowed_packet = 1073741824
Définir un algorithme de tableau temporaire
MySQL 8 gère les tableaux temporaires internes différemment des versions précédentes. Les paramètres par défaut peuvent entraîner des problèmes lors de l'exécution de certaines requêtes nécessaires à l'exécution de Looker, en particulier pour les instances Looker comportant de nombreux utilisateurs et projets. La bonne pratique consiste à définir le paramètre de serveur global suivant:
internal_tmp_mem_storage_engine = MEMORY
Configurer les jeux de caractères
Définissez les paramètres par défaut suivants pour utiliser UTF8mb4, qui accepte les jeux de caractères UTF8. Consultez l'article Dans MySQL, n'utilisez jamais "utf8". Utilisez "utf8mb4". pour savoir pourquoi nous vous recommandons d'utiliser UTF8mb4 (et non UTF8) avec MySQL.
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
Sur les instances Amazon RDS, pour appliquer ce paramètre, vous devez créer ou modifier un groupe de paramètres, puis modifier les paramètres appropriés. Nous vous recommandons de copier le groupe de paramètres actuel et d'apporter les modifications souhaitées à la copie, surtout si vous partagez des groupes de paramètres entre plusieurs instances RDS. Après avoir enregistré le groupe de paramètres, appliquez-le à l'instance RDS. Un redémarrage peut être nécessaire.
Définir votre schéma d'instance répliquée
Looker s'appuie sur une fonctionnalité qui nécessite un binlog mixed
ou row
. Si vous hébergez votre propre instance MySQL, définissez binlog_format
sur mixed
ou row
en exécutant l'une des commandes suivantes:
SET GLOBAL binlog_format = 'MIXED';
ou
SET GLOBAL binlog_format = 'ROW';
Créer une base de données et un utilisateur
Créez un utilisateur et une base de données sur l'instance de base de données, en remplaçant <DB_username>
, <DB_name>
et <DB_password>
par les valeurs réelles de l'utilisateur et de la base de données. Remplacez également <DB_charset>
et <DB_collation>
par le jeu de caractères et le classement correspondant aux paramètres du groupe de paramètres de l'instance RDS (pour une véritable compatibilité avec UTF8, nous recommandons utf8mb4
et 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>'@'%';
La base de données looker_tmp
de la dernière ligne n'a pas besoin d'exister réellement, mais l'instruction grant
est nécessaire pour la création de rapports internes.
Créer un fichier d'identifiants de base de données
Looker doit savoir à quelle base de données MySQL communiquer et quels identifiants utiliser. Dans le répertoire Looker, créez un fichier nommé looker-db.yml
avec le contenu suivant, en remplaçant <DB_hostname>
, <DB_username>
, <DB_password>
et <DB_name>
par les valeurs de votre base de données:
dialect: mysql
host: <DB_hostname>
username: <DB_username>
password: <DB_password>
database: <DB_name>
port: 3306
Si votre base de données MySQL nécessite une connexion SSL, ajoutez la ligne suivante à looker-db.yml
:
ssl: true
Si vous souhaitez également activer la vérification du certificat SSL, ajoutez la ligne suivante à looker-db.yml
:
verify_ssl: true
Si vous le souhaitez, vous pouvez également spécifier d'autres paramètres JDBC supplémentaires compatibles avec le pilote JDBC MariaDB en ajoutant jdbc_additional_params
. Par exemple, si vous devez utiliser un fichier de magasin de confiance spécifique, vous pouvez ajouter le paramètre suivant à la chaîne de connexion JDBC MySQL:
jdbc_additional_params: trustStore=/path/to/my/truststore.jks&keyStore=/path/to/my/keystore.jks
Pour les installations hébergées par un client, vous pouvez éventuellement spécifier le nombre maximal de connexions que Looker peut établir avec votre base de données en ajoutant max_connections
. Par exemple, pour limiter le nombre de connexions simultanées à votre base de données à 10, ajoutez ce qui suit:
max_connections: 10
Conformément au schéma de chiffrement de Looker, toutes les données sensibles de la base de données sont chiffrées au repos. Même si quelqu'un obtient les identifiants d'une base de données en texte brut et accède à celle-ci, Looker chiffre ou hache les données sensibles avant de les stocker. Cela s'applique aux mots de passe, aux identifiants de la base de données Analytics, au cache de requêtes, etc. Toutefois, si vous ne souhaitez pas stocker le mot de passe en texte clair pour cette configuration dans le fichier looker-db.yml
sur le disque, vous pouvez configurer la variable d'environnement LOOKER_DB
pour qu'elle contienne une liste de clés/valeurs pour chaque ligne du fichier looker-db.yml
. Exemple :
export LOOKER_DB="dialect=mysql&host=localhost&username=root&password=&database=looker&port=3306"
Sauvegarder le répertoire .db
Sauvegardez le répertoire .db
, qui contient les fichiers nécessaires à la création de la base de données HyperSQL en mémoire, au cas où vous auriez besoin de restaurer HyperSQL:
cp -r .db .db-backup
tar -zcvf db-backup.tar.gz ./.db-backup
Migrer la base de données
La migration de la base de données vers MySQL peut prendre des heures sur une instance de taille moyenne ou grande, en particulier si la base de données HyperSQL contient au moins 1 Go. Nous vous recommandons de mettre à niveau temporairement l'instance EC2 vers une m5.2xlarge
(avec 32 Go de RAM pour permettre le tas de mémoire de 26 Go spécifié dans les étapes) pendant la migration, ce qui réduira le temps nécessaire à environ 10 minutes.
Sur l'hôte Looker:
cd looker ./looker stop vi looker
Dans le script de démarrage de Looker, créez une deuxième ligne dans le fichier:
exit
Arrêtez l'instance dans la console AWS. Une fois l'opération arrêtée, définissez la taille de l'instance EC2 sur
m5.2xlarge
. Redémarrez ensuite l'instance.Connectez-vous en SSH à l'hôte en tant qu'utilisateur Looker. Commencez par vous assurer que Java n'est pas en cours d'exécution, puis exécutez la commande suivante:
cd looker java -Xms26000m -Xmx26000m -jar looker.jar migrate_internal_data looker-db.yml
Lors de l'exécution de l'étape
migrate_internal_data
, il est possible quelibcrypt
soit introuvable et qu'une trace de la pile s'affiche, en commençant par l'exemple suivant:NotImplementedError: getppid unsupported or native support failed to load ppid at org/jruby/RubyProcess.java:752 ppid at org/jruby/RubyProcess.java:749
Dans ce cas, définissez
LD_LIBRARY_PATH
manuellement avant d'exécuter la commande Java:export LD_LIBRARY_PATH=$HOME/looker/.tmp/:$LD_LIBRARY_PATH
Une fois l'opération terminée, arrêtez l'instance depuis la console AWS.
Vous pouvez maintenant restaurer l'instance à sa taille d'origine.
Redémarrez l'instance.
Démarrer Looker
Modifiez le script de démarrage de Looker et supprimez la ligne
exit
que vous avez ajoutée précédemment.Assurez-vous qu'aucun argument n'est défini dans
LOOKERARGS
dans le script de démarrage. Tous les arguments doivent être déplacés vers le fichierlookerstart.cfg
afin qu'ils ne soient pas écrasés par les nouvelles versions du script de démarrage. Enregistrez et quittez le script de démarrage.Modifier
lookerstart.cfg
. Le résultat doit ressembler à ceci :LOOKERARGS="-d looker-db.yml"
Si le script de démarrage Looker contenait d'autres arguments, ajoutez-les au fichier
lookerstart.cfg
.Archivez le répertoire
.db
s'il ne l'est pas déjà.mv .db .db-backup tar -zcvf db-backup.tar.gz ./.db-backup rm -rf ./.db-backup/
Lancez Looker:
./looker start
Vérifier que Looker utilise la nouvelle base de données
Si Looker utilise correctement le backend MySQL, vous devriez voir des connexions réseau entre l'instance Looker et la nouvelle instance de base de données. Pour vérifier cela, exécutez la commande suivante sur l'instance Looker:
netstat -na | grep 3306
Vous devriez voir quelques connexions à l'instance de base de données. Voici un exemple de résultat montrant une instance de base de données à l'adresse IP 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
Sauvegarde de Looker
Après la migration vers un backend MySQL, les sauvegardes S3 automatisées de Looker ne fonctionneront plus. Nous vous recommandons d'effectuer au moins des sauvegardes nocturnes de la base de données MySQL, ainsi que des sauvegardes du système de fichiers du répertoire de travail Looker. Le répertoire looker/log/
peut être exclu des sauvegardes du système de fichiers. Pour en savoir plus, consultez la page de documentation Créer des sauvegardes.