Selamlar,
Çalıştığımız bir şirkette ilginç bir gereklilik hasıl oldu, sizlere de bahsedeyim.
Ortam büyük ve dinamik. En kritik veritabanları 6TB'a yakın bir boyutta. İş ve haliyle veritabanı beklenmedik şekilde büyümüş. Müşteri sayısı, gelen iş ve iş yoğunluğu çok kısa zamanda, çok fazla artmış. Böyle olunca bazı noktalarda hazırlıksız yakalanılmış. Yeni Storage alımında geç kalınmış.
Gelinen noktada elde bir üretim SQL Server sunucusu, bir de ikincil bir SQL Server sunucusu var; üretim sunucusundan ikincil sunucuya Database Mirroring yapılıyor. Yani birincil sunucuda (üretim sunucusu) gerçekleşen tüm işlemler gerçek zamanlıya yakın olarak ikincil sunucuya aktarılıyor. Fakat varolan kullanılabilecek Storage alanı o kadar az ki, örneğin birincil sunucuda bir tablo silinse ve geri getirilmek istense bu yapılamaz; çünkü elde yedek olduğu halde bunu Restore edebilecek müsait disk alanı yok.
Böyle bir senaryo için, en azından kişilerin, misal yazılımcıların (her yazımda size sataşmazsam olmuyor) yapabileceği olası bir hatalı silme veya güncelleme senaryosunda ilgili kayıtların eski versiyonlarına ulaşabilmeleri için bu arkadaşlara gecikmeli olarak işletilen bir Log Shipping uygulamasını tavsiye ettim. Database Mirroring'in ve Log Shipping'in nasıl çalıştığını ayrıntısıyla anlattım. Yeni Storage siparişi verildi; fakat en azından Storage gelip kullanılabilir oluncaya kadar ve hatta sonrasında da böyle sıkıntılar yaşanırsa hızlı aksiyon alınabilmesi ve zarar gören verinin ılık yedeklerden geri getirilebilmesi için Log Shipping işlerini görecektir.
Geçenlerde bu geçişi yaptık, hem de o en büyük veritabanını tekrar Restore etmeye gerek kalmadan. Çünkü anlayacağınız üzere zaten bu veritabanı Database Mirroring sayesinde ikincil sunucuda Restoring durumdaydı. Varolan Transaction Log yedekleme işlemlerini sonlandırıp yeni Log Shipping yapılandırmasını uyguladıktan sonra beklendiği gibi tıkır tıkır çalıştı. Tabii ki öncesinde gerekti tüm testleri yaptım. Her ne kadar yeni Storage'tan gelecek diskler devreye girene kadar Restore yapamayacak olsalar da, gecikmeli çalışan Log Shipping'ler sayesinde şimdi kendilerini daha güvende hissediyorlar.
Umarım tüm IT direktörleri ve / veya sistemci arkadaşlarım gerekli kapasite planlama işlerini aksatmadan yapar ve tabii ki yönetimden bütçe kopartabilir ve bu öyle sıkıntılar yaşamaz, gerçekten zor bir durum.
Sevgiler,
Ekrem Önsoy
28 Ocak 2016 Perşembe
22 Ocak 2016 Cuma
Gereği kadar yetki vermek...
Merhabalar,
Bugün, çalıştığım bir firmaya hizmet veren başka bir firmadaki bir arkadaştan şöyle bir e-posta aldım:
"Ekrem Bey Merhaba,
SQL bağlantısı için izin istiyoruz. Bir de dün açılan X_user yetkisi yeterli olmadı sanırım. X veritabanı için mi sysadmin hakkıyla bağlantı izni rica ediyoruz."
Kendi içimde verdiğim ilk ilkel tepkiyi pas geçiyorum, medeni tepkimin yansıması aşağıdaki gibi oldu:
"Merhabalar,
…
"sysadmin" yetkisi yapacağınız işin boyutunu çok aşan bir yetki ve bu yetkiyi size tabii ki veremeyiz. Dün arkadaşınıza verdiğim yetkiyi verdim yine X_user'a, işlemlerinizi kendi kullanıcınız olan bu kullanıcıyla yapabilirsiniz. Eğer bir yetki sorunuyla karşılaşırsanız bana danışın lütfen."
"Ekrem Bey,
Büyük bir ihtimalle dün X beye verdiğiniz yetki ile işlemleri yapamadığı için sorun oldu. Aşağıda sizin sunucuya bağlanıp tablonun dizaynını açtığımdaki görüntü ve hata mesajı var (Görüldüğü gibi kolonlar yok)."
Yukarıdaki e-postayı gönderen arkadaş aşağıdaki ekran görüntüsünü eklemiş:
Cevabım şöyle oldu:
"Designer için db_owner yetkisi gerekli, sizde bu yetki yok, ama yeni alan eklemeniz için gerekli yetkiler var. Bu işlemler Designer kullanarak yapılmamalı, çok tehlikeli. Misal Designer, yerli yersiz bazı işlemler için tüm tabloyu silip sıfırdan oluşturma yöntemini uyguluyor.
5 dakika sonrasında aynı arkadaşlardan gelen e-posta şöyle:
"Tamamdır Ben düzeltmeleri yapabildim Ekrem Bey. işim bitti. Bilginize."
Diyeceğim o ki arkadaşlar, sevgili yazılımcı arkadaşlarımız veritabanı yöneticilerini hep az yetki vermekle suçlar, yokuş yapmakla suçlar (yıllar oldu, beni Denizbank'ta hala "Yokuş Ekrem" diye ananlar varmış, geliyor kulağıma ha!); ama çoğu zaman aslında verilen yetkiler yeterlidir. Sırf birileri yetki istiyor diye hemen vermeyin onlara istedikleri yetkiyi. Talebi sorgulayın, her şeyi sorgulayın (biraz felsefe).
Fazla yetki sahibi olmak, büyük sorumluluk, çoğu zaman yazılımcılar ilk etapta bunun yükünü anlayamıyorlar. Ancak ne zaman bir veritabanını, tabloyu vs siliyorlar veya yanlış işler yapıyorlar, o zaman anlıyorlar fazla yetkinin sıkıntısını. Günlük kullanımlık aracınızın 1000 beygirlik olması gibidir "sysadmin" yetkisiyle üretim ortamında çalışmak. Bunun tehlikelerini lütfen yeri geldiğinde yazılımcılarınıza anlatın.
Ekrem Önsoy
Bugün, çalıştığım bir firmaya hizmet veren başka bir firmadaki bir arkadaştan şöyle bir e-posta aldım:
"Ekrem Bey Merhaba,
SQL bağlantısı için izin istiyoruz. Bir de dün açılan X_user yetkisi yeterli olmadı sanırım. X veritabanı için mi sysadmin hakkıyla bağlantı izni rica ediyoruz."
Kendi içimde verdiğim ilk ilkel tepkiyi pas geçiyorum, medeni tepkimin yansıması aşağıdaki gibi oldu:
"Merhabalar,
…
"sysadmin" yetkisi yapacağınız işin boyutunu çok aşan bir yetki ve bu yetkiyi size tabii ki veremeyiz. Dün arkadaşınıza verdiğim yetkiyi verdim yine X_user'a, işlemlerinizi kendi kullanıcınız olan bu kullanıcıyla yapabilirsiniz. Eğer bir yetki sorunuyla karşılaşırsanız bana danışın lütfen."
Ardından yine aynı firmada çalışan, ama başka bir arkadaştan şöyle bir e-posta geldi:
Büyük bir ihtimalle dün X beye verdiğiniz yetki ile işlemleri yapamadığı için sorun oldu. Aşağıda sizin sunucuya bağlanıp tablonun dizaynını açtığımdaki görüntü ve hata mesajı var (Görüldüğü gibi kolonlar yok)."
Yukarıdaki e-postayı gönderen arkadaş aşağıdaki ekran görüntüsünü eklemiş:
 |
| Designer |
"Designer için db_owner yetkisi gerekli, sizde bu yetki yok, ama yeni alan eklemeniz için gerekli yetkiler var. Bu işlemler Designer kullanarak yapılmamalı, çok tehlikeli. Misal Designer, yerli yersiz bazı işlemler için tüm tabloyu silip sıfırdan oluşturma yöntemini uyguluyor.
Bunun yerine yapacağınız işlemleri kod ile yapmalısınız.
ALTER TABLE ... ADD ... gibi "
5 dakika sonrasında aynı arkadaşlardan gelen e-posta şöyle:
"Tamamdır Ben düzeltmeleri yapabildim Ekrem Bey. işim bitti. Bilginize."
Diyeceğim o ki arkadaşlar, sevgili yazılımcı arkadaşlarımız veritabanı yöneticilerini hep az yetki vermekle suçlar, yokuş yapmakla suçlar (yıllar oldu, beni Denizbank'ta hala "Yokuş Ekrem" diye ananlar varmış, geliyor kulağıma ha!); ama çoğu zaman aslında verilen yetkiler yeterlidir. Sırf birileri yetki istiyor diye hemen vermeyin onlara istedikleri yetkiyi. Talebi sorgulayın, her şeyi sorgulayın (biraz felsefe).
Fazla yetki sahibi olmak, büyük sorumluluk, çoğu zaman yazılımcılar ilk etapta bunun yükünü anlayamıyorlar. Ancak ne zaman bir veritabanını, tabloyu vs siliyorlar veya yanlış işler yapıyorlar, o zaman anlıyorlar fazla yetkinin sıkıntısını. Günlük kullanımlık aracınızın 1000 beygirlik olması gibidir "sysadmin" yetkisiyle üretim ortamında çalışmak. Bunun tehlikelerini lütfen yeri geldiğinde yazılımcılarınıza anlatın.
Ekrem Önsoy
6 Ocak 2016 Çarşamba
Ansızın AlwaysOn AG'deki bir Replica gitti...
Selam!
Dün akşam, bir müşterimdeki bir AlwaysOn Availability Group yapılandırmasındaki Replica'lardan biriyle ilgili hata mesajları gelmeye başladı telefonuma. Hata mesajları, replikasyonun gecikmesi ve ilgili Replica'nın çalışmaması ile ilgiliydi. Müsait olunca sunucuya bağlanıp AlwaysOn AG Dashboard'unu ve ilgili logları incelemeye başladım ve hata mesajlarının geldiği Replica'nın NOT SYNCHRONIZING durumunda olduğunu gördüm. Kırmızı çarpılı uyarı simgeleri gözlerinizin önüne geliyordur sanırım…
AlwaysOn_health Extended Event dosyasında şöyle bir kayıt gördüm:
A connection timeout has occurred on a previously established connection to availability replica '' with id [XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.
Daha sonra sorunun yaşandığı SQL Server Instance'ına bağlanmaya çalıştım, RDP yapamıyordum (nedenini sonra anlatacağım); fakat SSMS ile bağlanabiliyor ve TELNET ile servise erişebiliyordum. Yani SQL Server Instance servisi ayaktaydı. SQL Server Instance'ına bağlandım, Error Log'u incelemeye başladım. Dha sonra sorunun oluştuğu ilk anda yine yukarıdaki hata mesajını gördüm ve hemen onun ardından aşağıdakine benzer hatalar vardı:
AlwaysOn Availability Groups connection with primary database terminated for secondary database 'VERITABANI_ADI' on the availability replica with Replica ID: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}. This is an informational message only. No user action is required.
Fakat benim senaryomda can alıcı kısım (kafamda ampulün yandığı sahne), özellikle aşağıdaki hata mesajıydı:
Database Mirroring login attempt failed with error: 'Connection handshake failed. An OS call failed: (80090311) 0x80090311(No authority could be contacted for authentication.). State 67.'. [CLIENT: XX.X.X.XX]
Bu hata mesajını görünce aklıma bu ortamda takriben 15 gün önce yaşanmış olan kaza geldi. 15 gün önce yaşanan kaza, bu sıkıntının yaşandığı SQL Server Instance'ının Computer nesnesinin Active Directory'den yanlışlıkla silinmesi kazasıydı. Bu kaza, o anda bir soruna neden olmamıştı; fakat bu kaza hakkındaki bilgi bana geldiğinde, ilgili arkadaşlara "Belki şu anda bir soruna neden olmuyor, ama muhakkak bir gün patlar. Şimdilik Cache'ten vs idare ediyor olmalı (teknik olarak bu noktada tükendiğimi anladınız sanırım)" demiştim.
Sorunu çözmek için ilgili SQL Server Instance'ının bulunduğu bilgisayara yerel Windows hesabıyla bağlanıldı, Domain'den çıkartıldı ve tekrar eklendi. Bu işlemin akabinde AlwaysOn ile ilgili sorunun da, RDP yapamama sorununun da düzeldiğini gözlemledik.
Evet, belki Computer nesnesinin Active Directory'de yeniden oluşturulması için daha pratik bir yol vardı; fakat bunun incelenmesi için vakte ihtiyaç vardı ve bu konuda çalışması gereken, kazayı yapan arkadaştı, çünkü o anda tam olarak ne yaptığını o biliyordu. En azından onun yakından yönlendirmesi şarttı. Mesai saatlerinin dışında bir vakitti ve mesai saatlerinin içinde dahi olsa bu araştırmaya vakit ayırılabileceğini sanmıyorum, o yüzden böyle daha "pratik" bir yöntem kullanıldı, sonuç olarak da işe yaradı.
Sevgiler,
Ekrem Önsoy
Dün akşam, bir müşterimdeki bir AlwaysOn Availability Group yapılandırmasındaki Replica'lardan biriyle ilgili hata mesajları gelmeye başladı telefonuma. Hata mesajları, replikasyonun gecikmesi ve ilgili Replica'nın çalışmaması ile ilgiliydi. Müsait olunca sunucuya bağlanıp AlwaysOn AG Dashboard'unu ve ilgili logları incelemeye başladım ve hata mesajlarının geldiği Replica'nın NOT SYNCHRONIZING durumunda olduğunu gördüm. Kırmızı çarpılı uyarı simgeleri gözlerinizin önüne geliyordur sanırım…
AlwaysOn_health Extended Event dosyasında şöyle bir kayıt gördüm:
A connection timeout has occurred on a previously established connection to availability replica '
Daha sonra sorunun yaşandığı SQL Server Instance'ına bağlanmaya çalıştım, RDP yapamıyordum (nedenini sonra anlatacağım); fakat SSMS ile bağlanabiliyor ve TELNET ile servise erişebiliyordum. Yani SQL Server Instance servisi ayaktaydı. SQL Server Instance'ına bağlandım, Error Log'u incelemeye başladım. Dha sonra sorunun oluştuğu ilk anda yine yukarıdaki hata mesajını gördüm ve hemen onun ardından aşağıdakine benzer hatalar vardı:
AlwaysOn Availability Groups connection with primary database terminated for secondary database 'VERITABANI_ADI' on the availability replica with Replica ID: {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}. This is an informational message only. No user action is required.
Fakat benim senaryomda can alıcı kısım (kafamda ampulün yandığı sahne), özellikle aşağıdaki hata mesajıydı:
Database Mirroring login attempt failed with error: 'Connection handshake failed. An OS call failed: (80090311) 0x80090311(No authority could be contacted for authentication.). State 67.'. [CLIENT: XX.X.X.XX]
Bu hata mesajını görünce aklıma bu ortamda takriben 15 gün önce yaşanmış olan kaza geldi. 15 gün önce yaşanan kaza, bu sıkıntının yaşandığı SQL Server Instance'ının Computer nesnesinin Active Directory'den yanlışlıkla silinmesi kazasıydı. Bu kaza, o anda bir soruna neden olmamıştı; fakat bu kaza hakkındaki bilgi bana geldiğinde, ilgili arkadaşlara "Belki şu anda bir soruna neden olmuyor, ama muhakkak bir gün patlar. Şimdilik Cache'ten vs idare ediyor olmalı (teknik olarak bu noktada tükendiğimi anladınız sanırım)" demiştim.
Sorunu çözmek için ilgili SQL Server Instance'ının bulunduğu bilgisayara yerel Windows hesabıyla bağlanıldı, Domain'den çıkartıldı ve tekrar eklendi. Bu işlemin akabinde AlwaysOn ile ilgili sorunun da, RDP yapamama sorununun da düzeldiğini gözlemledik.
Evet, belki Computer nesnesinin Active Directory'de yeniden oluşturulması için daha pratik bir yol vardı; fakat bunun incelenmesi için vakte ihtiyaç vardı ve bu konuda çalışması gereken, kazayı yapan arkadaştı, çünkü o anda tam olarak ne yaptığını o biliyordu. En azından onun yakından yönlendirmesi şarttı. Mesai saatlerinin dışında bir vakitti ve mesai saatlerinin içinde dahi olsa bu araştırmaya vakit ayırılabileceğini sanmıyorum, o yüzden böyle daha "pratik" bir yöntem kullanıldı, sonuç olarak da işe yaradı.
Sevgiler,
Ekrem Önsoy
Kaydol:
Kayıtlar (Atom)