Migrazione del database di backend Looker a MySQL

Per impostazione predefinita, Looker utilizza un database in memoria HyperSQL per archiviare la configurazione, gli utenti e altri dati. In un'istanza intensa, questo database può raggiungere le dimensioni di gigabyte, causando problemi di prestazioni, pressione della memoria Java e lunghi tempi di avvio.

Ti consigliamo di sostituire il database HyperSQL con un backend completo del database MySQL quando la dimensione del database HyperSQL interno supera i 600 MB. Per controllare le dimensioni del database HyperSQL, visualizza le dimensioni del file looker.script:

cd looker
cd .db
ls -lah

Se il file looker.script supera i 600 MB, segui queste istruzioni per eseguire la migrazione a un database MySQL esterno.

Nota: questa procedura presuppone un deployment in AWS EC2. Per i deployment locali, i sistemi devono avere dimensioni analoghe alle istanze AWS equivalenti.

I clienti che eseguono l'aggiornamento a Looker 6.6 o versioni successive da una versione precedente a Looker 6.6 non possono eseguire contemporaneamente l'aggiornamento di Looker e la migrazione a un database di backend MySQL. Se stai aggiornando Looker ed eseguendo la migrazione a MySQL, ti consigliamo di completare l'aggiornamento di Looker prima di eseguire la migrazione a MySQL.

Esegui il provisioning di un'istanza MySQL

Esegui il provisioning di un'istanza MySQL 8.0.x da utilizzare come backend. Looker supporta anche MySQL 5.7.x.

Le versioni di MySQL precedenti alla 5.7.x non sono supportate perché non supportano la codifica di UTF8mb4.

In AWS RDS, un'istanza di classe db.m5.large è probabilmente sufficiente come backend per una singola istanza di Looker. Anche se l'utilizzo effettivo del database sarà probabilmente compreso nell'intervallo 5-10 GB, è consigliabile eseguire il provisioning di 100-150 GB di spazio di archiviazione SSD perché le IOPS sottoposte a provisioning si basano sulla quantità di spazio di archiviazione richiesta.

MySQL 8.0.X: modifica del plug-in di autenticazione predefinito

In MySQL 8.0.X, il plug-in di autenticazione predefinito è caching_sha2_password. Looker utilizza il plug-in mysql_native_password per tentare di autenticarsi nei database MySQL tramite il driver JDBC. Affinché questa versione di MySQL funzioni correttamente, devi seguire questi passaggi aggiuntivi:

1. Configura il database MySQL per utilizzare il plug-in mysql_native_password. Questa operazione può essere eseguita in diversi modi e dipende dal modo in cui viene eseguito il deployment del database MySQL 8 e dal tipo di accesso alla configurazione:

   • Avviare la procedura con il flag --default-auth=mysql_native_password.

   • Imposta la proprietà nel file di configurazione di my.cnf:

     [mysqld]
     default-authentication-plugin=mysql_native_password
     

   • Se l'istanza di database è ospitata tramite AWS RDS, imposta il parametro default_authentication_plugin tramite un gruppo di parametri RDS applicato a questa istanza di database.

2. Pronuncia le seguenti istruzioni, sostituendo some_password_here con una password univoca e sicura:

   CREATE USER looker IDENTIFIED WITH mysql_native_password BY 'some_password_here';
   GRANT SELECT ON database_name.* TO 'looker'@'%';
   

Ottimizza MySQL

Modifica le seguenti impostazioni sull'istanza MySQL.

Aumenta le dimensioni massime del pacchetto

Le dimensioni predefinite di MySQL per max_allowed_packet sono troppo piccole per eseguire la migrazione del database e possono causare un errore di migrazione con un errore PACKET_TOO_LARGE. Imposta max_allowed_packet sul valore massimo consentito di 1073741824:

max_allowed_packet = 1073741824

Imposta algoritmo della tabella temporanea

