Google Cloud показала, как уменьшить диск Cloud SQL для SQL Server почти без простоя

Google Cloud описала способ уменьшить диск инстанса Cloud SQL для SQL Server через Database Migration Service (DMS) с коротким переключением вместо многочасового простоя. Штатное сжатие диска в Cloud SQL требует остановки инстанса, и время простоя растёт вместе с выделенным объёмом: для дисков в несколько терабайт это часы. Схема с DMS переносит базы на новый инстанс с диском нужного размера, пока приложение продолжает работать.

Репликация в DMS устроена как log shipping в SQL Server. Сначала сервис снимает полную резервную копию выбранных пользовательских баз (.bak) и восстанавливает её на целевом инстансе, затем непрерывно применяет копии журналов транзакций (.trn). Синхронизация идёт на уровне пользовательской базы, поэтому логины, связанные серверы и задания SQL Server Agent в неё не попадают.

Изображение: Google Cloud Blog

Порядок действий: создать целевой инстанс с меньшим диском и запасом под журналы и будущий рост данных, запустить непрерывную репликацию, дождаться, пока отставание станет минимальным, и переключиться. На переключении трафик приложения останавливают, применяют последний журнал, повышают целевой инстанс в DMS и переводят приложение на новый адрес.

Перед переключением объекты уровня сервера переносят вручную. Логины скриптуют через sp_help_revlogin, чтобы сохранить идентификаторы безопасности (SID). Задания Agent, связанные серверы и сессии расширенных событий выгружают скриптами CREATE в SSMS; для связанных серверов на инстансе включают флаг cloudsql.linked_servers. Инстансам с TDE нужен перенос сертификата, а флаги баз данных, конфигурацию Active Directory и Entra ID на целевом инстансе настраивают заново.

Изображение: Google Cloud Blog

После переключения пользователи баз могут остаться без привязки к логинам: новые логины получают собственные SID, которые не совпадают с сохранёнными в перенесённых базах. Таких «осиротевших» пользователей находят запросом по sys.database_principals и sys.server_principals и привязывают командой ALTER USER ... WITH LOGIN.

Изображение: Google Cloud Blog

Решать, нужен ли перенос, Google советует по метрикам Cloud Monitoring database/disk/bytes_used и database/disk/quota: если выделенная квота заметно больше фактически занятого места, диск можно уменьшить. Автосжатие AUTO_SHRINK в продакшене не рекомендуют из-за фрагментации индексов, а файлы сжимают вручную через DBCC SHRINKFILE. Цену DMS компания в материале не называет; выгода — в снижении расходов на хранение.