Looker バックエンド データベースから MySQL への移行

デフォルトでは、Looker は HyperSQL のインメモリ データベースを使用して、構成やユーザーなどのデータを保存しています。ビジー状態のインスタンスでは、このデータベースのサイズがギガバイトにまで拡大する可能性があり、パフォーマンスの問題、Java のメモリ プレッシャー、起動時間が長くなる可能性があります。

内部 HyperSQL データベースのサイズが 600 MB を超える場合は、HyperSQL データベースを完全な MySQL データベース バックエンドに置き換えることをおすすめします。HyperSQL データベースのサイズを確認するには、looker.script ファイルのサイズを表示します。

cd looker
cd .db
ls -lah

looker.script ファイルのサイズが 600 MB を超える場合は、次の手順に沿って外部 MySQL データベースに移行してください。

この手順では、AWS EC2 へのデプロイを想定しています。ローカル デプロイの場合、システムのサイズは同等の AWS インスタンスと同程度にする必要があります。

Looker 6.6 より前のバージョンから Looker 6.6 以降に更新する場合、Looker の更新を実行して MySQL バックエンド DB に同時に移行することはできません。Looker を更新して MySQL に移行する場合は、Looker への移行前に MySQL の更新を完了することをおすすめします。

MySQL インスタンスをプロビジョニングする

バックエンドとして使用する MySQL 8.0.x インスタンスをプロビジョニングします。Looker は MySQL バージョン 5.7.x もサポートしています。

5.7.x よりも前のバージョンの MySQL では、UTF8mb4 エンコードがサポートされていないため、このバージョンはサポートされていません。

AWS RDS では、おそらく単一の Looker インスタンスのバックエンドとして db.m5.large クラスのインスタンスで十分です。データベースの実際の使用量は 5 ~ 10 GB の範囲になりますが、プロビジョニングされた IOPS はリクエストされたストレージの量に基づいているため、100 ~ 150 GB の SSD ストレージをプロビジョニングすることをおすすめします。

MySQL を調整する

MySQL のデフォルトの max_allowed_packet サイズは小さすぎてデータベース移行に失敗し、PACKET_TOO_LARGE エラーが発生して移行が失敗する可能性があります。max_allowed_packet を、1073741824 の最大許容値に設定します。

max_allowed_packet = 1073741824

さらに、以下のデフォルト パラメータを設定して、UTF8 文字セットをサポートする UTF8mb4 を使用します。MySQL では &utt;utf8" を使用しない。MySQL で UTF8 ではなく UTF8 を使用することをおすすめする理由については、&ft;utf8mb4". をご覧ください。

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

Amazon RDS インスタンスでは、パラメータ グループを作成または変更し、適切な設定を編集して、この設定を適用します。特に複数の RDS インスタンス間でパラメータ グループを共有している場合は、現在のパラメータ グループをコピーして、変更を加えることをおすすめします。パラメータ グループを保存したら、RDS インスタンスに適用します。再起動が必要になる場合があります。

レプリカ方式の設定

Looker は、mixed または row バイナリログを必要とする機能に依存しています。独自の MySQL インスタンスをホストする場合は、次のいずれかのコマンドを発行して binlog_formatmixed または row に設定します。

SET GLOBAL binlog_format = 'MIXED';

または

SET GLOBAL binlog_format = 'ROW';

データベースとユーザーを作成する

