Cloud SQL for SQL Server diskini DMS ile kısa kesintiyle küçültmek

Google Cloud, Cloud SQL disk küçültme işlemini Database Migration Service (DMS) ile kısa kesintiyle yapmanın yolunu anlattı. Yöntemde Cloud SQL for SQL Server instance’ı kaynak olarak kullanılıyor, veritabanları daha küçük diskli yeni bir instance’a sürekli replike ediliyor ve kısa bir cutover ile geçiliyor. Yerleşik shrink özelliğinde ise kesinti süresi ayrılmış toplam disk boyutuyla orantılı uzuyor.

Database Migration Service nedir, ne işe yarar?

Database Migration Service (DMS), Google Cloud’un yönetilen veritabanı taşıma servisidir. MySQL, PostgreSQL ve SQL Server gibi motorlarda kaynaktan hedefe sürekli replikasyon kurup kısa bir geçişle taşıma yapmak için kullanılır. Genellikle şirket içi ya da başka buluttaki veritabanlarını Cloud SQL’e almak için tercih edilir. Diğer bulutlarda AWS Database Migration Service ve Azure Database Migration Service benzer işi görür.

Cloud SQL disk küçültme için iki yol

Cloud SQL’de disk tek yönlü büyür. Automatic storage increase bir batch import ya da index bakımında diski büyütür, iş bitince o kapasite faturada kalır. Veriyi BigQuery’ye arşivleseniz de persistent disk küçülmez.

Yerleşik shrink özelliği işi görür. Ama instance kapalıyken çalışır ve süre ayrılmış disk boyutuyla orantılı uzar. Birkaç TB’lık diskte bu saatler demek.

DMS yolu farklı çalışır. Doğru boyutta yeni bir instance açarsınız, DMS ilk olarak full backup (.bak) alıp hedefe restore eder, ardından transaction log backup’larını (.trn) sürekli uygular. Uygulama bu sürede eski instance’ta çalışmaya devam eder. Kesinti yalnızca son log’un uygulanıp hedefin promote edildiği cutover anıdır.

Seçim ölçütü basit: bakım penceresi diskin boyutuna yetiyorsa yerleşik shrink daha az iş çıkarır. SLA (Service Level Agreement) saatlerce kesintiye izin vermiyorsa DMS yoluna bakın.

Önce dosyaları küçültün

Disk boşluğu iki katmanda birikir. SQL Server silinen verinin yerini .mdf ve .ndf dosyalarının içinde yeniden kullanıma ayırır, dosyanın kendisini küçültmez. DBCC SHRINKFILE bu boşluğu dosyadan diske geri verir.

Burada atlanmaması gereken bir ayrıntı var. SQL Server bir backup’ı restore ederken dosyaları backup’taki ayrılmış boyutla oluşturur. Yani kaynakta dosyalar şişkinse, hedefteki küçük disk restore sırasında yetmeyebilir. Hedef instance’ın disk boyutunu belirlemeden önce kaynaktaki dosya boyutlarına bakın.

Kaynaktaki sorgu her dosyanın ayrılmış ve kullanılan alanını gösteriyor. Cloud Monitoring tarafında database/disk/bytes_used ile database/disk/quota metriklerini yan yana koyun. Aradaki fark büyükse ve veritabanının yakında o alana geri dolması beklenmiyorsa küçültme mantıklı.

Hedef diski kullanılan alana eşitlemeyin. Transaction log’lar ve önümüzdeki büyüme için pay bırakın. Aksi halde automatic storage increase diski kısa sürede yeniden büyütür ve harcanan emek boşa gider.

Cutover öncesi taşınacaklar

DMS user database seviyesinde replike eder. Instance seviyesindeki her şeyi elle taşımanız gerekiyor. Runbook’a şunları ekleyin:

• Login’ler: sp_help_revlogin ile script alıp hedefte oluşturun.
• SQL Server Agent job’ları: SSMS’te script’leyin, adımlarda eski dosya yollarına bağımlılık var mı bakın.
• Linked server’lar: deploy etmeden önce hedefte cloudsql.linked_servers database flag’ini açın.
• Extended Events oturumları.
• TDE (Transparent Data Encryption) açıksa sertifikayı kaynaktan export edip hedefe import edin.
• Database flag’leri, Active Directory ve Entra ID ayarlarını kaynakla birebir eşleyin.
• PolyBase kullanıyorsanız database-scoped credential’lar için DMK’yi (Database Master Key) yeniden şifreleyin.

Bu listeyi replikasyon başlamadan hazırlamak cutover gününü rahatlatır. Eksik bir login ya da job ancak trafik yeni instance’a geçtiğinde ortaya çıkar.

Cutover sonrası orphaned user kontrolü

Restore edilen veritabanları kullanıcıları kaynaktaki SID (Security Identifier) değerleriyle taşır. Hedefte login’i başka yöntemle oluşturduysanız SID farklı olur ve kullanıcı login’siz kalır. Uygulama authentication hatası almaya başlar.

sp_help_revlogin SID’leri koruduğu için bu yolla taşınan login’lerde sorun beklenmez. Yine de cutover’dan hemen sonra her user database’de şu sorguyu çalıştırın:

SELECT dp.type_desc, dp.sid, dp.name AS user_name
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp ON dp.sid = sp.sid
WHERE sp.sid IS NULL AND dp.authentication_type_desc = 'INSTANCE';

Dönen her kullanıcı için ALTER USER [user_name] WITH LOGIN = [login_name]; ile eşlemeyi düzeltin. Sorguyu trafiği açmadan önce çalıştırırsanız hatayı kullanıcıdan önce görürsünüz.

Bu yolun bedeli

DMS yolu kesintiyi azaltır ama işi azaltmaz. Replikasyon süresince iki instance aynı anda çalışır, kısa bir süre iki kat fatura ödersiniz. Uygulama yeni bir instance’a bağlanacağı için connection string, secret ve firewall kurallarını cutover planına önceden yazın.

Cutover adımları sabit: trafiği durdurun, son log’un uygulanmasını bekleyin, hedefi DMS’te promote edin, uygulamayı yeni instance’a yönlendirin. Eski instance’ı geri dönüş için bir süre ayakta tutup sonra silin. Disk tasarrufu ancak o silme işleminden sonra faturaya yansır.