Taşıma için önemli noktalar

24 dakika

Şirket içinde çalışan bir iş sistemi, aynı ortamda çalışan diğer hizmetlerle birleştirilmiş bir mimariye sahip olabilir. Geçirmek istediğiniz sistemle kuruluşunuzun şu anda kullandığı diğer uygulamalar ve hizmetler arasındaki ilişkileri anlamak önemlidir.

Teknoloji başlangıç şirketinizde tedarikçi veritabanı, bileşenlerin her zaman stokta olduğundan ve üretim sürecinde kullanımları için tam zamanında ulaştığından emin olmak için kullanılır. Stok denetleyicileri, sevkiyatlar geldikçe bu veritabanını güncelleştirmek için mobil cihazları kullanır ve alıcılar stok düzeylerini izlemek ve sipariş için en iyi zamanı belirlemek için bir web sitesi kullanır. Yöneticiler, süreci izlemek ve verimliliği artırmak için bir dizi iş açısından kritik rapor kullanır. Bu kullanıcıların hiçbirinin Azure'a geçişten olumsuz etkilenmediğinden emin olmak istiyorsunuz.

Burada buluta sorunsuz bir veritabanı geçişi planlamayı ve yürütmeyi öğreneceksiniz.

Bağımlılıkları araştırma

Karmaşık bir sistemde, bir bileşen nadiren tamamen bağımsız çalışır. Bunun yerine, diğer işlemlere ve bileşenlere çağrı yapar. Örneğin veritabanları, kullanıcı hesaplarını barındıran dizin hizmetlerine bağlı olabilir. Bir veritabanını buluta taşıdığınızda bu dizin hizmetine erişebilir misiniz? Aksi takdirde, kullanıcılar nasıl oturum açar? Bunun gibi bir bağımlılığı gözden kaçırdığınızda, veritabanının toplam hatası olabilir.

Riskleri azaltmak için veritabanınızın aşağıdaki gibi hizmetlere bağlı olup olmadığını denetleyin:

Active Directory gibi dizin hizmetleri.
Güvenlik sorumlularının diğer depoları.
Diğer veritabanları.
Web API'leri veya diğer ağ hizmetleri.

Diğer bileşenlerin veritabanınıza bağlı olabileceğini de unutmayın. Bağımlı bileşenleri yeniden yapılandırmadan veritabanını taşırsanız sonuçları ne olur? Örneğin, bir ürün kataloğu veritabanını taşırsanız ve genel kullanıma yönelik web sitesi kullanıcılara hangi ürünleri sunacağını belirlemek için buna bağımlıysa, taşıma hizmette kesintiye neden olur mu?

Bu tür bileşenlerden herhangi birinin veritabanınıza bağlı olup olmadığını denetleyin:

Web siteleri ve web API'leri.
Mobil uygulamalar ve masaüstü yazılımları gibi istemci uygulamaları.
Diğer veritabanları.
Rapor.
Veri ambarları.

Bu denetimleri yapmak için her veritabanı ve sistem bileşeniyle ilgili paydaşlarla, yöneticilerle ve geliştiricilerle görüşün. Ardından, sistemlerin davranışını anladığınızdan emin değilseniz, davranışları gözlemlemek için ağ yakalamaları gibi testler çalıştırmayı göz önünde bulundurun.

Geri çekilmeye hazırlanma

Herhangi bir geçiş projesinde her zaman bir hataya hazırlıklı olmanız gerekir. Buluta veritabanı geçiş projesinde en kötü sonuç, yeni veritabanının kullanılamaz duruma gelmesi ve kullanıcıların işlerini yapamamalarıdır. Şirket içi özgün, değiştirilmemiş veritabanına geri dönmeyi planlayarak şirketinizin kârlılığı üzerinde büyük bir etkiye sahip olabilecek bu riski azaltmak yaygın bir durum.

Geri dönüş planı için şunları göz önünde bulundurun:

Başarısız geçişten etkilenmeyen bir veritabanına geri dönebileceğinizden nasıl emin olabilirsiniz? Örneğin, geçişe başlamadan hemen önce tam veritabanı yedeği almanız kesinlikle önerilir.
Geri dönmeniz gerekirse veritabanının çevrimdışı olması ne kadar süreyle kabul edilebilir?
Geri dönüş planı için ne kadar bütçeniz var? Örneğin, veritabanını ayrılmış bir geri dönüş sunucusuna çoğaltmayı göze alabilir misiniz? Öyleyse, geçişten hemen önce bu sunucuyu kapatabilirsiniz. Geri dönmek için bu sunucuyu önyüklersiniz. Yedeklemeden geri yüklemek zorunda kalmadan geçişten etkilenmeyen bir veritabanınız hemen olur.

Çevrimdışı ve çevrimiçi geçiş

Veritabanını geçirmek için en az iki seçeneğiniz vardır:

Dekont

Çevrimiçi seçenek şu anda Veri Geçiş Hizmeti'ndeki MySQL veritabanlarında kullanılamaz.

Sistemi durdurun, veritabanını aktarın, ardından yeni veritabanını kullanmak için sistemi yeniden yapılandırın ve yeniden başlatın. Bu bir çevrimdışı geçiştir.
Veritabanını yeni konumuna taşırken sistemi çalışır durumda tutun, geçiş devam ederken özgün veritabanında gerçekleştirilen işlemleri yeni veritabanına iletin ve ardından uygulamalarınızı yeni veritabanına bağlanacak şekilde değiştirin. Bu bir çevrimiçi geçiştir.

Kullanıcıların geçiş gerçekleşirken verileri değiştirememelerini sağlamak için çevrimdışı geçiş yapmak daha kolaydır. Ancak veritabanınız meşgulse veya kuruluşunuzun başarısı açısından kritikse bu mümkün olmayabilir.

Çevrimdışı geçişler

Veritabanınızın, normal iş saatlerinde tek bir saat diliminde çalışan analistlerden oluşan bir ekibi desteklediğini varsayalım. Ekip genellikle hafta sonları çalışmaz. Veritabanı genellikle Cuma günü 18:00 ile Pazar günü 09:00 arasında kullanılmaz.

Bu durumda, aşağıdaki adımları izleyerek hafta sonu çevrimdışı geçiş yapabilirsiniz:

Cuma akşamı tüm işlemler tamamlandıktan sonra veritabanını çevrimdışına alın.
Veritabanının tam yedeğini alın veya dışarı aktarın.
Şirket içi sunucuyu kapatın ve geri çekilmeniz gerekirse bu sunucuyu saklayın.
Veritabanını hedef bulut sistemine geri yükleyin.
Hedef sistemi çevrimiçine getirin.
İstemcileri bulut veritabanına bağlanacak şekilde yeniden yapılandırın.

Bu durumda, hizmette kesintinin kullanıcılar üzerinde çok az etkisi olduğu uzun bir süre olduğundan çevrimdışı geçiş mümkündür. Bu süre boyunca, hiçbir değişikliği kaçırmayabileceğinizi bilerek veritabanını tam olarak yedekleyebilir ve geri yükleyebilirsiniz.

Çevrimiçi geçişler

Şimdi satış uygulamasını destekleyen başka bir veritabanını düşünün. Satış personeli dünyanın dört bir yanında dağıtılır ve hafta sonları da çalışır. Düşük etkinlik dönemi yoktur, veritabanı her zaman meşgul olur ve veritabanını önemli bir süre çevrimdışına alırsanız, bu kullanıcıları etkiler. Satış etkinliği iş açısından kritik öneme sahiptir, bu nedenle hizmette kesinti olması kuruluşun alt çizgisini doğrudan etkiler.

Böyle durumlarda çevrimiçi geçiş yapmayı göz önünde bulundurun. Çevrimiçi geçişte kapalı kalma süresi, yeni veritabanına geçiş için gereken süreyle sınırlıdır. Çevrimiçi geçiş yürütmek için Azure Veri Geçiş Hizmeti gibi bir araç kullanın. Çevrimiçi geçişler, çevrimdışı geçişlerle aşağıdaki farklılıklara sahiptir:

