Migrazione del database di backend di Looker a MySQL

Per impostazione predefinita, Looker utilizza un database in memoria HyperSQL per archiviare la configurazione, gli utenti e altri dati. Su un'istanza con un utilizzo elevato, le dimensioni di questo database possono raggiungere i gigabyte, il che può causare problemi di prestazioni, utilizzo intensivo della memoria Java e tempi di avvio lunghi.

Su un'istanza ospitata dal cliente, ti consigliamo di sostituire il database HyperSQL con un backend di database MySQL completo quando le dimensioni del database HyperSQL interno superano i 600 MB. Per controllare le dimensioni del database HyperSQL, visualizza le dimensioni del file looker.script:

cd looker
cd .db
ls -lah

Se le dimensioni del file looker.script superano i 600 MB, segui le procedure riportate di seguito per eseguire la migrazione a un database MySQL esterno.

Nota: questa procedura presuppone un deployment in AWS EC2. Per i deployment locali, le dimensioni dei sistemi devono essere paragonabili a quelle delle istanze AWS equivalenti. 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.

Provisioning di un'istanza e di un utente MySQL

Puoi eseguire il provisioning di un'istanza MySQL 8.4.X (consigliata) o MySQL 8.0.X da utilizzare come backend. Le versioni di MySQL precedenti alla 8.0 non sono supportate.

Looker 26.6 e versioni successive supportano MySQL 8.4.X per il database di backend di Looker. Per le istanze ospitate dal cliente che utilizzano MySQL 8.0.X per il database di backend di Looker, ti consigliamo di eseguire l'aggiornamento a MySQL 8.4.X non appena aggiorni l'istanza di Looker alla versione 26.6 o successive.

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

MySQL 8.4.X

A partire da Looker 26.6, Looker supporta l'utilizzo di MySQL 8.4.X come database interno. Per MySQL 8.4.X, puoi utilizzare uno dei seguenti plug-in di autenticazione MySQL, come descritto nelle sezioni seguenti:

• caching_sha2_password
• mysql_native_password

Nota: se esegui l'upgrade del backend di Looker da MySQL 8.0.X a MySQL 8.4.X, puoi conservare l'utente del database che hai creato per MySQL 8.0.X. Tuttavia, con MySQL 8.0.X, Looker richiede che gli utenti del database eseguano l'autenticazione con mysql_native_password. Pertanto, se vuoi conservare l'utente del database di MySQL 8.0.X, segui le istruzioni per eseguire il provisioning di MySQL 8.4.X con mysql_native_password in modo che l'utente esistente possa ancora eseguire l'autenticazione. In caso contrario, se vuoi creare un nuovo utente quando esegui il provisioning di MySQL 8.4.X, puoi eseguire il provisioning dell'istanza MySQL e creare un nuovo utente con il plug-in di autenticazione caching_sha2_password o mysql_native_password.

Utilizzo di caching_sha2_password

In MySQL 8.4.X, il plug-in di autenticazione predefinito è caching_sha2_password. Looker offre due modi per utilizzare il plug-in caching_sha2_password:

1. Quando utilizzi una connessione SSL per il database interno: non è necessaria alcuna chiave pubblica RSA. Looker si connette in modo sicuro al database con le credenziali utente fornite. Per configurare una connessione SSL al database, consulta la sezione Creare un file di credenziali del database in questa pagina.
2. Se non ti connetti con SSL abilitato: per impostazione predefinita, Looker utilizza l'opzione --get-server-public-key per connettersi al database interno quando l'account utente fornito a Looker utilizza il plug-in caching_sha2_password. Assicurati che l'ambiente di rete sia protetto se SSL non è abilitato.

Nota: Looker non supporta la specifica di un file locale come chiave pubblica RSA per la connessione.

Per utilizzare il plug-in caching_sha2_password, configura l'utente eseguendo la seguente istruzione:

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

Sostituisci quanto segue:

• DB_username: nome utente
• password: password univoca e sicura

Utilizzo di mysql_native_password

Looker funziona con il mysql_native_password plug-in per l'autenticazione ai database MySQL tramite il driver JDBC. Perché MySQL 8.4.X funzioni con il plug-in mysql_native_password, devi eseguire i seguenti passaggi aggiuntivi:

1. Configura il database MySQL per abilitare il plug-in mysql_native_password. Questa operazione può essere eseguita in diversi modi, a seconda di come viene eseguito il deployment del database MySQL e del tipo di accesso alla configurazione:

   1. Avvia il server MySQL con --mysql-native-password=ON.

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

      [mysqld]
      mysql_native_password=ON
      

   3. Se l'istanza MySQL è ospitata su Google Cloud, AWS o Azure, il plug-in mysql_native_password deve essere abilitato automaticamente. Per istruzioni dettagliate, consulta la documentazione del provider.

2. Crea l'utente:

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

   Sostituisci quanto segue:

   • DB_username: nome utente
   • password: password univoca e sicura

MySQL 8.0.X

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 eseguire l'autenticazione ai database MySQL tramite il driver JDBC. Perché MySQL 8.0.X funzioni correttamente, devi eseguire i seguenti passaggi aggiuntivi:

