Upgrade ve Migration Stratejileri | Ücretsiz Elasticsearch: Sıfırdan Uzmanlığa Kursu

Giriş — Uçuş Sırasında Motor Değiştirmek

Bir uçağın motorunu uçuş sırasında değiştirmek — Elasticsearch upgrade'i tam olarak buna benziyor. Yolcular (kullanıcılar) hâlâ uçuyor, kargo (veri) hâlâ taşınıyor, ama motorları (cluster versiyonu) değiştirmen lazım. Bir hata yaparsan, düşersin. Plan yaparsan, yolcular farkına bile varmadan yeni motorla uçmaya devam eder.

Elasticsearch major version upgrade'leri (5.x → 6.x → 7.x → 8.x), breaking change'ler ve uyumsuzluklar barındırır. Bu derste rolling upgrade'den full cluster restart'a, reindex'ten snapshot migration'a, tüm yolları — adım adım, hata tuzaklarıyla birlikte — göreceğiz.

1. Upgrade Stratejileri — Hangisini Seçmeli?

Üç Ana Strateji

Strateji	Downtime	Risk	Kullanım
Rolling Upgrade	Yok	Düşük	Minor + major (N → N+1)
Full Cluster Restart	Var	Orta	Major jump (atlama) durumlarında
Reindex from Remote	Yok	Düşük	Farklı cluster'a migration

Hangi Versiyondan Hangisine?

5.x → 6.x → 7.x → 8.x  (her seferinde N+1)
     ↓           ↓
    Direct upgrade yok!
    5.x → 8.x YAPAMAZSINIZ!
    
Doğru yol: 5.x → 6.x → 7.x → 8.x (3 ayrı upgrade)
Veya: 5.x → yeni 8.x cluster'a reindex from remote

Index Compatibility Matrix

Kritik kural: Elasticsearch N.x versiyonu, (N-1).x versiyonunda oluşturulmuş index'leri okuyabilir. Daha eski index'leri OKUYAMAZ.

ES Versiyonu	Okuyabildiği Index Versiyonları
6.x	6.x ve 5.x'te oluşturulan index'ler
7.x	7.x ve 6.x'te oluşturulan index'ler
8.x	8.x ve 7.x'te oluşturulan index'ler

Bu ne demek? ES 7.x'e upgrade yapacaksanız ve cluster'da 5.x'te oluşturulmuş index'ler varsa, önce bu index'leri 6.x'te reindex etmelisiniz.

# Index'lerin hangi versiyonda oluşturulduğunu kontrol et
GET _cat/indices?v&h=index,creation.date.string,version.created.string

# Veya settings'ten:
GET my-old-index/_settings?filter_path=*.settings.index.version.created

2. Rolling Upgrade — Adım Adım

Ön Hazırlık

// 1. Deprecation API ile uyumsuzlukları kontrol et (7.x+)
GET _migration/deprecations

// Çıktı:
// {
//   "cluster_settings": [...],
//   "node_settings": [...],
//   "index_settings": {
//     "old-index": [
//       {
//         "level": "critical",
//         "message": "Index created before 7.0",
//         "url": "https://ela.st/...",
//         "details": "This index was created with version 6.8.0..."
//       }
//     ]
//   }
// }

// 2. Upgrade Assistant (Kibana) — görsel kontrol
// Kibana → Management → Upgrade Assistant
// Tüm deprecation'ları ve gerekli aksiyonları listeler

// 3. Snapshot al — GERİ DÖNÜŞ NOKTASI
PUT _snapshot/upgrade-backup/pre-upgrade-snapshot
{
  "indices": "*",
  "include_global_state": true
}

// Snapshot'ın tamamlandığını doğrula
GET _snapshot/upgrade-backup/pre-upgrade-snapshot/_status

Rolling Upgrade Adımları