Yedekleme veya dışarı aktarma işlemine başlamadan önce özgün veritabanını çevrimdışı taşımazsınız.
Geçiş işlemi devam ederken değişiklikler eski veritabanına uygulanır.
Geçiş aracı, geçiş öncesinde bu değişikliklerin yeni veritabanına kopyalanmasını sağlar. Bu genellikle eski veritabanını yeni veritabanına değişiklikleri çoğaltacak şekilde yeniden yapılandırarak elde edilir.

Uygulama geçişi

Veritabanını geçirdikten sonra, yeni sisteme nasıl (ve ne zaman) geçiş yapmalı ve uygulamaları yeni veritabanını kullanacak şekilde güncelleştirmelisiniz? Aşağıdakiler olabilir:

Uygulamaları tek tek yeni veritabanına taşıyın.
Kullanıcıların alt kümelerini taşıma.
Her iki yaklaşımın bir bileşimini benimseyin.

Amaç, bir şey ters giderse kolayca geri alınabilecek küçük aşamalarda uygulama geçişi gerçekleştirmenizdir. Veritabanı geçişi için çevrimdışı veya çevrimiçi bir yaklaşım izlemiş olmanızdan bağımsız olarak, özgün kaynakta çalışan bir yapılandırmaya sahip olmanız gerekir. Teoride, hızlı bir şekilde orijinal kaynağa geri dönebileceksiniz. Ancak veriler sürekli değişiyorsa, bu değişikliklerin nerede yapıldığını göz önünde bulundurmanız gerekir.

Çevrimdışı geçişte, kaynak ve hedefler birbirinden bağımsızdır. Kullanıcılar ve uygulamalar artık verilerin tutarlı bir görünümünü göremeyebilir. İşlem sisteminde bu durum kabul edilemez olabilir. Bu durumda, her iki sistem de canlı kalırken veritabanları arasında bir tür çift yönlü çoğaltma tutmanız gerekir. Alternatif olarak, bir uygulamanın amacı aylık veya haftalık raporlar oluşturmak, satış tahminleri oluşturmak veya diğer istatistiksel işlemleri gerçekleştirmekse, bu tutarlılık eksikliği o kadar endişe verici olmayabilir. Bu tür uygulamalar, güncel verilere bağımlı olmak yerine verilerin "uzun bir görünümünü" alır. Bu ikinci durumda işlem uygulamaları yeni veritabanını kullanırken raporlama uygulamaları daha yavaş taşınır.
Çevrimiçi geçişte, yeni veritabanı genellikle bir çoğaltma biçimiyle eski veritabanıyla eşitlenmiş olarak tutulur. Çoğaltma işlemi zaman uyumsuz olabileceğinden bir gecikme olabilir. Ancak, yeni veritabanındaki verilerde yapılan değişiklikler eskiye yayılmaz ve olası çakışmalara neden olur. Eski veritabanına karşı çalışan bir uygulama, yeni veritabanında değiştirilmiş olan verilerde çakışan bir değişiklik yapabilir. Çoğaltma, yeni veritabanındaki değişikliğin üzerine körü körüne yazılır ve bu da "kayıp güncelleştirme" ile sonuçlanır.

Test yaklaşımları

Veritabanı işletmenizde kritik bir rol oynuyorsa, bir hatanın sonuçları kapsamlı olabilir. Bunun olmayacağına olan güveninizi artırmak için, geçirilen veritabanına karşı performans testleri çalıştırarak kullanıcıların üzerine yerleştirebileceği yükle başa çıkabileceğinden ve hızlı yanıt verebileceğinden emin olun. Talebin normalden çok daha yüksek olduğu yoğun etkinlik dönemleri olabileceğini unutmayın. Geçirilen sisteminizin beklenen iş yükünü işlediğinden emin olmanız gerekir.

Kullanıcılara erişime izin vermeden önce her zaman yeni veritabanında bir tür regresyon testi gerçekleştirin. Bu testler, sistemin davranışının ve işlevselliğinin doğru olduğunu doğrular.

Ayrıca bir "bekletme testi" çalıştırmayı da düşünmelisiniz. Emme testi, sistemin bir bütün olarak basınç altında nasıl çalıştığını görmek için tasarlanmış bir yük testidir. Bir bekletme testi yeni veritabanının stresini oluşturur ve yüksek talep altında kararlı olup olmadığını belirler. Çekme testi, yüksek talep devam ettiğinde ne olduğunu görmek için önemli bir süre boyunca çalışır.

