RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 		 Visa 
4274 3200 2453 6495 

Глава 6. Работа с шифрованными табличными пространствами InnoDB

MySQL Enterprise Backup понимает шифрованные табличные пространства InnoDB. Для получения дополнительной информации о том, как сервер MySQL шифрует и расшифровывает табличные пространства InnoDB, посмотрите InnoDB Data-at-Rest Encryption это объясняет такие понятия как главный ключ и ключи табличного пространства, которые важны для понимания того, как MySQL Enterprise Backup работает с зашифрованными табличными пространствами InnoDB.

Когда шифрование табличного пространства InnoDB использует Oracle Key Vault (OKV) для управления ключом шифрования, особенность упоминается как MySQL Enterprise Transparent Data Encryption (TDE).

Следующее это краткое описание того, как зашифрованные табличные пространства InnoDB обработаны MySQL Enterprise Backup.

  • MySQL Enterprise Backup 8.0.16 и позже: Encrypted InnoDB undo logs поддерживаются MySQL Enterprise Backup. Зашифрованные табличные пространства отмены обработаны тем же самым путем, как зашифрованные табличные пространства для таблиц InnoDB.

  • MySQL Enterprise Backup 8.0.17 и позже: Encrypted InnoDB redo logs поддерживаются MySQL Enterprise Backup. Зашифрованные табличные пространства журналов отката обработаны тем же самым путем, как зашифрованные табличные пространства для таблиц InnoDB.

Поддержка базы данных с зашифрованными табличными пространствами InnoDB.

MySQL Enterprise Backup, чтобы сделать копию зашифрованных табличных пространств InnoDB, пользователь операционной системы, который управляет MySQL Enterprise Backup, должен иметь разрешение на запись для файла брелка на сервере, если на нем используется плагин keyring_file или keyring_aws.

Когда использование базы данных зашифровало табличные пространства InnoDB, MySQL Enterprise Backup всегда сохранит главный ключ для шифрования в зашифрованном файле в резервной копии, независимо от вида плагина брелка, используемого сервером. Следующее это типичная команда для поддержки базы данных, содержащей зашифрованные табличные пространства InnoDB:

$ mysqlbackup --defaults-file=/home/dbadmin/my.cnf \
              --backup-image=/home/admin/backups/my.mbi \
              --backup-dir=/home/admin/backup-tmp \
              --encrypt-password="password" \
              backup-to-image

Во время операции резервного копирования mysqlbackup копирует зашифрованные файлы табличного пространства InnoDB в резервную копию, а также выполняет следующие действия:

  • mysqlbackup связывается с сервером MySQL, чтобы определить плагин брелка, который использует сервер, это в настоящее время один из keyring_encrypted_file, keyring_file, keyring_okv, keyring_aws или keyring_hashicorp.

  • Если сервер использует плагин keyring_encrypted_file, пользователь должен использовать опцию --encrypt-password, чтобы дать mysqlbackup пароль шифрования файла брелка, который был установлен на сервере опцией --keyring_encrypted_file_password. mysqlbackup копирует с сервера зашифрованный файл данных брелка, который содержит главный ключ, используемый, чтобы зашифровать все ключи табличного пространства, в каталог meta в резервной копии. Зашифрованные файлы табличного пространства также копируются в резервную копию.

  • Если сервер использует плагин брелка кроме keyring_encrypted_file, mysqlbackup получает доступ к брелку, чтобы получить главный ключ и использует его, чтобы расшифровать зашифрованные ключи табличного пространства, которые использовались, чтобы зашифровать табличные пространства InnoDB на сервере. Главный ключ тогда помещается в файл данных брелка, названный keyring_kef м сохраняется в каталоге meta в резервной копии, файл зашифрован паролем пользователя, поставляемым опцией --encrypt-password.

    • Пользователи, которые не хотят поставлять пароль в командной строке или в файле по умолчанию, могут использовать опцию --encrypt-password, не определяя значение. mysqlbackup спросит пользователя о пароле. Это относится ко всем командам, которые используют опцию --encrypt-password.

    • Если сервер использует плагин keyring_hashicorp, используйте --encrypt-password, чтобы предоставить HashiCorp Vault AppRole ID, который был значением keyring_hashicorp_secret_id на сервере, который будет поддержан.

Команды extract или image-to-backup-dir для резервного копирования образа, содержащего зашифрованные табличные пространства InnoDB, не требует опции --encrypt-password.

Восстановление резервной копии с зашифрованными табличными пространствами InnoDB. Следующее это типичная команда для восстановления однофайловой резервной копии, содержащий зашифрованные табличные пространства InnoDB:

$ mysqlbackup --defaults-file=/usr/local/mysql/my.cnf \
              --backup-image=/home/admin/backups/my.mbi \
              --backup-dir=/home/admin/restore-tmp \
              --encrypt-password="password" \
              copy-back-and-apply-log