1. Configura il database MySQL in modo che utilizzi il plug-in mysql_native_password. Questa operazione può essere eseguita in diversi modi, a seconda di come viene eseguito il deployment del database MySQL 8 e del tipo di accesso alla configurazione:

   • Avvia la procedura con il flag --default-auth=mysql_native_password

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

     [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. Crea l'utente:

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

   Sostituisci quanto segue:

   • DB_username: nome utente
   • password: password univoca e sicura

Ottimizzare MySQL

Modifica le seguenti impostazioni nell'istanza MySQL.

Aumentare le dimensioni massime dei pacchetti

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

max_allowed_packet = 1073741824

Impostare l'algoritmo della tabella temporanea

MySQL 8 gestisce le tabelle temporanee interne in modo diverso rispetto alle versioni precedenti. Le impostazioni predefinite possono causare problemi durante l'esecuzione di alcune query necessarie per l'esecuzione di Looker, in particolare per le istanze di Looker con molti utenti e progetti. La best practice consiste nell'impostare la seguente impostazione del server globale:

internal_tmp_mem_storage_engine = MEMORY

Configurare i set di caratteri

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

Nelle istanze Amazon RDS, applichi questa impostazione creando o modificando un gruppo di parametri e modificando le impostazioni appropriate. Ti consigliamo di copiare il gruppo di parametri corrente e di apportare le modifiche alla copia, soprattutto se condividi i gruppi di parametri tra più istanze RDS. Dopo aver salvato il gruppo di parametri, applicalo all'istanza RDS. Potrebbe essere necessario un riavvio.

Impostare lo schema di replica

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

SET GLOBAL binlog_format = 'MIXED';

o

SET GLOBAL binlog_format = 'ROW';

Creare un database e concedere l'autorizzazione dell'utente

Crea un database nell'istanza di database:

create database DB_name default character set DB_charset default collate DB_collation;

Quindi, concedi le autorizzazioni all'utente che hai creato quando hai eseguito il provisioning dell'istanza e dell'utente MySQL:

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

Sostituisci quanto segue:

• DB_name: nome del database
• DB_charset: il set di caratteri che corrisponde alle impostazioni del gruppo di parametri dell'istanza RDS (per il supporto UTF8 effettivo, consigliamo utf8mb4)
• DB_collation: la collation che corrisponde alle impostazioni del gruppo di parametri dell'istanza RDS (per il supporto UTF8 effettivo, consigliamo utf8mb4_general_ci)
• DB_username: nome utente

Il database looker_tmp nell'ultima riga non deve esistere, ma l'istruzione grant è necessaria per i report interni.

Creare un file di credenziali del database

Looker deve sapere a quale database MySQL deve comunicare e quali credenziali deve utilizzare. Nella directory di Looker, crea un file denominato looker-db.yml con i seguenti contenuti, sostituendo DB_hostname, DB_username, DB_password e DB_name con i valori del tuo database:

dialect: mysql_8
host: DB_hostname
username: DB_username
password: DB_password
database: DB_name
port: 3306

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

ssl: true

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

verify_ssl: true

Facoltativamente, puoi anche specificare altri parametri JDBC aggiuntivi 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 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: quando salvi le credenziali in un file, segui le considerazioni sulla sicurezza delle best practice. Idealmente, imposta le autorizzazioni del file looker-db.yml su 600, di proprietà dell'account "utente" Linux con cui viene eseguita l'applicazione Looker. Questo file non deve mai essere archiviato in un repository Git.

Nello schema di crittografia di Looker, tutti i dati sensibili nel database vengono criptati at-rest. Anche se qualcuno dovesse ottenere l'accesso alle credenziali del database in testo non crittografato e al database, Looker cripta o esegue l'hashing dei dati sensibili prima di archiviarli. Questo vale per elementi come password, credenziali del database di analisi e cache delle query. Tuttavia, se non vuoi archiviare la password in dati 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 e valori per ogni riga del file looker-db.yml. Ad esempio:

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

Importante: limita l'utilizzo dell'account utente MySQL all'indirizzo IP utilizzato dal server Looker.

Eseguire il backup della directory .db

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

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

Eseguire la migrazione del database

La migrazione del database a MySQL può richiedere ore su un'istanza media o grande, soprattutto se il database HyperSQL è di 1 GB o più. 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, il che riduce 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 nel file:

   exit
   

3. Arresta l'istanza nella console AWS. Una volta arrestata, modifica le dimensioni dell'istanza EC2 in m5.2xlarge. Quindi, riavvia l'istanza.

4. Esegui SSH sull'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
   

   Quando esegui il passaggio migrate_internal_data, libcrypt potrebbe non essere trovato e verrà visualizzata un'analisi dello stack, a partire da:

   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 manualmente LD_LIBRARY_PATH prima di eseguire il comando Java:

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

5. Una volta completata l'operazione, arresta l'istanza dalla console AWS.

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

7. Riavvia l'istanza.

Avviare Looker

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

2. Assicurati che non siano definiti argomenti in LOOKERARGS nello script di avvio. Al contrario, tutti gli argomenti devono essere spostati nel file the lookerstart.cfg file in modo che non vengano sovrascritti dalle nuove versioni dello script di avvio. Salva ed esci dallo script di avvio.

3. Modifica lookerstart.cfg. Dovrebbe avere un aspetto simile al seguente:

   LOOKERARGS="-d looker-db.yml"
   

   Se nello script di avvio di Looker erano presenti altri argomenti, 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
   

Verificare che Looker utilizzi il nuovo database

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

netstat -na | grep 3306

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

Eseguire il backup di Looker

Dopo la migrazione a un backend MySQL, i backup S3 automatici di Looker non funzioneranno più. Ti consigliamo di eseguire almeno backup notturni del database MySQL e backup notturni del file system della directory di lavoro di Looker. La directory looker/log/ può essere esclusa dai backup del file system. Per ulteriori informazioni, consulta la pagina della documentazione Creazione di backup.