Yeni sistemin kararlı olduğunu kurduğunuzda, kullanıcıları geçirmeye başlayabilirsiniz. Ancak, kullanıcıların yeni sistemi kabul edilebilir bulacağına ilişkin ek güvenceye ihtiyacınız olabilir. Bu noktada "kanarya testlerini" göz önünde bulundurabilirsiniz. Kanarya testi, kullanıcıların küçük bir alt kümesini yeni sisteme şeffaf bir şekilde yönlendirir, ancak erişimlerinin farkında değildir. Bu, yeni sistemle ilgili sorunları veya sorunları bulmanıza olanak sağlayan bir kör test biçimidir. Bu kullanıcıların yanıtlarını izleyin ve gerekli ayarlamaları yapın.

Paralel sistemlerin bakımı

Eski şirket içi veritabanını yeni bulut veritabanıyla paralel olarak çalıştırmayı seçmenizin çeşitli nedenleri vardır:

Test dönemleri. Önceki konu başlığında gördüğünüz gibi, kişileri desteklemek için kullanmadan önce işlevselliğini, kararlılığını ve kapasitesini değerlendirmek için geçirilen veritabanına karşı kanarya testleri çalıştırmak iyi bir fikirdir. Şirket içi sistemin paralel olarak korunması, yeni sistemle ilgili sorunlar varsa kullanıcıları eski sisteme geri döndürmek için hızlı bir yol sağlar.
Aşamalı geçişler. Beklenmeyen hataların üretim üzerindeki etkisini azaltmanın bir yolu, önce az sayıda kullanıcıyı yeni sisteme taşımak ve sonuçları izlemektir. Tümü sorunsuz çalışıyorsa, yeni veritabanında güven kazandıkça diğer kullanıcı gruplarını taşıyabilirsiniz. Kullanıcıları bölüme göre, konuma veya role göre alfabetik olarak taşıyabilirsiniz. Bu kullanıcılar yeni veritabanına eklenene kadar bu kullanıcıları alfabetik olarak taşıyabilirsiniz.
Parçalı geçişler. Bir diğer yaklaşım da geçişi kullanıcıya göre değil iş yüküne göre segmentlere ayırmaktır. Örneğin, insan kaynaklarını destekleyen veritabanı tablolarını satışları destekleyenlerden önce geçirebilirsiniz.

Tüm bu durumlarda, eski şirket içi veritabanının yeni bulut veritabanıyla paralel olarak çalıştığı bir dönem vardır. Eski veritabanında yapılan değişikliklerin yeni veritabanına da uygulandığından ve ters yönde aktığından emin olmanız gerekir. Bu eşitleme için betik yazabilir veya Azure Veri Geçiş Hizmeti gibi bir araç kullanabilirsiniz.

Paralel veritabanlarını korumaya ve değişiklikleri eşitlemeye karar verirseniz kendinize şu soruları sorun:

Çakışma çözümü. Şirket içi bir satırda yapılan bir değişikliğin, buluttaki aynı satırda yapılan farklı bir değişikliğe benzer bir zamanda gerçekleşmesi olası mı? Bu, hangi değişikliğin saklanması gerektiğinin belirsiz olduğu bir çakışmaya neden olur. Bu tür çakışmaları nasıl çözersiniz?
Ağ trafiği. Değişiklikler veritabanları arasında eşitlenirken ne kadar ağ trafiği oluşturulacak? Bu trafik için yeterli ağ kapasiteniz var mı?
Gecikme süresi. Veritabanlarından birinde bir değişiklik olduğunda, bu değişiklik diğer veritabanına ulaşmadan önce hangi gecikme (varsa) kabul edilebilir? Örneğin, bir ürün kataloğunda, yeni ürünlerin tüm kullanıcılar tarafından görülebilmesi için bir güne kadar bekleyebilirsiniz. Ancak, veritabanı döviz kurları gibi kritik işlem bilgilerini içeriyorsa, bu veriler anlık değilse çok daha sık eşitlenmelidir.

