Задний план: Я перемещаю некоторых клиентов на экземпляр SQL-сервера AWS RDS. У каждого есть две базы данных: одна для их реальных данных, а другая для обучающих данных, которые являются копией их текущих данных. База данных обучения поддерживается в актуальном состоянии за счет регулярного восстановления ее с помощью действующей базы данных. В идеале эти базы данных должны размещаться в одном экземпляре RDS, поскольку они не такие большие, и это снизит стоимость хостинга вдвое.
Проблема: Amazon имеет следующие ограничения в их документации:
You can't restore a backup file to the same DB instance that was used to create the backup file. Instead, restore the backup file to a new DB instance. Renaming the database is not a workaround for this limitation.
You can't restore the same backup file to a DB instance multiple times. That is, you can't restore a backup file to a DB instance that already contains the database that you are restoring. Renaming the database is not a workaround for this limitation.
Так что резервное копирование живой базы данных и восстановление ее в учебной базе данных, как я обычно делал бы, нет. Какой у меня лучший вариант, кроме размещения двух отдельных экземпляров для каждого клиента?
Я предполагаю, что единственный способ обойти эту проблему - использовать Generate Scripts, чтобы создать сценарий для вашей БД и импортировать его в другой экземпляр DB того же экземпляра RDS. docs.microsoft.com/en-us/sql/relational-databases/scripting/…
Если вы используете обучающую базу данных только для чтения, рассмотрите возможность использования реплики для чтения. Это также избавит вас от постоянного резервного копирования производства и возобновления обучения.
Просто сделайте это так же, как если бы вы делали это с традиционным SQL Server, вместо того, чтобы использовать предоставленную возможность создания моментальных снимков.
@JohnRotenstein - экземпляры RDS разрешают резервное копирование только в хранилище S3 в том же регионе, что и относится к примечаниям документации OP. Возможность создания снимков - это межрегиональная функция. Я бы хотел, чтобы мы выполняли резервное копирование непосредственно на диск, как с обычным SQL Server, но, увы ... параметры резервного копирования / восстановления для RDS оставляют желать лучшего.
Хотя можно сгенерировать сценарий для базы данных, импортировать его в другое место, создать резервную копию и восстановить его обратно в исходный экземпляр, в моем случае это было не лучшим решением. Мне пришлось отказаться от использования экземпляра RDS и пойти по более традиционному пути размещения нескольких обучающих баз данных на экземпляре Windows EC2.
Я смотрю на тот же сценарий, и для создания очищенной копии db мне понадобится отдельный экземпляр RDS и длительное время процесса для 1) резервного копирования и нажатия на S3, 2) восстановления с S3 на экземпляр scrub RDS, 3 ) очистить базу данных, 4) сделать резервную копию на S3 (снова), 4) позволить моей команде поддержки получить доступ к очищенной копии. Вряд ли идеально ...
Отличные новости:
Ограничение, указанное ранее в документация RDS, было снято:
You can't restore a backup file to the same DB instance that was used to create the backup file. Instead, restore the backup file to a new DB instance. Renaming the database is not a workaround for this limitation.
You can't restore the same backup file to a DB instance multiple times. That is, you can't restore a backup file to a DB instance that already contains the database that you are restoring. Renaming the database is not a workaround for this limitation.
Я только что протестировал это и смог без проблем восстановить одну и ту же резервную копию в разные имена баз данных на одном и том же RDS SQL Server, используя хранимую процедуру msdb.dbo.rds_restore_database
, как определено в связанной документации.
Очень веская причина для клиентов SQL Server не переходить на AWS, это глупое ограничение, и я думаю, что Amazon не торопится его решать, вероятно, потому, что это отговаривает нас использовать SQL Server.