データベース インスタンスにユーザーとデータベースを作成します。<DB_username><DB_name><DB_password> は、ユーザーとデータベースの実際の値に置き換えます。また、<DB_charset><DB_collation> を、RDS インスタンス パラメータ グループの設定に一致する選択された文字セットと照合に置き換えます(真の UTF8 をサポートするには、utf8mb4utf8mb4_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>'@'%';

最後の行にある looker_tmp データベースは、実際に存在していなくてもかまいませんが、内部レポートには grant ステートメントが必要です。

データベース認証情報ファイルを作成する

Looker はどの MySQL データベースと通信し、どの認証情報を使用するかを知る必要があります。Looker ディレクトリに、次の内容のファイルを looker-db.yml という名前で作成し、<DB_hostname><DB_username><DB_password><DB_name> を実際のデータベースの値に置き換えます。

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

SSL データベースで SSL 接続が必要な場合は、looker-db.yml に次の行を追加します。

ssl: true

SSL 証明書の検証も有効にする場合は、looker-db.yml に次の行を追加します。

verify_ssl: true

jdbc_additional_params を追加して、MariaDB JDBC ドライバでサポートされている他の JDBC パラメータを指定することもできます。たとえば、特定のトラストストア ファイルを使用する必要がある場合は、MySQL JDBC 接続文字列に次のパラメータを追加します。

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

顧客がホストするインストールでは、max_connections を追加することで、Looker がデータベースに対して確立できる接続の最大数を任意で指定できます。たとえば、データベースへの同時接続数を 10 に制限するには、次の行を追加します。

max_connections: 10

セキュリティに関する推奨事項: 認証情報をファイルに保存する際は、セキュリティに関するベスト プラクティスに沿って行ってください。理想的には、Looker アプリケーションを実行する Linux アカウントが所有する looker-db.yml ファイルの権限を 600 に設定します。このファイルは Git リポジトリにチェックインしないでください。

Looker の暗号化スキームでは、データベース内のすべてのセンシティブ データは保存時に暗号化されます。誰かが平文のデータベース認証情報にアクセスしてデータベースにアクセスした場合でも、Looker は機密データを暗号化してからハッシュ化してから保存します。これは、パスワード、分析データベースの認証情報、クエリ キャッシュなどに適用されます。ただし、この構成のクリアテキスト パスワードをディスクの looker-db.yml ファイルに保存しない場合は、環境変数 LOOKER_DB を構成して、looker-db.yml ファイルの各行の Key-Value のリストを格納できます。例:

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

セキュリティに関する推奨事項: MySQL ユーザー アカウントの使用は、Looker サーバーで使用される IP アドレスに制限してください。

.db ディレクトリをバックアップする

HyperSQL を復元する必要がある場合に備えて、メモリ内 HyperSQL データベースの構築に必要なファイルが含まれる .db ディレクトリにバックアップします。

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

データベースを移行する

中規模または大規模のインスタンスでデータベースを MySQL に移行する場合、特に HyperSQL データベースが 1 GB 以上の場合、数時間かかることがあります。移行中に EC2 インスタンスを m5.2xlarge に一時的にアップグレードし(手順で指定されている 26 GB のヒープに対応できるように 32 GB の RAM を使用)、時間の短縮(最大 10 分)することをおすすめします。

  1. Looker ホスト上:
    cd looker
    ./looker stop
    vi looker
  1. Looker の起動スクリプトで、ファイルに新しい 2 行目を作成します。
    exit
  1. AWS コンソールでインスタンスを停止します。停止したら、EC2 インスタンスのサイズを m5.2xlarge に変更します。その後、インスタンスを再起動します。

  2. Looker ユーザーとしてホストに SSH 接続します。Java が実行中でないことを確認してから、次のコマンドを実行します。

    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
  1. それが正常に完了したら、AWS コンソールからインスタンスを停止します。

  2. インスタンスを元のサイズに復元できるようになりました。

  3. インスタンスを再起動します。

Looker を起動する

  1. Looker 起動スクリプトを編集し、前に追加した exit 行を削除します。

  2. 起動スクリプトの LOOKERARGS に引数が定義されていないことを確認します。代わりに、引数を lookerstart.cfg ファイルに移動して、新しいバージョンの起動スクリプトで上書きされないようにします。起動スクリプトを保存して終了します。

  3. lookerstart.cfg を編集します。次のようになります。

    LOOKERARGS="-d looker-db.yml"
If there were any other arguments in the Looker startup script, add them to the `lookerstart.cfg` file.
  1. .db ディレクトリがまだアーカイブされていない場合はアーカイブします。
    mv .db .db-backup
    tar -zcvf db-backup.tar.gz ./.db-backup
    rm -rf ./.db-backup/
  1. Looker を起動します。
    ./looker start

Looker が新しいデータベースを使用していることを確認する

Looker がバックエンド MySQL を適切に使用している場合は、Looker インスタンスと新しいデータベース インスタンスとの間のネットワーク接続を確認できます。これを確認するには、Looker インスタンスで次のコマンドを実行します。

netstat -na | grep 3306

データベース インスタンスへの接続がいくつか表示されます。IP アドレス 10.0.3.155 の DB インスタンスを示す出力例を次に示します。

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

Looker のバックアップ

MySQL バックエンドに移行すると、Looker の S3 自動バックアップは機能しなくなります。少なくとも夜間の MySQL データベースのバックアップと、Looker 作業ディレクトリの夜間のファイル システムのバックアップをおすすめします。looker/log/ ディレクトリは、ファイル システムのバックアップから除外される場合があります。詳細については、バックアップの作成に関するドキュメント ページをご覧ください。