ADIM 1: Shard allocation'ı devre dışı bırak
ADIM 2: Synced flush yap (7.x, 8.x'te otomatik)
ADIM 3: Bir node'u durdur
ADIM 4: Node'u yeni versiyonla başlat
ADIM 5: Node'un cluster'a katıldığını doğrula
ADIM 6: Shard allocation'ı tekrar aç
ADIM 7: Cluster'ın GREEN olmasını bekle
ADIM 8: Sonraki node için ADIM 1'e dön

Detaylı komutlar:

// ═══════════════════════════════════════
// ADIM 1: Shard allocation'ı kapat
// ═══════════════════════════════════════
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}

// ═══════════════════════════════════════
// ADIM 2: Synced flush (ES 7.x ve altı)
// ═══════════════════════════════════════
POST _flush/synced
// ES 8.x'te bu komut kaldırıldı — otomatik yapılıyor

// Normal flush (her versiyonda)
POST _flush

// ═══════════════════════════════════════
// ADIM 3: Node'u durdur
// ═══════════════════════════════════════
// Linux:
// sudo systemctl stop elasticsearch
// 
// Docker:
// docker stop es-node-1

// ═══════════════════════════════════════
// ADIM 4: Node'u güncelle ve başlat
// ═══════════════════════════════════════
// RPM:
// sudo rpm -U elasticsearch-8.12.0-x86_64.rpm
//
// DEB:
// sudo dpkg -i elasticsearch-8.12.0-amd64.deb
//
// Docker:
// docker run -d --name es-node-1 elasticsearch:8.12.0 ...
//
// sudo systemctl start elasticsearch

// ═══════════════════════════════════════
// ADIM 5: Node'un katıldığını doğrula
// ═══════════════════════════════════════
GET _cat/nodes?v&h=name,version,heap.percent,disk.percent

// ═══════════════════════════════════════
// ADIM 6: Shard allocation'ı tekrar aç
// ═══════════════════════════════════════
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}

// ═══════════════════════════════════════
// ADIM 7: GREEN olmasını bekle
// ═══════════════════════════════════════
GET _cluster/health?wait_for_status=green&timeout=5m

// Shard recovery durumunu izle
GET _cat/recovery?v&active_only=true

// ═══════════════════════════════════════
// ADIM 8: Sonraki node — ADIM 1'e dön
// ═══════════════════════════════════════

Rolling Upgrade Sırası

Sıra önemli! Her zaman şu sırada:

1. NON-master-eligible data node'lar (herhangi biri)
2. Diğer non-master-eligible data node'lar
3. Master-eligible node'lar (birer birer!)
   → Aktif master'ı EN SON yap
   → Master election sorun çıkarmasın diye

Neden bu sıra?
- Data node düşünce → shard'lar replica'dan servis edilir
- Master düşünce → yeni master seçimi olur
- Aktif master'ı son yaparsak, diğer master-eligible node'lar zaten yeni versiyonda — election sorunsuz olur

⚠️ Dikkat: Rolling upgrade sırasında cluster mixed version durumundadır. Bu sürede yeni versiyon özelliklerini kullanmayın — tüm node'lar upgrade olana kadar eski versiyon API'lerini kullanın.

3. Full Cluster Restart Upgrade

Ne Zaman Gerekli?

Major version atlama (5.x → 6.x gibi, ama bazen rolling da yeterli)
Uyumsuz plugin'ler var
Cluster state corruption
Çok küçük cluster (2-3 node) — rolling'in avantajı az

Adımlar

// 1. Snapshot al
PUT _snapshot/upgrade-repo/full-restart-snapshot
{
  "indices": "*",
  "include_global_state": true
}

// 2. Shard allocation'ı kapat
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}

// 3. Flush
POST _flush

// 4. TÜM node'ları durdur
// sudo systemctl stop elasticsearch (her node'da)

// 5. TÜM node'ları güncelle
// RPM/DEB/Docker image değiştir

// 6. TÜM node'ları başlat (master-eligible'lar önce)
// sudo systemctl start elasticsearch (her node'da)

// 7. Cluster'ın oluşmasını bekle
GET _cluster/health?wait_for_nodes=5&timeout=5m

// 8. Allocation'ı aç
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}

// 9. GREEN olmasını bekle
GET _cluster/health?wait_for_status=green&timeout=30m

Downtime süresi tahmini:

Node kapatma:       1-2 dakika/node
Güncelleme:         2-5 dakika/node
Node başlatma:      1-3 dakika/node
Cluster formation:  1-5 dakika
Recovery:           5-60 dakika (veri boyutuna göre)

5 node cluster, 1 TB veri:
≈ 20-30 dakika downtime

4. Reindex from Remote — Cluster Migration

Ne Zaman Kullanılır?

Farklı bir cluster'a migration
Major version atlama (5.x → 8.x direkt)
Cloud'a geçiş (on-prem → Elastic Cloud)
Cluster yeniden yapılandırma (shard stratejisi değişikliği)

Reindex from Remote Konfigürasyonu

# elasticsearch.yml (HEDEF cluster'da)
reindex.remote.whitelist: "old-cluster:9200, 192.168.1.10:9200"

// Hedef cluster'da yeni index oluştur (yeni mapping ile)
PUT new-my-index
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "title": { "type": "text" },
      "status": { "type": "keyword" },
      "created_at": { "type": "date" }
    }
  }
}

// Reindex from remote
POST _reindex
{
  "source": {
    "remote": {
      "host": "http://old-cluster:9200",
      "username": "elastic",
      "password": "changeme",
      "socket_timeout": "1m",
      "connect_timeout": "10s"
    },
    "index": "old-my-index",
    "query": {
      "match_all": {}
    }
  },
  "dest": {
    "index": "new-my-index"
  }
}

Büyük Veri Setleri için Reindex

// Sliced reindex — paralel çalışma
POST _reindex?slices=5&wait_for_completion=false
{
  "source": {
    "remote": {
      "host": "http://old-cluster:9200"
    },
    "index": "big-index",
    "size": 5000
  },
  "dest": {
    "index": "new-big-index"
  }
}

// Task durumunu izle
GET _tasks?detailed=true&actions=*reindex

// Belirli task'ı izle
GET _tasks/task_id_here

// Task'ı iptal et
POST _tasks/task_id_here/_cancel

Reindex ile Dönüşüm

// Reindex sırasında veri dönüşümü (script)
POST _reindex
{
  "source": {
    "remote": {
      "host": "http://old-cluster:9200"
    },
    "index": "old-users"
  },
  "dest": {
    "index": "new-users",
    "pipeline": "migration-pipeline"
  },
  "script": {
    "source": """
      // Field adını değiştir
      ctx._source.full_name = ctx._source.remove('name');
      // Yeni field ekle
      ctx._source.migrated_at = '2024-01-15T10:00:00Z';
      // Field sil
      ctx._source.remove('deprecated_field');
    """
  }
}

// Migration ingest pipeline
PUT _ingest/pipeline/migration-pipeline
{
  "processors": [
    {
      "rename": {
        "field": "old_field",
        "target_field": "new_field",
        "ignore_missing": true
      }
    },
    {
      "set": {
        "field": "schema_version",
        "value": 2
      }
    },
    {
      "remove": {
        "field": "deprecated_field",
        "ignore_missing": true
      }
    }
  ]
}

5. Snapshot/Restore ile Migration

Neden Snapshot/Restore?

Reindex from remote, veriyi ağ üzerinden doküman doküman kopyalar — yavaştır. Snapshot/restore, binary düzeyde kopyalar — çok daha hızlıdır.

Karşılaştırma (1 TB veri):
- Reindex from remote: 4-8 saat
- Snapshot/restore:     30-60 dakika

Adımlar

// ═══════════════════════════════════════
// KAYNAK CLUSTER'DA
// ═══════════════════════════════════════

// 1. Shared repository oluştur (S3, GCS, Azure Blob, NFS)
PUT _snapshot/migration-repo
{
  "type": "s3",
  "settings": {
    "bucket": "my-es-migration",
    "region": "eu-west-1",
    "base_path": "migration-2024"
  }
}

// 2. Snapshot al
PUT _snapshot/migration-repo/migration-snapshot
{
  "indices": "index-1,index-2,logs-*",
  "include_global_state": false,
  "metadata": {
    "taken_by": "migration-team",
    "reason": "v7-to-v8 migration"
  }
}

