sql >> データベース >  >> RDS >> Mysql

MySQL8.0用のPerconaServerを使用して暗号化されたデータベースをバックアップする方法

    生産の中断は、ある時点で発生することがほぼ保証されています。私たちはそれを知っているので、バックアップを計画し、リカバリスタンバイデータベースを作成し、単一のインスタンスをクラスターに変換します。

    適切な復旧シナリオの必要性を認め、考えられる災害のタイムラインと障害のシナリオを分析し、データベースを起動するための手順を実装する必要があります。計画的な停止の実行は、次の停止の準備、診断、および回復に役立ちます。ダウンタイムの影響を軽減するために、組織は適切な復旧計画を必要とします。これには、サービスを実現するために必要なすべての要素が含まれます。

    バックアップ管理は、バックアップジョブをスケジュールするほど穏やかではありません。保持、保存、検証、取得するバックアップが物理的か論理的か、セキュリティを見落としがちなものなど、考慮すべき多くの要素があります。

    多くの組織は、サーバーイメージのバックアップ(スナップショット)、論理バックアップと物理バックアップの組み合わせを複数の場所に保存しようとして、バックアップへのアプローチを変えています。同じデータセンターに保存されているデータベースとバックアップを一掃するような、地域または地域の災害を回避するためです。

    安全にしたい。データとバックアップは暗号化する必要があります。しかし、両方のオプションが用意されている場合、多くの影響があります。この記事では、暗号化されたデータベースを扱う場合のバックアップ手順について説明します。

    MySQL8.0用のPerconaServerの暗号化の保存

    MySQL 5.7.11から、コミュニティバージョンのMySQLがInnoDBテーブルスペース暗号化のサポートを開始しました。これは、透過表スペース暗号化と呼ばれるか、または暗号化アットレストと呼ばれます。

    エンタープライズバージョンとの主な違いは、キーの保存方法です。キーは、規制への準拠に必要な安全な保管庫に配置されていません。同じことがPerconaServerにも当てはまり、バージョン5.7.11以降、InnoDBテーブルスペースを暗号化することができます。 Percona Server 8.0では、バイナリログの暗号化のサポートが大幅に拡張されました。バージョン8.0が追加されました

    (Percona 8.0リリースドキュメントによる):

      一時ファイルの暗号化
    • InnoDB Undo Tablespace Encryption
    • InnoDBシステムテーブルスペース暗号化(InnoDBシステムテーブルスペース暗号化)
    • default_table_encryption =OFF / ON(一般的なテーブルスペース暗号化)
    • table_encryption_privilege_check =OFF / ON(暗号化設定の確認)
    • InnoDB REDOログ暗号化(マスターキー暗号化のみ)(Redoログ暗号化)
    • InnoDBマージファイルの暗号化(暗号化設定の確認)
    • Percona並列ダブルライトバッファー暗号化(InnoDBテーブルスペース暗号化)

    興味のある方へ-MySQLEnterpriseバージョンからPerconaへの移行-OracleのMySQLEnterpriseエディションで利用可能な機能と一致するkeyring_vaultプラグインを介してHashicorpVaultサーバーと統合することも可能です。

    保存データの暗号化には、キーリングプラグインが必要です。ここには2つのオプションがあります:

    • keyring_file-暗号化キーを備えたフラットファイル
    • KeyringVaultプラグイン-サービス

    テーブルスペース暗号化を有効にする方法

    暗号化を有効にするには、-early-plugin-loadオプションを使用してデータベースを起動します。

    手作業で:

    $ mysqld --early-plugin-load="keyring_file=keyring_file.so"

    または構成ファイルを変更する:

    [mysqld]
    
    early-plugin-load=keyring_file.so

    Percona Server 8.0を起動すると、2種類のテーブルスペースを暗号化できます。一般表領域とシステム表領域。 Sysテーブルスペースは、パラメーターinnodb_sys_tablespace_encryptを介して制御されます。デフォルトでは、sysテーブルスペースは暗号化されていません。すでに暗号化されている場合、暗号化された状態に変換することはできません。新しいインスタンスを作成する必要があります(--bootstrapオプションを使用してインスタンスを開始します)。

    一般的なテーブルスペースは、テーブルスペース内のすべてのテーブルの暗号化をサポートするか、暗号化をサポートしません。混合モードで暗号化を実行することはできません。暗号化されたateテーブルスペースを作成するには、ENCRYPTION ='Y/N'フラグを使用します。

    例:

    mysql> CREATE TABLESPACE severalnines ADD DATAFILE 'severalnines.ibd' ENCRYPTION='Y';
    暗号化されたデータベースのバックアップ

    暗号化されたテーブルスペースを追加するときは、xtrabackupコマンドにキーリングファイルを含める必要があります。これを行うには、キーリングファイルへのパスを--keyring-file-dataオプションの値として指定する必要があります。

    $ xtrabackup --backup --target-dir=/u01/mysql/data/backup/ --user=root --keyring-file-data=/u01/secure_location/keyring_file
    キーリングファイルは必ず安全な場所に保管してください。また、常にファイルのバックアップをとってください。 Xtrabackupは、バックアップディレクトリ内のキーリングファイルをコピーしません。バックアップを準備するには、キーリングファイルのコピーを自分で作成する必要があります。

    バックアップの準備

    バックアップファイルを取得したら、リカバリの準備をする必要があります。ここでは、keyring-file-dataも指定する必要があります。

    $ xtrabackup --prepare --target-dir=/u01/mysql/data/backup/ --keyring-file-data=/u01/secure_location/keyring_file

    これでバックアップが準備され、-copy-backオプションを使用して復元できます。キーリングが回転している場合は、キーリング(バックアップの作成と準備に使用されたもの)を復元する必要があります。

    バックアップエクストラバックアップを準備するには、キーリングにアクセスする必要があります。 XtrabackupはMySQLサーバーと直接通信せず、準備中にデフォルトのmy.cnf構成ファイルを読み取りません。コマンドラインからキーリング設定を指定します:

    $ xtrabackup --prepare --target-dir=/data/backup --keyring-vault-config=/etc/vault.cnf

    これでバックアップが準備され、-copy-backオプションを使用して復元できます:

    $ xtrabackup --copy-back --target-dir=/u01/backup/ --datadir=/u01/mysql/data/
    増分バックアップの実行

    InnoDBテーブルスペース暗号化を使用して増分バックアップを作成するプロセスは、暗号化されていないテーブルスペースを使用して同じ増分バックアップを作成するプロセスと似ています。

    増分バックアップを作成するには、完全バックアップから始めます。 xtrabackupバイナリは、xtrabackup_checkpointsというファイルをバックアップのターゲットディレクトリに書き込みます。このファイルには、バックアップ終了時のデータベースのLSNであるto_lsnを示す行が含まれています。

    まず、次のコマンドを使用して完全バックアップを作成する必要があります。

    $ xtrabackup --backup --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

    完全バックアップができたので、それに基づいて増分バックアップを作成できます。次のようなコマンドを使用します。

    $ xtrabackup --backup --target-dir=/data/backups/inc1 \
    
    --incremental-basedir=/data/backups/base \
    
    --keyring-file-data=/var/lib/mysql-keyring/keyring

    / data / backups / inc1 /ディレクトリには、ibdata1.deltaやtest/table1.ibd.deltaなどのデルタファイルが含まれているはずです。

    意味は自明である必要があります。このディレクトリをさらに別の増分バックアップのベースとして使用できるようになりました:

    $ xtrabackup --backup --target-dir=/data/backups/inc2 \
    
    --incremental-basedir=/data/backups/inc1 \
    
    --keyring-file-data=/var/lib/mysql-keyring/keyring
    増分バックアップの準備

    これまでのところ、データベースのバックアッププロセスは、キーリングファイルの場所を指定したフラグを除いて、通常のバックアップと同様です。

    残念ながら、増分バックアップの--prepareステップは、通常のバックアップの場合と同じではありません。

    通常のバックアップでは、データベースの整合性を保つために2種類の操作が実行されます。コミットされたトランザクションはログファイルからデータファイルに対して再生され、コミットされていないトランザクションはロールバックされます。バックアップの準備時にコミットされていないトランザクションのロールバックをスキップする必要があります。これは、バックアップ時にコミットされていなかったトランザクションが進行中であり、次の増分バックアップでコミットされる可能性があるためです。ロールバックフェーズを防ぐには、-apply-log-onlyオプションを使用する必要があります。

    ロールバックフェーズを防ぐために--apply-log-onlyオプションを使用しない場合、増分バックアップは役に立ちません。トランザクションがロールバックされた後は、それ以上の増分バックアップを適用できません。

    作成した完全バックアップから始めて、それを準備してから、増分の差を適用することができます。次のバックアップがあることを思い出してください。

    /data/backups/base
    
    /data/backups/inc1
    
    /data/backups/inc2

    ベースバックアップを準備するには、通常どおり--prepareを実行する必要がありますが、ロールバックフェーズは実行しないでください。

    $ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

    最初の増分バックアップを完全バックアップに適用するには、次のコマンドを使用する必要があります。

    $ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \
    
    --incremental-dir=/data/backups/inc1 \
    
    --keyring-file-data=/var/lib/mysql-keyring/keyring

    ベースバックアップと増分バックアップの間でキーリングがローテーションされている場合は、最初の増分バックアップが作成されたときに使用されていたキーリングを使用する必要があります。

    2番目の増分バックアップの準備も同様のプロセスです

    $ xtrabackup --prepare --target-dir=/data/backups/base \
    
    --incremental-dir=/data/backups/inc2 \
    
    --keyring-file-data=/var/lib/mysql-keyring/keyring
    注; --apply-log-onlyは、最後の増分を除くすべての増分をマージするときに使用する必要があります。そのため、前の行には--apply-log-onlyオプションが含まれていません。最後のステップで--apply-log-onlyが使用された場合でも、バックアップは一貫性がありますが、その場合、サーバーはロールバックフェーズを実行します。
    最後のステップは--copy-backを使用して復元することです。オプション。キーリングが回転している場合は、バックアップの作成と準備に使用したキーリングを復元する必要があります。

    説明されている復元方法は機能しますが、サーバーが使用しているのと同じキーリングにアクセスする必要があります。別のサーバーでバックアップが準備されている場合、またはかなり後で、キーリングのキーが削除された場合、または誤動作の場合、キーリングボールトサーバーがまったく使用できない場合は、不可能な場合があります。

    --transition-key =オプションを使用して、xtrabackupがキーリングボールトサーバーにアクセスせずにバックアップを処理できるようにする必要があります。この場合、xtrabackupは指定されたパスフレーズからAES暗号化キーを取得し、それを使用して、バックアップされているテーブルスペースのテーブルスペースキーを暗号化します。

    パスフレーズを使用したバックアップの作成

    次の例は、この場合のバックアップの作成方法を示しています。

    $ xtrabackup --backup --user=root -p --target-dir=/data/backup \
    
    --transition-key=MySecetKey
    生成されたキーを使用したバックアップの復元

    バックアップを復元するときは、新しいマスターキーを生成する必要があります。 keyring_fileの例を次に示します。

    $ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \
    
    --transition-key=MySecetKey --generate-new-master-key \
    
    --keyring-file-data=/var/lib/mysql-keyring/keyring

    keyring_vaultの場合、次のようになります。

    $ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \
    
    --transition-key=MySecetKey --generate-new-master-key \
    
    --keyring-vault-config=/etc/vault.cnf

    1. 結果を除算するためのSQLの10進値

    2. 「ALTERTABLESWITCHステートメントが失敗しました」を修正する方法

    3. MariaDBクラスターを使用したAmazonAWSでのホットスタンバイの構築

    4. MySQLパフォーマンスチューニングに関する10の役立つヒント