MySQL 8 gestisce le tabelle temporanee interne in modo diverso rispetto alle versioni precedenti. Le impostazioni predefinite possono causare problemi di esecuzione di alcune query necessarie per l'esecuzione di Looker, soprattutto per le istanze Looker con molti utenti e progetti. La best practice prevede di utilizzare l'algoritmo della tabella temporanea interna MySQL 5.7 impostando la seguente impostazione del server globale:

internal_tmp_mem_storage_engine = MEMORY

Configura i set di caratteri

Imposta i seguenti parametri predefiniti per utilizzare UTF8mb4, che supporta i set di caratteri UTF8. Consulta l'articolo In MySQL, non utilizzare mai "utf8". Utilizza "utf8mb4". per informazioni sul motivo per cui consigliamo di utilizzare UTF8mb4 e non UTF8 in 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

Sulle istanze Amazon RDS, puoi applicare questa impostazione creando o modificando un gruppo di parametri e modificando le impostazioni appropriate. Ti consigliamo di copiare il gruppo di parametri correnti e di apportare le modifiche alla copia, soprattutto se condividi i gruppi di parametri tra diverse istanze RDS. Dopo aver salvato il gruppo di parametri, applicalo all'istanza RDS. Potrebbe essere necessario riavviare.

Imposta lo schema di replica

Looker si basa sulla funzionalità che richiede un binlog mixed o row. Se ospiti la tua istanza MySQL, imposta binlog_format su mixed o row inviando uno dei seguenti comandi:

SET GLOBAL binlog_format = 'MIXED';

o

SET GLOBAL binlog_format = 'ROW';

Crea un database e un utente

Crea un utente e un database nell'istanza di database, sostituendo <DB_username>, <DB_name> e <DB_password> con i valori effettivi per l'utente e il database. Sostituisci anche <DB_charset> e <DB_collation> con il set di caratteri e le regole di confronto selezionati che corrispondono alle impostazioni del gruppo di parametri dell'istanza RDS (per il supporto reale di UTF8, consigliamo utf8mb4 e 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>'@'%';

Non è necessario che il database looker_tmp nell'ultima riga esista, ma è necessaria l'istruzione grant per creare report interni.

Crea un file di credenziali del database

Looker deve sapere con quale database MySQL deve parlare e quali credenziali utilizzare. Nella directory di Looker, crea un file denominato looker-db.yml con il seguente contenuto, sostituendo <DB_hostname>, <DB_username>, <DB_password> e <DB_name> con valori per il tuo database:

dialect: mysql
host: <DB_hostname>
username: <DB_username>
password: <DB_password>
database: <DB_name>
port: 3306

Se il tuo database MySQL richiede una connessione SSL, aggiungi la seguente riga a looker-db.yml:

ssl: true

Se vuoi attivare la verifica del certificato SSL, aggiungi la seguente riga a looker-db.yml:

verify_ssl: true

Facoltativamente, puoi anche aggiungere altri parametri JDBC supportati dal driver JDBC MariaDB aggiungendo jdbc_additional_params. Ad esempio, se devi utilizzare un file Trust Store specifico, puoi aggiungere il seguente parametro alla stringa di connessione JDBC di MySQL:

jdbc_additional_params: trustStore=/path/to/my/truststore.jks&keyStore=/path/to/my/keystore.jks

Per le installazioni ospitate dal cliente, puoi facoltativamente specificare il numero massimo di connessioni che Looker può stabilire con il tuo database aggiungendo max_connections. Ad esempio, per limitare a 10 il numero di connessioni simultanee al database, aggiungi quanto segue:

max_connections: 10

Importante: segui le best practice per la sicurezza quando salvi le credenziali in un file. Idealmente, imposta le autorizzazioni del file looker-db.yml su 600, di proprietà dell'account "utente" Linux in cui viene eseguita l'applicazione Looker. Questo file non deve mai essere inserito in un repository Git.

