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

Sur une instance hébergée par le client, nous vous recommandons de remplacer la base de données HyperSQL par un backend de base de données MySQL complet lorsque la taille de la base de données HyperSQL interne dépasse 600 Mo. Pour vérifier la taille de la base de données HyperSQL, consultez la taille du fichier looker.script :

cd looker
cd .db
ls -lah

Si la taille du fichier looker.script dépasse 600 Mo, suivez les procédures ci-dessous pour migrer vers une base de données MySQL externe.

Remarque : Cette procédure suppose un déploiement dans AWS EC2. Pour les déploiements locaux, les systèmes doivent être dimensionnés de manière comparable aux instances AWS équivalentes. Si vous mettez à jour Looker et migrez vers MySQL, nous vous recommandons d'effectuer la mise à jour de Looker avant de migrer vers MySQL.

Provisionner une instance et un utilisateur MySQL

Vous pouvez provisionner une instance MySQL 8.4.X (recommandée) ou MySQL 8.0.X à utiliser comme backend. Les versions de MySQL antérieures à la version 8.0 ne sont pas compatibles.

Looker 26.6 et versions ultérieures sont compatibles avec MySQL 8.4.X pour la base de données backend Looker. Pour les instances hébergées par le client qui utilisent MySQL 8.0.X pour la base de données backend Looker, nous vous recommandons de passer à MySQL 8.4.X dès que vous mettez à jour votre instance Looker vers la version 26.6 ou ultérieure.

Dans AWS RDS, une instance de classe db.m5.large est probablement suffisante comme backend pour 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 judicieux de provisionner entre 100 et 150 Go de stockage SSD, car les IOPS provisionnés sont basés sur la quantité de stockage demandée.

MySQL 8.4.X

Looker est compatible avec l'utilisation de MySQL 8.4.X comme base de données interne à partir de Looker 26.6. Pour MySQL 8.4.X, vous pouvez utiliser l'un des plug-ins d'authentification MySQL suivants, comme décrit dans les sections suivantes :

• caching_sha2_password
• mysql_native_password

Remarque : Si vous mettez à niveau votre backend Looker de MySQL 8.0.X vers MySQL 8.4.X, vous pouvez conserver l'utilisateur de base de données que vous avez créé pour MySQL 8.0.X. Toutefois, avec MySQL 8.0.X, Looker exige que les utilisateurs de base de données s'authentifient avec mysql_native_password. Par conséquent, si vous souhaitez conserver l'utilisateur de base de données de MySQL 8.0.X, suivez les instructions pour provisionner MySQL 8.4.X avec mysql_native_password afin que votre utilisateur existant puisse toujours s'authentifier. Sinon, si vous souhaitez créer un nouvel utilisateur lorsque vous provisionnez MySQL 8.4.X, vous pouvez provisionner l'instance MySQL et créer un nouvel utilisateur avec le plug-in d'authentification caching_sha2_password ou mysql_native_password.

Utiliser caching_sha2_password

Dans MySQL 8.4.X, le plug-in d'authentification par défaut est caching_sha2_password. Looker propose deux façons d'utiliser le plug-in caching_sha2_password :

1. Lorsque vous utilisez une connexion SSL pour la base de données interne : aucune clé publique RSA n'est nécessaire. Looker se connecte de manière sécurisée à la base de données avec les identifiants utilisateur fournis. Reportez-vous à la section Créer un fichier d'identifiants de base de données sur cette page pour configurer une connexion SSL à votre base de données.
2. Si vous ne vous connectez pas avec SSL activé : par défaut, Looker utilise l'option --get-server-public-key pour se connecter à la base de données interne lorsque le plug-in caching_sha2_password est utilisé par le compte utilisateur fourni à Looker. Assurez-vous que l'environnement réseau est sécurisé si SSL n'est pas activé.

Remarque : Looker n'est pas compatible avec la spécification d'un fichier local comme clé publique RSA pour la connexion.

Pour utiliser le plug-in caching_sha2_password, configurez l'utilisateur en exécutant l'instruction suivante :

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

Remplacez les éléments suivants :

• DB_username : nom d'utilisateur
• password: mot de passe unique et sécurisé

Utiliser mysql_native_password

Looker fonctionne avec le mysql_native_password plug-in pour l'authentification aux bases de données MySQL via le pilote JDBC. Pour que MySQL 8.4.X fonctionne avec le plug-in mysql_native_password, vous devez suivre les étapes supplémentaires suivantes :

1. Configurez la base de données MySQL pour activer le mysql_native_password plug-in. Pour cela, plusieurs options sont possibles, selon la manière dont votre base de données MySQL est déployée et le type d'accès dont vous disposez pour la configuration :

   1. Démarrez le serveur MySQL avec --mysql-native-password=ON.

   2. Définissez la propriété dans le my.cnf fichier de configuration :

      [mysqld]
      mysql_native_password=ON
      

   3. Si l'instance MySQL est hébergée sur Google Cloud, AWS ou Azure, le mysql_native_password plug-in doit être activé automatiquement. Pour obtenir des instructions détaillées, consultez la documentation de votre fournisseur.

2. Créez l'utilisateur :

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

   Remplacez les éléments suivants :

   • DB_username : nom d'utilisateur
   • password: mot de passe unique et sécurisé