Parçalı geçiş

Parçalı geçiş, tam bir sistemi iş yüklerine böldüğünüz ve bir kerede bir iş yükü geçirebileceğiniz yerdir.

Birden çok veritabanı

Karmaşık bir sistem, birkaç iş yükünü destekleyen birden çok veritabanı içerebilir. Örneğin, insan kaynakları StaffDB veritabanını kullanırken satış ekibinin hem ProductCatalogDB veritabanını hem de OrdersDB veritabanını sorgulayan mobil uygulamaları olabilir.

Elbette veritabanı sisteminin tamamını tek seferde buluta geçirmeyi seçebilirsiniz. Bu daha basit olabilir çünkü veritabanlarını hem şirket içinde hem de bulutta çalıştırmanız gerekmez. Geçiş sırasında bu veritabanlarının nasıl iletişim kuracaklarını düşünmeniz gerekmez. Ancak, başarısızlık riskleri daha yüksektir. Tek bir sorun hem insan kaynakları ekibini hem de satış ekibini etkileyebilir.

Bir kerede bir iş yükünü taşıdığınız bir parçalı geçiş gerçekleştirerek orta ve büyük veritabanı sistemleri için bu riskleri azaltmayı göz önünde bulundurun. Bu örnekte, bir hatayla ilgili sorunlar insan kaynakları ekibiyle sınırlı olacağından ve sipariş almanıza engel olmayacağından önce StaffDB veritabanını geçirmeyi düşünebilirsiniz. StaffDB geçişiyle ilgili tüm sorunları çözerek, diğer iş yükü geçişleri için geçerli olan dersleri öğreneceksiniz.

Ardından, Ürün Kataloğu iş yükünü buluta geçirmeyi düşünebilirsiniz. Bunu yaparsanız aşağıdakiler gibi soruları göz önünde bulundurun:

Kataloğa yeni eklenen ürünlerin sipariş edilebilir olduğundan nasıl emin olursunuz?
Şirket içinde kalan OrdersDB veritabanıyla herhangi bir veriyi eşitlemeniz gerekiyor mu?
Yeni ürünlerin ürün kataloğundan OrdersDB veritabanına ulaşması için hangi gecikme süresi kabul edilebilir?

Tek veritabanı parçalı geçişleri

Tüm iş yüklerini destekleyen tek bir veritabanınız olsa bile, parçalı geçişi göz önünde bulundurabilirsiniz. Örneğin, veritabanını aşağıdaki gibi parçalara bölebilirsiniz:

İk işlemlerini destekleyen tablolar.
Satışları destekleyen tablolar.
Çözümleme ve raporlamayı destekleyen tablolar.

İlk olarak İk operasyon tablolarını geçirirseniz, ortaya çıkan herhangi bir sorun yalnızca İk personelini etkiler. Satış ve veri analistleri eski veritabanında kesintisiz olarak çalışmaya devam eder.

Parçalı geçiş gerçekleştirmeden önce veritabanlarını ve uygulamalar tarafından nasıl kullanıldıklarını tam olarak anlamanız gerekir. Örneğin, veritabanınızdaki bazı tablolar hem satış hem de raporlamayı destekleyebileceğinden. Başka bir deyişle iş yüklerini temiz bir şekilde bölemezsiniz. Tüm iş yükleri geçirilene kadar bu tabloları şirket içi ve bulut veritabanları arasında eşitlemeniz gerekir.

Güvenlik sorunları

Veritabanlarınız ürün ayrıntıları, kişisel personel bilgileri ve ödeme ayrıntıları gibi hassas veriler içerebilir; bu nedenle güvenlik her zaman yüksek önceliklidir. Geçiş sırasında ve yeni veritabanında bu verilerin nasıl koruneceğine karar vermeniz gerekir.

Güvenlik duvarı koruması

İnternet'e bağlı bir uygulamada veritabanı sunucuları genellikle en az iki güvenlik duvarı tarafından korunur. örneğin, bu sunucular web sitelerini veya web API'lerini barındırıyorsa, ilk güvenlik duvarı interneti ön uç sunucularından ayırır. Dış güvenlik duvarında yalnızca TCP bağlantı noktası 80 açık olmalıdır, ancak bu bağlantı noktası engellenen adresler dışında tüm kaynak IP adresleri için açık olmalıdır.