// 3. Snapshot'ın tamamlandığını doğrula
GET _snapshot/migration-repo/migration-snapshot

// ═══════════════════════════════════════
// HEDEF CLUSTER'DA
// ═══════════════════════════════════════

// 4. Aynı repository'yi hedef cluster'da tanımla
PUT _snapshot/migration-repo
{
  "type": "s3",
  "settings": {
    "bucket": "my-es-migration",
    "region": "eu-west-1",
    "base_path": "migration-2024",
    "readonly": true
  }
}

// 5. Snapshot'taki index'leri listele
GET _snapshot/migration-repo/migration-snapshot

// 6. Restore et
POST _snapshot/migration-repo/migration-snapshot/_restore
{
  "indices": "index-1,index-2",
  "ignore_unavailable": true,
  "include_global_state": false,
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1",
  "index_settings": {
    "index.number_of_replicas": 1
  },
  "ignore_index_settings": [
    "index.refresh_interval"
  ]
}

// 7. Restore durumunu izle
GET _cat/recovery?v&active_only=true

💡 İpucu: rename_pattern ve rename_replacement ile restore edilen index'lerin adını değiştirebilirsiniz. Mevcut index'lerle çakışmayı önlemek için kullanışlıdır. Karşılaştırma yapıp, doğrulandıktan sonra alias ile geçiş yapabilirsiniz.

6. Breaking Changes Checklist — Versiyon Bazlı

5.x → 6.x Breaking Changes

✅ Kontrol listesi:
□ Multiple mapping types kaldırıldı → Her index tek type
  (5.x: PUT index/type1, PUT index/type2 → 6.x: sadece _doc)
□ _all field varsayılan olarak kapalı
□ Index template'lerde include_type_name: true gerekebilir
□ String field type kaldırıldı → text veya keyword kullan
□ Completion suggester format değişti
□ Parent-child → join field type'a geçti
□ Internal versioning değişti → seq_no + primary_term kullan
□ Tribe node kaldırıldı → Cross-cluster search kullan
□ Shadow replicas kaldırıldı

6.x → 7.x Breaking Changes

✅ Kontrol listesi:
□ Default shard sayısı 5 → 1 oldu
  (Artık number_of_shards belirtmeniz gerekebilir!)
□ Mapping types tamamen kaldırıldı (_doc bile opsiyonel)
  (6.x: GET index/_doc/id → 7.x: GET index/_doc/id)