In base allo schema di crittografia di Looker, tutti i dati sensibili nel database sono criptati at-rest. Anche se qualcuno dovesse ottenere l'accesso alle credenziali del database in testo non crittografato e accedere al database, Looker cripta o esegue l'hashing di dati sensibili prima di archiviarli. Questo vale per le password, per le credenziali dei database di analisi, per la cache delle query e così via. Tuttavia, se non vuoi archiviare la password del testo in chiaro per questa configurazione nel file looker-db.yml su disco, puoi configurare la variabile di ambiente LOOKER_DB in modo che contenga un elenco di chiavi/valori per ogni riga nel file looker-db.yml. Ecco alcuni esempi:

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

Importante: limita l'uso del tuo account utente MySQL all'indirizzo IP utilizzato dal tuo server Looker.

Esegui il backup della directory .db

Esegui il backup della directory .db, che contiene i file necessari per creare il database HyperSQL in memoria, nel caso in cui sia necessario ripristinare HyperSQL:

cp -r .db .db-backup
tar -zcvf db-backup.tar.gz ./.db-backup

Esegui la migrazione del database

La migrazione del database a MySQL può richiedere ore su un'istanza di medie o grandi dimensioni, soprattutto se il database HyperSQL è di almeno 1 GB. Ti consigliamo di eseguire temporaneamente l'upgrade dell'istanza EC2 a m5.2xlarge (con 32 GB di RAM per consentire l'heap di 26 GB specificato nei passaggi) durante la migrazione, in modo da ridurre il tempo necessario a circa 10 minuti.

1. Nell'host Looker:

   cd looker
   ./looker stop
   vi looker
   

2. Nello script di avvio di Looker, crea una nuova seconda riga del file:

   exit
   

3. Arresta l'istanza nella console AWS. Una volta arrestato, cambia la dimensione dell'istanza EC2 in m5.2xlarge. Quindi, riavvia l'istanza.

4. SSH per l'host come utente Looker. Innanzitutto, assicurati che Java non sia in esecuzione, quindi esegui:

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

   Durante l'esecuzione del passaggio migrate_internal_data, potrebbe non essere trovato libcrypt e verrà visualizzata un'analisi dello stack, a partire da quanto segue:

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

   In questo caso, imposta LD_LIBRARY_PATH manualmente prima di eseguire il comando Java:

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

5. Al termine, arresta l'istanza dalla console AWS.

6. Ora puoi ripristinare le dimensioni originali dell'istanza.

7. Avvia di nuovo l'istanza.

Avvia Looker

1. Modifica lo script di avvio di Looker ed elimina la riga exit che hai aggiunto in precedenza.

2. Assicurati che non ci siano argomenti definiti in LOOKERARGS nello script di avvio. Eventuali argomenti dovrebbero invece essere spostati nel file lookerstart.cfg in modo che non vengano sovrascritti da nuove versioni dello script di avvio. Salva ed esci dallo script di avvio.

3. Modifica lookerstart.cfg. Dovrebbe avere il seguente aspetto:

   LOOKERARGS="-d looker-db.yml"
   

   Se sono presenti altri argomenti nello script di avvio di Looker, aggiungili al file lookerstart.cfg.

4. Archivia la directory .db, se non è già archiviata.

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

5. Avvia Looker:

   ./looker start
   

Verifica che Looker stia utilizzando il nuovo database

Se Looker utilizza il backend MySQL, dovresti vedere le connessioni di rete tra l'istanza di Looker e la nuova istanza di database. Per verificarlo, esegui il comando seguente sull'istanza di Looker:

netstat -na | grep 3306

Dovresti vedere alcune connessioni all'istanza di database. Di seguito è riportato un output di esempio che mostra un'istanza DB all'indirizzo 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

Backup di Looker

Dopo aver eseguito la migrazione a un backend MySQL, i backup S3 automatici di Looker non funzioneranno più. Consigliamo di eseguire almeno i backup notturni del database MySQL insieme ai backup notturni del file system della directory di lavoro di Looker. La directory looker/log/ potrebbe essere esclusa dai backup del file system. Per ulteriori informazioni, consulta la pagina Creazione di backup della documentazione.