İkinci güvenlik duvarı, ön uç sunucuları veritabanı sunucularından ayırır. Veritabanı hizmetinin dış dünya tarafından bilinmeyen özel bir bağlantı noktası numarasında yayımlanması önerilir. İkinci güvenlik duvarında bu bağlantı noktası numarasını yalnızca ön uç sunucularının IP adresleri için açın. Bu düzenleme, kötü amaçlı bir İnternet kullanıcısından veritabanı sunucularına doğrudan iletişim kurmasını engeller.

Veritabanı sunucularını Azure sanal makinelerine geçirmeyi planlıyorsanız, güvenlik duvarı kurallarını çoğaltmak için Ağ Güvenlik Grupları (NSG) içeren bir sanal ağ kullanın. MySQL için Azure Veritabanı, MariaDB için Azure Veritabanı veya PostgreSQL için Azure Veritabanı kullanıyorsanız, Bağlan ion kullanarak veritabanını korumak için güvenlik duvarı kuralları oluşturabilirsiniz azure portalında sunucunun güvenlik sayfası.

Kimlik doğrulaması ve yetkilendirme

Çoğu veritabanında, kimlerin hangi verilere erişip hangi verileri değiştirdiği üzerinde yakından denetim sahibi olmanız gerekir. Bu denetim, kullanıcıların veritabanına bağlandığında olumlu bir şekilde tanımlanmasını gerektirir. Bu işleme kimlik doğrulaması adı verilir ve genellikle kullanıcı adı ve parola ile gerçekleştirilir. MySQL, MariaDB ve PostgreSQL gibi veritabanı sistemleri kendi kimlik doğrulama mekanizmalarını sağlar. Sistemlerinizi buluta geçirirken kullanıcıların kimliğini güvenli bir şekilde doğrulamaya devam ettiğinizden emin olmanız gerekir.

Dekont

MySQL için Azure Veritabanı, MariaDB için Azure Veritabanı ve PostgreSQL için Azure Veritabanı hizmetleri, geleneksel MySQL, MariaDB ve PostgreSQL kimlik doğrulamasına öykünmektedir.

Kullanıcının kim olduğunu bildiğinizde, işinin parçası olan görevleri tamamlamak için bu kullanıcıya izinler atamanız gerekir. Bu işleme yetkilendirme adı verilir.

Veritabanı geçiş projesi için kullanıcıların bulut veritabanında doğru yetkilendirildiğinden emin olmanız gerekir:

Kullanıcı hesaplarının şirket içi sistemde nerede depolandığını öğrenin. MySQL'de kullanıcı hesapları genellikle veritabanının usermysql tablosunda depolanır, ancak örneğin Active Directory'de depolanan kullanıcı hesaplarıyla tümleştirmek mümkündür.
Tüm kullanıcı hesaplarının listesini alın. Örneğin, MySQL'de şu komutu kullanabilirsiniz:
```
SELECT host, user FROM mysql.user;
```
Her kullanıcı hesabı için veritabanına hangi erişime sahip olduklarını öğrenin. Örneğin MySQL'de kullanıcı hesabı için dbadmin@on-premises-host şu komutu kullanabilirsiniz:
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
Bulut veritabanında her kullanıcı hesabını yeniden oluşturun. Örneğin, MySQL'de yeni bir hesap oluşturmak için şu komutu kullanabilirsiniz:
```
CREATE USER 'dbadmin'@'cloud-host'
```
Her kullanıcı hesabını bulut veritabanında doğru erişim düzeyine yetki verin. Örneğin, MySQL'de bir kullanıcının tam veritabanına erişmesine izin vermek için şu komutu kullanabilirsiniz:
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

Şifreleme

Veriler ağ üzerinden gönderildikçe, "ortadaki adam" saldırısı tarafından kesilebilir. Bunu önlemek için hem MySQL için Azure Veritabanı, MariaDB için Azure Veritabanı hem de PostgreSQL için Azure Veritabanı, iletişimleri şifrelemek için Güvenli Yuva Katmanı'na (SSL) destek sağlar. SSL varsayılan olarak zorunludur ve bu ayarı değiştirmemen kesinlikle önerilir.

