Vous consultez la documentation de Looker 22.16. Pour accéder à la documentation la plus récente, cliquez ici.

Migrer la base de données backend Looker vers MySQL

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 occupée, la taille de cette base de données peut atteindre plusieurs gigaoctets, ce qui peut entraîner des problèmes de performances, de la pression sur la mémoire Java et de longs temps de démarrage.

Nous vous recommandons de remplacer la base de données HyperSQL par un backend de base de données MySQL complet lorsque sa taille 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.

Cette procédure suppose un déploiement dans AWS EC2. Pour les déploiements locaux, la taille des systèmes doit être comparable à celle des instances AWS équivalentes.

Les clients qui passent à Looker 6.6 ou version ultérieure depuis une version antérieure à Looker 6.6 ne peuvent pas effectuer la mise à jour et la migration de Looker vers une base de données backend MySQL en même temps. Si vous mettez à jour Looker et que vous migrez vers MySQL, nous vous recommandons de terminer la mise à jour de Looker avant d'effectuer la migration vers MySQL.

Provisionner une instance MySQL

Provisionnez une instance MySQL 8.0.x à utiliser comme backend. Looker est également compatible avec MySQL version 5.7.x.

Les versions de MySQL antérieures à la version 5.7.x ne sont pas compatibles, car elles ne sont pas compatibles avec l'encodage UTF8mb4.

Dans AWS RDS, une instance de classe db.m5.large est probablement suffisante pour servir de backend à une seule instance Looker. Même si l'utilisation réelle de la base de données se situera probablement entre 5 et 10 Go, il est conseillé de provisionner 100 à 150 Go d'espace de stockage SSD, car les IOPS provisionnées sont basées sur la quantité de stockage demandée.

Régler MySQL

La taille par défaut max_allowed_packetde MySQL est trop petite pour la migration de la base de données et peut entraîner l'échec de la migration avec une erreur PACKET_TOO_LARGE. Définissez max_allowed_packet sur la valeur maximale autorisée de 1073741824:

max_allowed_packet = 1073741824

Définissez également les paramètres par défaut suivants pour utiliser UTF8mb4, qui est compatible avec les jeux de caractères UTF8. Consultez l'article Dans MySQL, n'utilisez jamais "utf8". Utilisez &utt8ut4". pour comprendre 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, vous pouvez appliquer ce paramètre en créant ou en modifiant un groupe de paramètres et en modifiant les paramètres appropriés. Nous vous recommandons de copier le groupe de paramètres actuel et d'y apporter les modifications, en particulier 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 le schéma de votre instance dupliquée

Looker repose 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';

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 choisis, qui correspondent aux paramètres du groupe de paramètres d'instance RDS. Pour une compatibilité UTF8 réelle, 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 sur la dernière ligne n'a pas besoin d'exister, mais l'instruction grant est nécessaire pour les 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 validation du certificat SSL, ajoutez la ligne suivante à looker-db.yml :

verify_ssl: true

Vous pouvez également spécifier d'autres paramètres JDBC supplémentaires compatibles avec le pilote JDBC Mariaria en ajoutant jdbc_additional_params. Par exemple, si vous devez utiliser un fichier Trust Store 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 le 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 les éléments suivants:

max_connections: 10

Recommandation de sécurité: Respectez les bonnes pratiques liées à la sécurité lorsque vous enregistrez des identifiants dans un fichier. Idéalement, définissez les autorisations du fichier looker-db.yml sur 600, qui appartiennent au compte utilisateur Linux sous lequel l'application Looker est exécutée. Ce fichier ne doit jamais être enregistré dans un dépôt Git.

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 obtenait l'accès à des identifiants de base de données en texte brut et pouvait accéder à la base de données, 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"

Recommandation de sécurité: Limitez l'utilisation de votre compte utilisateur MySQL à l'adresse IP utilisée par votre serveur Looker.

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 moyenne ou grande, en particulier si la base de données HyperSQL fait au moins 1 Go. Nous vous recommandons de mettre à niveau temporairement l'instance EC2 vers m5.2xlarge (avec 32 Go de RAM pour permettre les 26 Go de mémoire spécifiés lors de la procédure) lors de la migration, ce qui réduit le temps requis à 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'instance arrêtée, définissez sa taille sur m5.2xlarge. Ensuite, redémarrez l'instance.
Connectez-vous en SSH à l'hôte en tant qu'utilisateur Looker. Assurez-vous d'abord 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

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

Une fois l'opération terminée, arrêtez l'instance depuis la console AWS.
Vous pouvez maintenant restaurer la taille d'origine de l'instance.
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. À la place, tous les arguments doivent être déplacés dans le fichier lookerstart.cfg afin qu'ils ne soient pas remplacé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"

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

Si ce n'est pas déjà fait, archivez le répertoire .db.

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

Démarrez 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 le vérifier, exécutez la commande suivante sur l'instance Looker:

netstat -na | grep 3306

Vous devriez voir des connexions à l'instance de base de données. Vous trouverez ci-dessous un exemple de sortie affichant une instance de base de données dont l'adresse IP est 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

Sauvegarder Looker

Une fois la migration vers un backend MySQL effectuée, les sauvegardes S3 automatisées de Looker ne fonctionneront plus. Nous recommandons d'effectuer au moins des sauvegardes nocturnes de la base de données MySQL et des sauvegardes nocturnes 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 Créer des sauvegardes.