Управление резервными копиями в Managed Service for MySQL

Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы получить список резервных копий кластеров MySQL, доступных в каталоге по умолчанию, выполните команду:

yc managed-mysql backup list

Результат:

+--------------------------+---------------------+----------------------+---------------------+
|            ID            |     CREATED AT      |  SOURCE CLUSTER ID   |     STARTED AT      |
+--------------------------+---------------------+----------------------+---------------------+
| c9qgo11pud7kb3cdomeg...  | 2020-08-10 12:00:00 | c9qgo11pud7kb3cdomeg | 2020-08-10 11:55:17 |
| ...                                                                                         |
+--------------------------+---------------------+----------------------+---------------------+

Чтобы получить список резервных копий кластера, воспользуйтесь методом API listBackups и передайте в запросе идентификатор кластера в параметре clusterId.

Чтобы получить список резервных копий всех кластеров Managed Service for MySQL в каталоге, воспользуйтесь методом API list и передайте идентификатор каталога в параметре folderId запроса.

Идентификатор кластера можно получить со списком кластеров в каталоге.

Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы получить данные о резервной копии кластера MySQL, выполните команду:

yc managed-mysql backup get <идентификатор резервной копии>

Идентификатор резервной копии можно получить со списком резервных копий.

Воспользуйтесь методом API get и передайте идентификатор резервной копии в параметре backupId запроса.

Чтобы узнать идентификатор, получите список резервных копий.

Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы создать резервную копию кластера:

1. Посмотрите описание команды CLI для создания резервной копии кластера MySQL:

   yc managed-mysql cluster backup --help
   

2. Запросите создание резервной копии, указав идентификатор или имя кластера:

   yc managed-mysql cluster backup <идентификатор или имя кластера>
   

   Идентификатор и имя кластера можно получить со списком кластеров.

Воспользуйтесь методом API backup и передайте в запросе идентификатор кластера в параметре clusterId.

Идентификатор кластера можно получить со списком кластеров в каталоге.

Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы восстановить кластер из резервной копии:

1. Посмотрите описание команды CLI для восстановления кластера MySQL:

   yc managed-mysql cluster restore --help
   

2. Получите список доступных резервных копий MySQL-кластеров:

   yc managed-mysql backup list
   

   Результат:

   +--------------------------+---------------------+----------------------+---------------------+
   |            ID            |     CREATED AT      |  SOURCE CLUSTER ID   |     STARTED AT      |
   +--------------------------+---------------------+----------------------+---------------------+
   | c9qgo11pud7kb3cdomeg...  | 2020-08-10 12:00:00 | c9qgo11pud7kb3cdomeg | 2020-08-10 11:55:17 |
   | ...                                                                                         |
   +--------------------------+---------------------+----------------------+---------------------+
   

   Время завершения создания резервной копии указано в столбце CREATED AT списка доступных резервных копий в формате yyyy-mm-dd hh:mm:ss (2020-08-10 12:00:00 в примере выше). Вы можете восстановить состояние кластера на любой момент времени, начиная от создания резервной копии.

3. Запросите создание кластера из резервной копии:

   yc managed-mysql cluster restore \
      --backup-id=<идентификатор резервной копии> \
      --time=<момент времени, на который нужно восстановить состояние кластера MySQL> \
      --name=<имя кластера> \
      --environment=<окружение: PRESTABLE или PRODUCTION> \
      --network-name=<имя сети> \
      --host zone-id=<зона доступности>,`
            `subnet-name=<имя подсети>`
            `assign-public-ip=<доступ к хосту через публичный IP-адрес: true или false> \
      --resource-preset=<класс хоста> \
      --disk-size=<размер хранилища в гигабайтах> \
      --disk-type=<тип диска>
   

   Где:

   • --backup-id — идентификатор резервной копии.

   • --time — момент времени, на который нужно восстановить состояние кластера MySQL, в формате yyyy-mm-ddThh:mm:ssZ.

   • --name — имя кластера.

   • --environment — окружение:

     • PRESTABLE — для тестирования, в том числе самого сервиса MySQL. В Prestable-окружении раньше появляются новая функциональность, улучшения и исправления ошибок. При этом не все обновления обеспечивают обратную совместимость.
     • PRODUCTION — для стабильных версий ваших приложений.

   • --network-name — имя сети.

   • --host — параметры хоста:

     • zone-id — зона доступности.

     • subnet-name — имя подсети. Необходимо указывать, если в выбранной зоне доступности создано две или больше подсетей.

     • assign-public-ip — флаг, который указывается, если хосту требуется публичный IP-адрес.

   • --resource-preset — класс хоста.

   • --disk-size — размер хранилища в гигабайтах.

   • --disk-type — тип диска:

     • network-hdd;
     • network-ssd;
     • local-ssd;
     • network-ssd-nonreplicated.

Используйте Terraform для восстановления:

• Существующего кластера из резервной копии.
• Кластера, созданного и удаленного через Консоль управления, CLI или API.

Для восстановления потребуется ID резервной копии. Получите список доступных резервных копий MySQL-кластеров с помощью CLI:

yc managed-mysql backup list

Результат:

+--------------------------+---------------------+----------------------+---------------------+
|            ID            |     CREATED AT      |  SOURCE CLUSTER ID   |     STARTED AT      |
+--------------------------+---------------------+----------------------+---------------------+
| c9qgo11pud7kb3cdomeg...  | 2020-08-10 12:00:00 | c9qgo11pud7kb3cdomeg | 2020-08-10 11:55:17 |
| ...                                                                                         |
+--------------------------+---------------------+----------------------+---------------------+

Чтобы восстановить из резервной копии существующий кластер:

1. Создайте конфигурационный файл Terraform для нового кластера.

   При этом не используйте ресурсы баз данных (yandex_mdb_mysql_database) и пользователей (yandex_mdb_mysql_user) — они будут восстановлены из резервной копии.

2. Добавьте в этот конфигурационный файл блок restore:

   resource "yandex_mdb_mysql_cluster" "<имя кластера>" {
     ...
     restore {
       backup_id = "<имя нужной резервной копии>"
       time      = "<временная метка момента восстановления в формате yyyy-mm-ddThh:mm:ss>"
     }
   }
   

   В параметре time укажите момент времени, на который нужно восстановить состояние MySQL-кластера, начиная со времени создания выбранной резервной копии.

   Примечание

   Параметр time не является обязательным. Если его не указывать, кластер будет восстановлен на момент запуска процесса восстановления.

3. Проверьте корректность настроек.

   1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

   2. Выполните команду:

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

4. Подтвердите изменение ресурсов.

   1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

      Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

   2. Если вас устраивают планируемые изменения, внесите их:

      1. Выполните команду:

         terraform apply
         

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

Terraform создаст копию существующего кластера. Базы данных и пользователи будут развернуты из выбранной резервной копии.

resource "yandex_mdb_mysql_cluster" "<имя кластера>" {
  ...
  timeouts {
    create = "1h30m" # Полтора часа
    update = "2h"    # 2 часа
    delete = "30m"   # 30 минут
  }
}

Чтобы восстановить из резервной копии удаленный ранее кластер:

1. Создайте конфигурационный файл Terraform для нового кластера.

   При этом не используйте ресурсы баз данных (yandex_mdb_mysql_database) и пользователей (yandex_mdb_mysql_user) — они будут восстановлены из резервной копии.

2. Добавьте в этот конфигурационный файл блок restore с именем резервной копии, из которой нужно восстановиться:

   resource "yandex_mdb_mysql_cluster" "<имя кластера>" {
     ...
     restore {
         backup_id = "<идентификатор резервной копии удаленного кластера>"
     }
   }
   

3. Проверьте корректность настроек.

   1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

   2. Выполните команду:

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

4. Подтвердите изменение ресурсов.

   1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

      Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

   2. Если вас устраивают планируемые изменения, внесите их:

      1. Выполните команду:

         terraform apply
         

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

Terraform создаст новый кластер. Базы данных и пользователи будут развернуты из резервной копии.

Подробнее см. в документации провайдера Terraform.

resource "yandex_mdb_mysql_cluster" "<имя кластера>" {
  ...
  timeouts {
    create = "1h30m" # Полтора часа
    update = "2h"    # 2 часа
    delete = "30m"   # 30 минут
  }
}

Воспользуйтесь методом API restore и передайте в запросе:

• Идентификатор требуемой резервной копии в параметре backupId. Чтобы узнать идентификатор, получите список резервных копий в кластере.
• Момент времени, на который должен быть восстановлен кластер, в параметре time.
• Имя нового кластера, который будет содержать восстановленные из резервной копии данные, в параметре name. Имя кластера должно быть уникальным в рамках каталога.

Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Задать время начала резервного копирования в существующем кластере можно с помощью команды update:

yc managed-mysql cluster update <идентификатор или имя кластера> \
   --backup-window-start=<время начала резервного копирования, по UTC в формате `HH:MM:SS`>

Идентификатор и имя кластера можно получить со списком кластеров.

1. Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.

   О том, как создать такой файл, см. в разделе Создание MySQL-кластера.

2. Добавьте к описанию кластера Managed Service for MySQL блок backup_window_start:

   resource "yandex_mdb_mysql_cluster" "<имя кластера>" {
     ...
     backup_window_start {
       hours   = <Час начала резервного копирования (UTC)>
       minutes = <Минута начала резервного копирования (UTC)>
     }
   }
   

3. Проверьте корректность настроек.

   1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

   2. Выполните команду:

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

4. Подтвердите изменение ресурсов.

   1. Выполните команду для просмотра планируемых изменений:

      terraform plan
      

      Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

   2. Если вас устраивают планируемые изменения, внесите их:

      1. Выполните команду:

         terraform apply
         

      2. Подтвердите изменение ресурсов.

      3. Дождитесь завершения операции.

Подробнее см. в документации провайдера Terraform.

resource "yandex_mdb_mysql_cluster" "<имя кластера>" {
  ...
  timeouts {
    create = "1h30m" # Полтора часа
    update = "2h"    # 2 часа
    delete = "30m"   # 30 минут
  }
}

Воспользуйтесь методом update и передайте в запросе:

• Идентификатор кластера в параметре clusterId. Его можно получить со списком кластеров в каталоге.
• Новое время начала резервного копирования в параметре configSpec.backupWindowStart.
• Список изменяемых полей конфигурации кластера в параметре updateMask (в данном случае — configSpec.backupWindowStart).

Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы задать приоритет резервного копирования для выбранного хоста, выполните команду:

yc managed-mysql host update <имя хоста> \
   --cluster-name=<имя кластера> \
   --backup-priority=<приоритет хоста при резервном копировании: от 0 до 100>

Имя хоста можно запросить со списком хостов в кластере, имя кластера — со списком кластеров в каталоге.

Чтобы задать приоритет хоста, воспользуйтесь методом updateHosts и передайте в запросе:

• Идентификатор кластера в параметре clusterId. Его можно получить со списком кластеров в каталоге.
• Имя хоста в параметре updateHostSpecs.hostName. Его можно получить со списком хостов в кластере.
• Новое значение приоритета хоста в параметре updateHostSpecs.backupPriority.
• Список полей конфигурации кластера, подлежащих изменению (в данном случае — updateHostSpecs.hostName и updateHostSpecs.backupPriority), в параметре updateMask.