MySQL 8.0.X

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 l'authentification aux bases de données MySQL via le pilote JDBC. Pour que MySQL 8.0.X fonctionne correctement, vous devez suivre les étapes supplémentaires suivantes :

1. Configurez la base de données MySQL pour qu'elle utilise 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 et le type d'accès dont vous disposez pour la configuration :

   • Démarrez le processus avec l'option --default-auth=mysql_native_password.

   • Définissez la propriété dans le my.cnf fichier de configuration :

     [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 dans un groupe de paramètres RDS appliqué à cette instance de base de données.

2. Créez l'utilisateur :

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

   Remplacez les éléments suivants :

   • DB_username : nom d'utilisateur
   • password: mot de passe unique et sécurisé

Ajuster MySQL

Ajustez les paramètres suivants sur votre instance MySQL.

Augmenter la taille maximale des paquets

La taille par défaut de max_allowed_packet de 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éfinir l'algorithme de table temporaire

MySQL 8 gère les tables 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 au fonctionnement 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 est compatible avec 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, vous appliquez 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'apporter les modifications à la copie, en particulier si vous partagez des groupes de paramètres sur 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 de réplication

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 accorder des autorisations à l'utilisateur

Créez une base de données sur l'instance de base de données :

create database DB_name default character set DB_charset default collate DB_collation;

Accordez ensuite des autorisations à l'utilisateur que vous avez créé lorsque vous avez provisionné l'instance et l'utilisateur MySQL :

grant all on DB_name.* to 'DB_username'@'%';
grant all on looker_tmp.* to 'DB_username'@'%';

Remplacez les éléments suivants :

• DB_name : nom de la base de données
• DB_charset : jeu de caractères correspondant aux paramètres du groupe de paramètres de l'instance RDS (pour une véritable compatibilité UTF8, nous vous recommandons utf8mb4)
• DB_collation : collation correspondant aux paramètres du groupe de paramètres de l'instance RDS (pour une véritable compatibilité UTF8, nous vous recommandons utf8mb4_general_ci)
• DB_username : nom d'utilisateur

La base de données looker_tmp de la dernière ligne n'a pas besoin d'exister, 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 s'adresser 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_8
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 MariaDB 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

Important : Suivez les bonnes pratiques de sécurité lorsque vous enregistrez des identifiants dans un fichier. Dans l'idéal, définissez les autorisations du fichier looker-db.yml sur 600, appartenant 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.

Dans le 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 une personne accède aux identifiants de la base de données en texte brut et à la base de données, Looker chiffre ou hache les données sensibles avant de les stocker. Cela s'applique à des éléments tels que les mots de passe, les identifiants de base de données d'analyse et le cache de requêtes. 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 et de valeurs pour chaque ligne du fichier looker-db.yml. Exemple :

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

Important : 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 en mémoire HyperSQL, au cas où vous devriez 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 plusieurs heures sur une instance moyenne ou grande, en particulier si la base de données HyperSQL est d'au moins 1 Go. Nous vous recommandons de mettre à niveau temporairement l'instance EC2 vers une instance m5.2xlarge (avec 32 Go de RAM pour autoriser le tas de mémoire de 26 Go spécifié dans les étapes) pendant la migration, ce qui réduit le temps nécessaire à environ 10 minutes.

1. Sur l'hôte Looker :

   cd looker
   ./looker stop
   vi looker
   

2. Dans le script de démarrage Looker, créez une deuxième ligne dans le fichier :

   exit
   

3. Arrêtez l'instance dans la console AWS. Une fois l'arrêt effectué, remplacez la taille de l'instance EC2 par m5.2xlarge. Redémarrez ensuite l'instance.

4. Connectez-vous en SSH à l'hôte en tant qu'utilisateur Looker. Tout d'abord, assurez-vous 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, libcrypt peut ne pas être trouvé et une trace de la pile s'affiche, en commençant par :

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

   Si cela se produit, définissez manuellement LD_LIBRARY_PATH avant d'exécuter la commande Java :

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

5. Une fois l'opération terminée, arrêtez l'instance à partir de la console AWS.

6. Vous pouvez maintenant restaurer la taille d'origine de l'instance.

7. Redémarrez l'instance.

Démarrer Looker

1. Modifiez le script de démarrage Looker et supprimez la ligne exit que vous avez ajoutée précédemment.

2. Assurez-vous qu'aucun argument n'est défini dans LOOKERARGS dans le script de démarrage. Au lieu de cela, tous les arguments doivent être déplacés vers le fichier lookerstart.cfg afin qu'ils ne soient pas remplacés par de nouvelles versions du script de démarrage. Enregistrez le script de démarrage et quittez-le.

3. Modifiez lookerstart.cfg. Le résultat doit ressembler à ceci :

   LOOKERARGS="-d looker-db.yml"
   

   S'il existe d'autres arguments dans le script de démarrage Looker, ajoutez-les au fichier lookerstart.cfg.

4. Archivez le répertoire .db, s'il n'est pas déjà archivé.

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

5. 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 vérifier cela, 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. Voici un exemple de résultat, affichant 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

Sauvegarder Looker

Une fois que vous avez migré vers un backend MySQL, les sauvegardes S3 automatisées de Looker ne fonctionneront plus. Nous vous recommandons d'effectuer au moins une sauvegarde quotidienne de la base de données MySQL, ainsi que des sauvegardes quotidiennes 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.