WordPress veritabanını Azure’a taşırken hedef olarak Azure SQL Database seçerseniz standart WordPress kurulumu bu veritabanına bağlanamaz. WordPress, MySQL veya MariaDB kullanır. Azure tarafında bu yazının konusu Azure Database for MySQL Flexible Server; uygulama dosyalarını taşıma işlemi ayrı bir iş.
Bu yazının ilk sürümündeki MySQL taşıma yaklaşımını güncel hizmete uyarlıyorum. Kaynak veritabanını hazırlayıp güvenli bağlantıyı kuracağız, ardından veri aktarımı ve geri dönüş planına bakacağız. Mevcut ekran görüntüleri eski kurulumdan kaldığı için değişen ürün adlarını ve menüleri ayrıca belirtiyorum.
Önce neyi taşıdığınızı belirleyin
Veritabanında yazılarınız, kullanıcılarınız ve WordPress ayarları bulunur. Tema dosyaları, eklentiler ve yüklediğiniz görseller ise web sunucusundadır. Yalnız MySQL’i taşıdığınızda wp-content klasörü yerinde kalır, ziyaretçiler aynı web sunucusuna gelmeye devam eder.
Bu ayrım maliyet hesabını da değiştirir. Web sunucusu başka bir sağlayıcıda, MySQL Azure’da çalışacaksa her dinamik sayfa isteği iki ortam arasındaki bağlantıyı kullanır. Veritabanının daha güçlü olması, uzak bağlantının gecikmesini kendiliğinden telafi etmez. Taşıma kararından önce uygulama sunucusundan hedef Azure bölgesine erişimi ölçün.
WordPress’in güncel gereksinimleri MySQL 8.0 veya üzerini, alternatif olarak MariaDB 10.11 veya üzerini öneriyor. Kaynağın bu alt sınırı karşılaması tek başına yeterli olmaz. Hedefte desteklenen sürümü, eklentilerin uyumluluğunu ve kullandığınız karakter setini de kontrol edin.
Eski Azure ekranından bugünkü hedefe
İlk yazıdaki aşağıdaki ekran, 2020 döneminin MySQL sunucusu oluşturma akışına ait. Yeni kurulumda Flexible Server kullanın; eski ekranın hizmet seçeneklerini veya kaynak ölçülerini bugünkü öneri gibi kopyalamayın.
Sunucu boyutunu seçerken mevcut veritabanı büyüklüğüne ve yoğun saatlerdeki sorgu yüküne bakın. Yedek saklama süresi, depolama büyümesi ve yüksek erişilebilirlik tercihi faturayı etkiler. Küçük bir blogla sipariş alan mağazanın kesinti toleransı aynı olmayacağı için, tek bir işlemci ve disk önerisi vermek doğru olmaz.
Eski Migration Guide ekranları farklı veritabanı motorları için araç seçimini gösteriyordu. WordPress’in MySQL veritabanını PostgreSQL veya SQL Server’a doğrudan aktarma izni olarak yorumlamayın.
Microsoft’un dump ve restore ile taşıma rehberi küçük ve orta büyüklükteki geçişler için uygulanabilir bir başlangıç. Büyük veritabanında veya kısa kesinti penceresinde yöntemi ayrıca değerlendirmek gerekir. Buradaki adımlar kesintisiz geçiş garantisi vermez.
Bağlantıyı veri aktarmadan doğrulayın
Kaynak hosting’in dış bağlantı izni ile Azure’un ağ erişimi ayrı ayarlardır. Önce aktarımı yapacağınız bilgisayarın kaynağa bağlanabildiğini doğrulayın. Aşağıdaki Workbench ekranı eski kurulumda bu kontrol için kullanılmıştı.
Azure hedefinde public erişim kullanıyorsanız güvenlik duvarını yalnız gerekli istemci adresleriyle sınırlandırın. Private erişimde ise web sunucusunun ilgili ağa ulaşması ve sunucu adını doğru çözmesi gerekir. Yönetici bilgisayarından başarılı bağlantı, WordPress sunucusunun da erişebildiğini kanıtlamaz.
Bu eski hedef bağlantı ekranındaki kullanıcı adı biçimini güncel Flexible Server’a aynen taşımayın. Sunucunun güncel bağlantı bilgilerini kullanın. Aşağıdaki IP ekleme ekranı da eski portala ait; bugünkü ayarı hedef sunucunun Networking bölümünden kontrol edin.
TLS doğrulamasını kapatarak bağlantı sorununu çözmeyin. Microsoft’un TLS bağlantı rehberindeki güncel sertifika zincirini kullanın. MySQL istemcisinde --ssl-mode=VERIFY_IDENTITY, sertifika doğrulamasına sunucu adı kontrolünü de ekler. Bağlantıda IP adresi yerine Azure’un verdiği tam sunucu adını kullanmanızın nedenlerinden biri bu.
Son kopyadan önce yazmayı durdurun
İlk aktarımı üretim geçişinden önce prova edin. Tablo motorlarını, dışa aktarma hatalarını ve hedefe yükleme süresini bu aşamada görün. Kaynak MariaDB ise MySQL ile sürüm numarası benzer diye uyumluluk varsaymayın; özellikle collation ve eklentilerin oluşturduğu tabloları inceleyin.
Son aktarımda WordPress’i bakım moduna alın, sipariş veya form kaydı gibi yazma işlemlerini durdurun. Zamanlanmış işler ve arka plan entegrasyonları da veri yazabilir. Ziyaretçiye bakım sayfası göstermek bu işlemleri tek başına durdurmaz.
MySQL istemcisinin mysqldump aracıyla örnek bir dışa aktarma komutu şöyle kurulabilir. Buradaki adlar örnektir, parolayı komuta yazmak yerine istemde girin. CA dosyası, bağlandığınız kaynak sunucunun sertifikasını doğrulayan güvenilir sertifika zincirini içermeli; Azure hedefinin CA dosyasını kaynak için otomatik olarak kullanmayın:
mysqldump --host=kaynak.example.com --user=aktarim --password --ssl-mode=VERIFY_IDENTITY --ssl-ca="C:\sertifikalar\kaynak-ca.pem" --single-transaction --no-tablespaces --set-gtid-purged=OFF --result-file=wordpress.sql wordpress
--single-transaction, InnoDB tablolarında tutarlı kopya almaya yardımcı olur. Aktarım sırasında tablo yapısını değiştirmeyin; farklı motorlar varsa aynı garantiyi varsaymayın. Bu seçenekler MySQL istemcisi içindir, MariaDB aracına kontrol etmeden uygulamayın.
Hedefte boş uygulama veritabanını hazırlayın ve dump dosyasını Workbench’in Data Import ekranından içeri alın. Sistem veritabanlarını veya eski sunucunun kullanıcı tablolarını topluca taşımayın. WordPress için yalnız kendi veritabanında gereken yetkilere sahip ayrı kullanıcı oluşturun.
Eski yazının aşağıdaki sihirbaz görüntüleri kaynak ve hedef ayrımını gösteriyor. Güncel dump/import yönteminde aynı sihirbazı açmanız gerekmiyor.
WordPress’i bağlayıp geri dönüşü açık tutun
wp-config.php içindeki DB_HOST, DB_NAME, DB_USER ve DB_PASSWORD değerlerini hedefe göre güncelleyin. Parolayı repoya koymayın. PHP bağlantısında TLS’in gerçekten kullanıldığını da doğrulayın; komut satırındaki güvenli bağlantı ayarı WordPress’e otomatik aktarılmaz.
WordPress/PHP sürümünüzün sertifika doğrulama davranışını prova ortamında kontrol edin. MYSQL_CLIENT_FLAGS için TLS seçmek, her ortamda sertifika zinciri ve sunucu adı doğrulamasının doğru kurulduğunu tek başına kanıtlamaz. Barındırma ortamınızın desteklediği bağlantı yapılandırmasını esas alın.
Yönetici girişi, yeni yazı kaydı, görsel yükleme ve kullandığınız form veya sipariş akışını deneyin. Türkçe karakterleri ve kalıcı bağlantıları kontrol edin. Yalnız ana sayfanın açılmasına bakarsanız önbellekteki içerik, veritabanı sorununu gizleyebilir.
Geri dönüş için eski bağlantı ayarlarını ve son yedeği saklayın. Hedefte yeni kayıt oluştuysa eski veritabanına doğrudan dönmek bu kayıtları kaybettirir; önce veri farkını kapatmanız gerekir. Taşımayı tamamlanmış saymadan bu kararı kimin vereceğini belirleyin.
Geçişten önce son kontrol
- Hedef motorun ve sürümün WordPress ile uyumunu doğrulayın.
- Son kopyada uygulamanın bütün yazma kaynaklarını durdurun.
- TLS bağlantısını web sunucusundan da sınayın.
- Yeni veriler oluştuğunda geri dönüşün nasıl yapılacağını yazın.
Ben bu geçişi, yedeğin hedefte açıldığını ve uygulamanın oraya yazabildiğini gördükten sonra tamamlanmış sayarım. Sorularınız olursa yorumlarda buluşalım.
