Kurulum ekranındaki veritabanı host alanına çoğu zaman düşünmeden localhost yazılır. Uygulama başka sunucuya taşındığında aynı değer başarısız olabilir. Bazen 127.0.0.1 kullanmak sonucu değiştirir; bu da iki ifadenin her bağlantı katmanında bütünüyle eş anlamlı olmadığını gösterir. Rastgele değer denemek yerine uygulamanın ve sağlayıcının desteklediği bağlantı bilgisini belirlemek gerekir.
Host değeri bağlantı yöntemini etkileyebilir
PHP MySQLi bağlantı belgesi, localhost için Unix soketinin, 127.0.0.1 için ise TCP/IP bağlantısının kullanılabildiğini açıklar. Bu açıklama ilgili PHP sürücüsünün bağlamındadır; her işletim sistemi ve her uygulamaya aynı şekilde genellenmemelidir. Hatanın bağlantı kurulmadan mı, kimlik doğrulamada mı çıktığını ayrıca kaydedin.
Web adresini veritabanı adresi sanmayın
www ile başlayan site adresi, e-posta sunucusu ve veritabanı sunucusu farklı görevlerdir. Kontrol panelinde verilen gerçek bağlantı ayrıntısını kullanın. DNS kavramları rehberi ad çözümleme mantığını anlatır; ancak DNS kaydı eklemek tek başına veritabanına erişim izni vermez. Gereken bilgiyi bilmiyorsanız yapılandırmayı tahminle değiştirmeyin.
Taşıma sonrasında iki veritabanına dikkat edin
Dosyaları yeni hesaba kopyalanmış bir site eski veritabanına bağlanmaya devam edebilir. Ana sayfa açıldığı için taşımanın tamamlandığı düşünülürken güncellemeler eski ortama yazılıyor olabilir. Taşıma planında dosya, veritabanı ve DNS geçişini ayrı kontrol maddeleri yapın. Sipariş verisi bulunan projelerde çift yönlü yazma riski oluşmadan yöneticinizle geçiş planını netleştirin.
Bağlantıyı değiştirmeden önce envanter çıkarın
Uygulama adı, mevcut host, veritabanı adı, bağlantı sürücüsü ve son çalışan zamanını güvenli bir notta toplayın. Parolayı bu envanterin herkesçe görülen bölümüne koymayın. Yönetim ekranının çalışması ile ziyaretçi ekranının çalışmasını ayrı deneyin. Kimlik hatası varsa hata kaydı incelemesi ile hangi adımın başarısız olduğunu ayırın.
Web hosting üzerinde uzak veritabanı erişimi gerekiyorsa bunun hizmet kapsamında desteklenip desteklenmediğini sorun. Sadece deneme yapmak için bütün kaynak adreslerine izin vermeyin. Düzeltmeden sonra kullanılan hedefi yazılı kayda geçirin ve geri dönüşte hangi ayarın kullanılacağını belirtin. Çalışan bir siteyi başka bir rehberdeki örneğe benzetmek için değiştirmek yerine, mevcut mimarinin doğruluğunu kanıtlamayı hedefleyin.
Yanlış hedefe yazmayı önleyecek kontrol soruları
Yeni bağlantı ayarını uygulamadan önce ekip içinde şu soruları cevaplayın: bu hedef üretim mi, test mi, hangi yedek ona ait ve son değişiklikleri kim doğrulayacak? Aynı isimli iki veritabanı bulunuyorsa yalnız ada bakarak seçim yapmayın. İşletme açısından önemli veriler için kontrollü bir doğrulama yöntemi belirleyin; test amacıyla gerçek sipariş oluşturmak zorunda değilsiniz. Eski hizmet kapatılacaksa bağlantının hâlâ ona gitmediğinden emin olun. Bir hedefin yanıt vermesi onun doğru hedef olduğunu kanıtlamaz. Başarıyı içerik ve uygulama davranışıyla birlikte kaydedin; hassas verilerin örnek ekran görüntüsüne yanlışlıkla girmediğini de inceleyin.
Sıkça Sorulan Sorular
localhost yerine alan adımı yazabilir miyim?
Bunu genel çözüm olarak yapmayın. Web alan adının işaret ettiği yer ile veritabanı hizmetinin konumu aynı olmak zorunda değildir; sağlayıcının bağlantı bilgisini kullanın.
127.0.0.1 kesin daha iyi mi?
Hayır. Fark bağlantı yöntemidir; performans veya uyumluluk garantisi değildir. Uygulamanız ve hizmetiniz için desteklenen değer belirleyicidir.
Uzak veritabanı için port açmak yeterli mi?
Hayır. Yetkilendirme, erişim sınırı ve güvenli taşıma gibi koşullar birlikte değerlendirilmelidir. İnternete geniş erişim açmayın.
Taşınan sitede eski host kalabilir mi?
Kalabilir, fakat bu bilinçli mimari karar olmalıdır. İki ortamın hangi veriyi kullandığını doğrulamadan eski hizmeti kapatmayın.