SSL şifrelemesi kullanmak için istemci uygulamalarınızın bağlantı ayarlarını değiştirmeniz gerekebilir. Gerekli değişiklikleri (varsa) belirlemek için bu konuyu geliştiricilerinizle tartışın.

İzleme ve yönetim

Veritabanını geçirmeyi planlamanın bir parçası, veritabanı yöneticilerinin geçiş sonrasında görevlerini gerçekleştirmeye nasıl devam edeceklerini göz önünde bulundurmaktır.

İzleme

Şirket içi veritabanı yöneticileri, donanım performans sorunları veya ağ erişimi çekişmesi gibi sorunları tespit etmek için düzenli olarak izlemek için kullanılır. Üretkenlik etkilenmeden önce sorunları çözebileceklerini güvence altına almak için izler. Düzenli olarak izlenmeyen tüm veritabanlarının er ya da geç sorunlara neden olmasını bekleyebilirsiniz.

Bulut veritabanları için de tam olarak aynı yaklaşımı benimsemeniz gerekir. Herhangi bir donanım satın almadan, ayarlamadan ve yapılandırmadan kaynak ekleyebildiğiniz için Azure gibi bir PaaS sisteminde sorunları çözmek daha kolay olabilir. Ancak yine de geliştirme sorunlarını belirlemeniz gerektiğinden izleme, günlük görevleriniz arasında yüksek önceliklidir.

Veritabanlarını buluta geçirmeden önce, yöneticilerinizin şu anda hangi izleme araçlarını kullandığını öğrenin. Bu araçlar önerilen bulut tabanlı çözümünüzle uyumluysa, bunları yalnızca geçirilen veritabanlarına yeniden bağlamanız gerekebilir. Aksi takdirde, alternatifleri araştırmanız gerekir.

Azure'ın bir dizi performans izleme aracı içerdiğini ve çok çeşitli performans sayaçları ve günlük verileri topladığını unutmayın. Azure İzleyici'yi yapılandırarak bu verileri Azure portalında panoları ve grafikleri kullanarak görüntüleyebilirsiniz. Özel graflar, tablolar ve raporlar oluşturursunuz ve bunlar özellikle yöneticilerinizin ihtiyaçlarına göre tasarlanmıştır.

Yönetim

Veritabanı yöneticileriniz, şirket içi veritabanının şemasını ve içeriğini değiştirmek için tercih edilen araçları kullanır. Geçişten sonra aynı araçları kullanıyorlarsa uzmanlıklarından yararlanmaya devam edebilirsiniz. Mevcut araç kümesinin önerilen bulutta barındırılan veritabanıyla uyumlu olup olmadığını değerlendirerek başlayın. Birçok araç, SQL gibi yaygın olarak benimsenen standartları temel aldıkları için uyumlu olacaktır, ancak uyumluluğun doğrulanması önemlidir. Geçiş sonrasında geçerli yönetim araçları çalışmazsa, yöneticilerinizle birlikte alternatifleri belirlemeyi deneyin.

Azure, MySQL, MariaDB ve PostgreSQL veritabanlarını yönetmek için kullanabileceğiniz çeşitli araçlar içerir:

Azure portalı. Bu web sitesi, veritabanlarını ve Azure bulutunda oluşturabileceğiniz diğer tüm kaynakları yapılandırmak, izlemek ve yönetmek için kullanabileceğiniz güçlü özelliklere sahiptir.
Azure PowerShell. Bu, çok sayıda komut içeren bir betik yürütme ortamı ve dilidir. Karmaşık veritabanı yönetim görevlerini otomatikleştirmek için Windows ve Linux ortamlarında kullanılabilen PowerShell'i kullanın.
Azure CLI. Bu, Azure'a bir komut satırı arabirimidir. Azure'daki hizmetleri ve kaynakları yönetmek için bunu kullanın. CLI'yı Windows ve Linux kabuk ortamlarından ve Bash betiklerinin içinden kullanabilirsiniz.

Devam et