□ include_type_name varsayılanı false oldu
□ _default_ mapping kaldırıldı
□ Adaptive replica selection varsayılan oldu
□ Discovery seed_hosts → discovery.seed_hosts
□ cluster.initial_master_nodes gerekli (yeni cluster'da)
□ Security (X-Pack) free olarak dahil edildi
□ Java REST Client: RestHighLevelClient → deprecated (8.x'te)
□ binary logging format değişti
□ JVM: G1GC varsayılan oldu
□ Lucene 8 → BM25 skoring iyileştirmesi
□ Soft deletes varsayılan açık → peer recovery gelişti

7.x → 8.x Breaking Changes

✅ Kontrol listesi:
□ Security varsayılan AÇIK → TLS zorunlu
  (8.x'te auto-configuration ile gelir)
□ Java REST Client değişti:
  RestHighLevelClient → ElasticsearchClient (yeni Java client)
□ _type tamamen kaldırıldı
  (7.x: PUT index/_doc/id → 8.x: PUT index/_doc/id aynı)
□ Joda time → java.time formatı
  (date format pattern'ları değişebilir: epoch_millis, vb.)
□ Synced flush kaldırıldı → otomatik
□ node.max_local_storage_nodes kaldırıldı
□ Transport client tamamen kaldırıldı → REST client kullan
□ Frozen index API kaldırıldı → searchable snapshots kullan
□ emit_value() script değişikliği
□ text field'larda fielddata açık → keyword sub-field kullan
□ _source disabled index'lere runtime field uygulanamaz
□ System index'lere direct erişim kısıtlandı
□ SSL/TLS auto-configuration eklendi
□ Elastic Agent / Fleet entegrasyonu güçlendi
□ Kibana Saved Objects migration otomatik

Versiyon Kontrol Komutları

# Mevcut versiyon
GET /

# Node versiyonları (mixed cluster kontrolü)
GET _cat/nodes?v&h=name,version

# Index'lerin oluşturulma versiyonları
GET _cat/indices?v&h=index,version.created.string

# Deprecation log'ları (7.x+)
GET _migration/deprecations

# Uyumsuz index'leri bul (8.x'e geçmeden önce)
# 6.x veya altında oluşturulan index'ler 8.x'te AÇILMAZ!
GET _cat/indices?v&h=index,version.created.string&s=version.created.string:asc

7. Upgrade Öncesi Hazırlık Checklist

Kapsamlı Checklist

PRE-UPGRADE CHECKLIST:
═══════════════════════════════════════

BACKUP
□ Full snapshot alındı mı?
□ Snapshot başarılı mı? (GET _snapshot/repo/snap)
□ Restore testi yapıldı mı? (farklı cluster'da)
□ Cluster settings yedeklendi mi? (GET _cluster/settings)
□ Index templates yedeklendi mi? (GET _index_template/*)
□ ILM policies yedeklendi mi? (GET _ilm/policy/*)
□ Kibana saved objects export edildi mi?

UYUMLULUK
□ Deprecation API kontrol edildi mi?
□ Upgrade Assistant (Kibana) çalıştırıldı mı?
□ Uyumsuz index'ler reindex edildi mi?
□ Plugin'ler yeni versiyonla uyumlu mu?
□ Custom script'ler (Painless) kontrol edildi mi?
□ Ingest pipeline'lar kontrol edildi mi?
□ Java client versiyonu güncellendi mi?

CLUSTER SAĞLIĞI
□ Cluster GREEN mi? (YELLOW/RED ile upgrade yapmayın!)
□ UNASSIGNED shard var mı?
□ Pending tasks var mı? (GET _cluster/pending_tasks)
□ Recovery devam ediyor mu?

DONANIM
□ Disk alanı yeterli mi? (en az %20 boş)
□ Yeni versiyon paketleri indirildi mi?
□ Rollback planı var mı?

UYGULAMA
□ Uygulama ES client'ı uyumlu mu?
□ Query'ler yeni versiyonla test edildi mi?
□ Test ortamında upgrade test edildi mi?
□ Monitoring kurulu mu?

8. Canary Deployment

Canary Stratejisi

Tüm cluster'ı bir anda upgrade etmek yerine, önce bir kısmını upgrade edip test etmek:

Aşama 1: Test cluster'da upgrade
  └── Tüm query'leri test et
  └── Performance benchmark yap
  └── Regression yoksa devam

Aşama 2: Production — 1 data node upgrade
  └── İzle (24 saat)
  └── Hata yoksa devam

Aşama 3: Production — kalan data node'lar
  └── Birer birer, her birinde 1 saat izle

Aşama 4: Master node'lar
  └── Birer birer, master election'ı izle

Aşama 5: Kibana ve diğer komponentler
  └── Kibana versiyonu ES versiyonuyla eşleşmeli

Canary ile Rolling Upgrade Script

#!/bin/bash
# canary-upgrade.sh — Production rolling upgrade script

ES_HOST="localhost:9200"
NODES=("node-1" "node-2" "node-3" "node-4" "node-5")
CANARY_NODE="${NODES[0]}"  # İlk node canary

echo "=== Pre-flight checks ==="
HEALTH=$(curl -s "$ES_HOST/_cluster/health" | jq -r '.status')
if [ "$HEALTH" != "green" ]; then
  echo "ABORT: Cluster is $HEALTH, must be green!"
  exit 1
fi

echo "=== Taking snapshot ==="
curl -XPUT "$ES_HOST/_snapshot/upgrade-repo/pre-upgrade-$(date +%Y%m%d)" \
  -H 'Content-Type: application/json' \
  -d '{"indices":"*","include_global_state":true}'

echo "=== Waiting for snapshot ==="
# Snapshot tamamlanana kadar bekle...

echo "=== Upgrading canary: $CANARY_NODE ==="
# 1. Allocation kapat
curl -XPUT "$ES_HOST/_cluster/settings" \
  -H 'Content-Type: application/json' \
  -d '{"persistent":{"cluster.routing.allocation.enable":"primaries"}}'

# 2. Flush
curl -XPOST "$ES_HOST/_flush"

# 3. Node durdur (SSH ile)
ssh $CANARY_NODE "sudo systemctl stop elasticsearch"

# 4. Güncelle
ssh $CANARY_NODE "sudo rpm -U /tmp/elasticsearch-8.12.0-x86_64.rpm"

# 5. Başlat
ssh $CANARY_NODE "sudo systemctl start elasticsearch"

# 6. Bekle
sleep 60

# 7. Allocation aç
curl -XPUT "$ES_HOST/_cluster/settings" \
  -H 'Content-Type: application/json' \
  -d '{"persistent":{"cluster.routing.allocation.enable":null}}'

# 8. GREEN bekle
echo "Waiting for green..."
curl -s "$ES_HOST/_cluster/health?wait_for_status=green&timeout=10m"

echo "=== Canary upgraded! Monitor for 24h before continuing ==="

9. Rollback Planı

Upgrade Başarısız Olursa

Rolling Upgrade Rollback:
1. Güncellenen node'u durdur
2. Eski versiyon paketini kur
3. Node'u eski versiyonla başlat
4. Cluster'ın stabilize olmasını bekle

Full Cluster Restart Rollback:
1. Tüm node'ları durdur
2. Eski versiyon paketlerini kur
3. Tüm node'ları başlat
4. Snapshot'tan restore et (gerekirse)

Snapshot Rollback (son çare):
1. Yeni cluster'ı durdur
2. Data dizinlerini temizle
3. Eski versiyonu kur
4. Başlat
5. Snapshot'tan restore et

// Snapshot'tan full restore
POST _snapshot/upgrade-repo/pre-upgrade-20240115/_restore
{
  "indices": "*",
  "include_global_state": true
}

⚠️ Dikkat: Upgrade sonrası yeni versiyon index'e yazma yaptıysa (yeni doküman, mapping değişikliği), eski versiyona rollback yapılamaz — o index'ler eski versiyonda açılmaz. Bu yüzden upgrade öncesi snapshot kritiktir.

10. Kibana ve Beats Upgrade Sırası

Upgrade Sırası

1. Elasticsearch (önce)
2. Kibana (ES'ten sonra, ES versiyonuyla eşleşmeli)
3. Logstash (uyumlu, genellikle sorunsuz)
4. Beats (geriye uyumlu, en son)
5. Elastic Agent (Fleet üzerinden)

Kibana Upgrade

# Kibana versiyonu ES versiyonuyla eşleşmeli
# ES 8.12.0 → Kibana 8.12.0

# RPM
sudo rpm -U kibana-8.12.0-x86_64.rpm
sudo systemctl restart kibana

# Docker
docker pull docker.elastic.co/kibana/kibana:8.12.0
docker stop kibana
docker run ... docker.elastic.co/kibana/kibana:8.12.0

Kibana ilk açılışta "Saved Objects" migration yapabilir — bu birkaç dakika sürebilir. Tarayıcıda "Kibana is loading" mesajı görebilirsiniz, sabırlı olun.

Beats Upgrade

Beats geriye uyumludur (backward compatible). Eski Beats → yeni ES genellikle çalışır. Ama yeni özelliklerden faydalanmak için Beats'i de güncelleyin.

# Filebeat upgrade
sudo rpm -U filebeat-8.12.0-x86_64.rpm
sudo systemctl restart filebeat

# Veya Elastic Agent kullanıyorsanız:
# Fleet UI → Agent policies → Upgrade
# Merkezi yönetimle tüm agent'ları güncelleyebilirsiniz

11. Migration Best Practices

❌ Yapma

Snapshot almadan upgrade yapma — Geri dönüş yolun kapanır
Doğrudan 2+ major version atlama — 5.x → 8.x yapamazsın
YELLOW/RED cluster'da upgrade yapma — Önce cluster'ı düzelt
Test etmeden production'da upgrade yapma — Her zaman staging'de test et
Tüm node'ları aynı anda durdurma (rolling upgrade'de) — Birer birer yap
Mixed version cluster'da yeni feature kullanma — Tüm node'lar upgrade olana kadar bekle
Kibana'yı ES'ten önce upgrade etme — ES önce, Kibana sonra

✅ Yap

Deprecation API ve Upgrade Assistant kullan — Sorunları önceden bul
Uyumsuz index'leri önceden reindex et — 6.x'te oluşturulmuş index'ler 8.x'te açılmaz
Canary deployment yap — Önce 1 node upgrade et, 24 saat izle
Rollback planı hazırla — Her şey ters gidebilir
Monitoring'i sıkılaştır — Upgrade sırasında GC, thread pool, latency izle
Off-peak saatte yap — Gece veya düşük trafik saatlerinde
İletişim planı yap — Ekipleri bilgilendir, bakım penceresi aç

12. Sıfırdan Yeni Cluster'a Migration

Ne Zaman Sıfırdan Başlamalı?

3+ major version atlama (5.x → 8.x)
Cluster mimarisi tamamen değişecek (shard stratejisi, tier yapısı)
On-prem'den cloud'a geçiş
Mapping'leri yeniden tasarlama fırsatı

Blue-Green Migration

BLUE (Eski Cluster)          GREEN (Yeni Cluster)
─────────────────            ─────────────────
ES 6.8, 5 node              ES 8.12, 5 node
├── index-1                  ├── index-1 (reindex)
├── index-2                  ├── index-2 (reindex)
└── logs-*                   └── logs-* (reindex)
     ↑                            ↑
     │                            │
  [Uygulamalar]               [Uygulamalar]
     │                            │
     └────── DNS/LB Switch ──────┘

// 1. Yeni cluster'da mapping'leri oluştur
// 2. Reindex from remote ile veriyi kopyala
POST _reindex?slices=auto&wait_for_completion=false
{
  "source": {
    "remote": {
      "host": "http://old-cluster:9200",
      "username": "elastic",
      "password": "xxx"
    },
    "index": "products"
  },
  "dest": {
    "index": "products"
  }
}

// 3. Yeni cluster'da query'leri test et
// 4. Uygulama config'ini güncelle (yeni cluster endpoint)
// 5. DNS/Load Balancer'ı yeni cluster'a yönlendir
// 6. Eski cluster'ı decomission et (1 hafta bekle, sonra kapat)

💡 İpucu: Blue-green migration sırasında dual-write yapabilirsiniz: uygulama hem eski hem yeni cluster'a yazar. Böylece geçiş anında veri kaybı olmaz. Migration tamamlanınca eski cluster yazma işlemlerini kapatırsınız.

Özet

Bu derste öğrendiklerimizi toplayalım:

Rolling upgrade, downtime'sız upgrade yöntemidir. Node'ları birer birer durdurup güncellersiniz. Shard allocation'ı kapatmak → flush → node güncelle → allocation aç → GREEN bekle döngüsüdür.
Index compatibility kuralı: ES N.x, sadece N.x ve (N-1).x'te oluşturulan index'leri okuyabilir. 2 major version atlamak için önce eski index'leri reindex edin.
Reindex from remote, farklı cluster'lar arası migration için idealdir. Major version atlama (5.x → 8.x) yapılabilir. Sliced reindex ile paralel çalıştırılabilir.
Snapshot/restore, reindex'ten 5-10x daha hızlıdır. Shared repository (S3, GCS) üzerinden cluster'lar arası veri taşıma yapılır.
Breaking changes her major versiyonda var. Deprecation API ve Upgrade Assistant ile önceden tespit edin. 5.x→6.x (mapping types), 6.x→7.x (default shard), 7.x→8.x (security default) en büyük değişikliklerdir.
Her zaman snapshot alın, test ortamında deneyin, canary deployment yapın. Upgrade bir operasyondur — plansız yapılmaz.