Failover tatbikatı / planlı geçiş
Rol değişiminin türünü (planlı switchover, acil failover ya da prod'a dokunmadan tatbikat) belirleyip; her senaryoda doğru komut sırasını ve doğrulama adımlarını sunan karar ağacı. Amaç: planlıda veri kaybı olmadan, acilde en az kayıpla, tatbikatta ise hiç kesinti olmadan hazır olmak.
Ne yapmak istiyorsun?
Rol değişiminin bağlamını seç. Primary sağlıklıyken planlı bir geçiş mi yapıyorsun (bakım/taşıma), primary gerçekten öldü ve acil geçiş mi gerekiyor, yoksa üretime dokunmadan bir tatbikat/hazırlık doğrulaması mı yapıyorsun?
- Planlı switchover (primary sağlıklı)
- Acil failover (primary öldü)
- Tatbikat / hazırlık testi (prod'a dokunma)
Planlı geçiş — önce hazır mısın?
Planlı switchover'da amaç SIFIR veri kaybıdır. Bunun için geçişten önce replikanın primary'yi yakaladığından (lag ~0) ve sağlıklı olduğundan emin olmalısın. Aşağıdaki komutlarla lag'i kontrol et; lag sıfıra yakınsa geçiş adımlarına ilerle.
SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#; -- DG: SELECT name, value FROM v$dataguard_stats WHERE name LIKE '%lag%';- Lag sıfıra yakın, geçişe hazır
- Lag yüksek, önce senkronu bekle
Planlı switchover (veri kaybısız kontrollü geçiş)
Primary ve standby sağlıklı ve senkronken rolleri kontrollü şekilde değiştir. Sıra önemlidir: yazımları durdur, kalan değişikliklerin standby'a aktığından emin ol, sonra rolü devret ve uygulamayı yeni primary'ye yönlendir.
Acil geçiş — primary gerçekten öldü mü?
Zorla failover'a geçmeden önce primary'nin gerçekten erişilemez olduğunu doğrula ve split-brain riskini değerlendir. Primary aslında yaşıyorsa (ör. geçici ağ kesintisi) zorla geçiş iki ayrı yazılabilir kopyaya (split-brain) yol açar. Ayrıca en güncel standby'ı seçmek için lag'i karşılaştır.
-- primary'ye erişim dene: tnsping primary_db; ve standby'da: SELECT thread#, MAX(sequence#) FROM v$archived_log GROUP BY thread#;- Evet, primary öldü — zorla geç
- Emin değilim / primary geri gelebilir
Acil failover (primary öldü, veri kaybı riskiyle geçiş)
Primary erişilemez ve geri gelmesini bekleyemiyorsun. Standby'ı zorla terfi ettirmen gerekir; asenkron replikasyonda son işlemlerin bir kısmı kaybolabilir. Önceliğin hizmeti geri getirmek, sonra kayıp penceresini tespit ve eski primary'yi güvenle geri almaktır.
Tatbikat / hazırlık testi (üretime dokunmadan doğrula)
Gerçek bir geçiş yapmadan, failover'a hazır olduğunu kanıtla. Replikaların sağlığını, lag'in kabul edilebilir olduğunu ve uygulamanın yönlendirilebildiğini prod'u etkilemeden doğrula. İstersen izole bir kopyada gerçek switchover'ı prova et.