Тот же самый пароль, используемый для поддержки базы данных, должен поставляться в опции --encrypt-password для операции восстановления. Во время восстановления mysqlbackup копирует зашифрованные файлы табличного пространства InnoDB и зашифрованный файл, содержащий главные ключи (keyring_kef) на сервер. Это также выполняет следующие действия:

  • MySQL Enterprise Server: mysqlbackup вернет зашифрованный файл данных брелка к его надлежащему местоположению на сервере. Восстановленный сервер должен быть запущен с плагином keyring_encrypted_file с опциями keyring_encrypted_file_data и --keyring_encrypted_file_password (которые должны поставить серверу тот же самый пароль, используемый с опцией --encrypt-password во время восстановления).

  • MySQL Community Server: Плагин keyring_file это единственный плагин брелка, поддержанный MySQL Community Server, поэтому mysqlbackup использует пароль, поставляемый опцией --encrypt-password, чтобы расшифровать файл данных брелка и затем вернул его к надлежащему местоположению на сервере для плагина keyring_file.

Для возрастающих резервных копий. Для ряда возрастающих резервных копий, если плагин брелка кроме keyring_encrypted_file используется на сервере, пользователи могут предоставить различное значение --encrypt-password для любого полного резервного копирования или инкрементного резервного копирования в резервной последовательности. Однако, пароль, используемый, чтобы сделать определенное полное резервное копирование или инкрементное резервное копирование, должен быть обеспечен, чтобы восстановить ту резервную копию. Начиная сервер после восстановления ряда возрастающих резервных копий, пароль, используемый для того, чтобы восстанавливать последнее инкрементное резервное копирование, должен поставляться серверу (за исключением MySQL Community Server, который запустится с плагином keyring_file и не требует опции --keyring_encrypted_file_password).

Дополнительно: Создание и восстановление каталога с зашифрованными табличными пространствами InnoDB. Следующее это типичная команда для создания директивной резервной копии, содержащей зашифрованные табличные пространства InnoDB:

$ mysqlbackup --defaults-file=/home/dbadmin/my.cnf \
              --backup-dir=/home/admin/backup \
              --encrypt-password="password" backup

Следующее это типичная команда для подготовки резервной копии с apply-log:

$ mysqlbackup --backup-dir=/home/admin/backup \
              --encrypt-password="password" apply-log

Заметьте, что пароль пользователя должен поставляться опцией --encrypt-password как ключи табличного пространства, а затем табличные пространства должны быть расшифрованы, прежде чем журнал может быть применен. То же самое требование применяется, когда вы пытаетесь обновить зашифрованную резервную копию с зашифрованным инкрементным резервным копированием, используя команду apply-incremental-backup:

$ mysqlbackup --backup-dir=/home/admin/backup \
              --incremental-backup-dir=/home/admin/backup-in \
              --encrypt-password="password" \
              apply-incremental-backup

Если вы использовали различные значения для --encrypt-password для полных или возрастающих резервных копий в резервной последовательности удостоверьтесь, что вы поставляете тот же самый пароль, с которым вы раньше создавали отдельную резервную копию, когда вы выполняете apply-log или apply-incremental-backup.

Затем команда copy-back восстанавливает подготовленную резервную копию на сервере:

$ mysqlbackup --defaults-file=/usr/local/mysql/my.cnf \
              --backup-dir=/home/admin/backup copy-back

Заметьте, что опция --encrypt-password не требуется для этого шага.

Можно объединить два шага apply-log и copy-back в один, запуская команду copy-back-and-apply-log, для который требуется опция for which the --encrypt-password:

$ mysqlbackup --defaults-file=/usr/local/mysql/my.cnf \
              --backup-dir=/home/admin/backup \
              --encrypt-password="password" \
              copy-back-and-apply-log

Ограничения. Определенные ограничения применяются, когда MySQL Enterprise Backup работает с зашифрованными табличными пространствами InnoDB:

  • MySQL Enterprise Backup 8.0.20 и ранее: Во время операции validate, если mysqlbackup сталкивается с зашифрованными табличными пространствами InnoDB, это выпускает предупреждение и затем перескакивает через них.

  • MySQL Enterprise Backup 8.0.20 и ранее: Для частичных резервных копий, используя транспортабельные табличные области (то есть, когда используется опция --use-tts), зашифрованные таблицы InnoDB никогда не включаются в резервную копию. Предупреждение выпущено в файле журнала каждый раз, когда через зашифрованную таблицу InnoDB, которая соответствует критериям выбора, перескочили.

  • Опция --skip-unused-pages не имеет никакого эффекта на зашифрованные таблицы InnoDB во время изготовления резервной копии (то есть, пустые страницы для тех таблиц не пропускаются).

  • Если сервер выполняет master key rotation когда резервная копия создается, получающаяся резервная копия могла бы стать испорченной.

Поиск

  

Найди своих коллег!

Вы можете направить письмо администратору этой странички, Алексею Паутову. mailto:alexey.v.pautov@mail.ru