PHP 5 ve MySQL 5.7'den Modern RHEL + MySQL InnoDB Cluster Mimarisine Geçiş

Oradaydık ve Şimdi Buradayız

Bazı yolculuklar, başlamadan önce bakıldığında imkânsız görünür. Önünüzde dağ vardır, geride bıraktığınız evi düşünmenize fırsat vermeyen bir aciliyet vardır ve yol boyunca her köşede sizi kıpırdamaktan caydıracak yeni bir bahane vardır. Yıllarca rahatça çalışmış bir RHEL 6 + Pacemaker + MySQL 5.7.xx + PHP 5 ortamından çıkmak da öyle bir yolculuktur: kapıdan dışarı adım atmak için bin bir sebep yoktur, ama dışarıda kalmak için artık tek bir sebep bile kalmamıştır.

Mayıs 2026 itibarıyla bu mimaride aynı anda dört kritik risk birden devreye girmiş durumdadır:

1. MySQL 5.7 destek ve güvenlik riski — Ekim 2023'ten beri Sustaining Support
2. MySQL 8.0'ın da artık EOL olması — Nisan 2026, sürüm 8.0.46 son sürüm
3. PHP 5 kaynaklı uygulama güvenliği ve uyumluluk riski — Ocak 2019'dan beri EOL
4. RHEL 6 / Pacemaker tabanlı legacy HA mimarisinin sürdürülebilirlik riski

Yolun sonunda lisanslı RHEL 9/10 sunucular üzerinde MySQL 8.4 LTS (veya yeni yayınlanan MySQL 9.7 LTS), InnoDB Cluster ve MySQL Router kullanan modern bir mimari vardır. Aradaki bütün adımlar; doğru bridge işletim sistemi, doğru ara MySQL sürümü, hazır PHP runtime, çalışan authentication plugin, temizlenmiş replication kanalları, doğru bakım penceresi — bunların hepsi aynı anda doğru hizalanmadan o eve varılamaz. Bu yazı, o yolun neden bu kadar dikkatli planlanması gerektiğini anlatır.

Kısa sonuç: Bu tip ortamlarda yalnızca veritabanını yükseltmek yeterli değildir. PHP 5 kodlarının, MyISAM tabloların, authentication eklentilerinin (özellikle Mayıs 2026 itibarıyla MySQL 8.4'te varsayılan olarak kapalı olan mysql_native_password), SQL uyumluluğunun ve HA mimarisinin birlikte ele alınması gerekir. Hiçbir adım tek başına yetmez; ancak hepsi sırayla yerine oturursa "oradaydık ve şimdi buradayız" denilebilir.

1. Neden Bu Yolculuk Artık Ertelenmemeli?

MySQL 5.7 artık güvenli bir hedef sürüm değil

Oracle, MySQL 5.7'nin 25 Ekim 2023 itibarıyla Oracle Sustaining Support kapsamına geçtiğini ve kullanıcıların güncel LTS sürümlerine yükseltilmesini önerdiğini duyurmuştur. Sustaining Support, yeni güvenlik yamasının, bug fix'in veya error correction'ın artık yayınlanmadığı; yalnızca daha önce yayınlanmış güncellemelerin erişilebilir kaldığı bir destek seviyesidir. Yani sistem her gün yeni bir CVE listesine doğru ilerlerken, hiçbir kapı bir daha açılmıyor.

Kaynaklar:

• MySQL Product Support EOL Announcements
• Oracle Lifetime Support Policy

MySQL 8.0 da artık EOL

Önemli güncelleme (Nisan 2026): Oracle, MySQL 8.0.46 sürümünü yayınlayarak MySQL 8.0 hattını resmi olarak Premier Support kapsamı dışına çıkardı ve kullanıcıları MySQL 8.4 LTS veya 9.7 LTS sürümlerine yönlendirdi.

Bu durum, MySQL 5.7'den 8.4'e geçiş için MySQL 8.0'ın hâlâ teknik olarak gerekli bir ara durak olmasına rağmen (Oracle, bir LTS / bugfix serisinin atlanmasına izin vermez), bu adımda kalıcı olarak durulmaması gerektiği anlamına gelir. MySQL 8.0 bir köprüdür, üzerinden geçilir, orada kalınamaz.

Kaynaklar:

• MySQL 8.0 Release Notes — 8.0.46 (End of Life)
• Oracle Blog — MySQL 9.7 Is Out and the Community Wins

PHP 5 güvenlik açısından çok daha kritik

PHP tarafındaki durum çok daha keskindir. PHP resmi dokümantasyonu, PHP 5 desteğinin 10 Ocak 2019'dan beri sonlandığını belirtmektedir. Desteklenen sürümler sayfası, EOL sürümlerin yamalanmamış güvenlik açıklarına maruz kaldığını açıkça ifade eder.

Kaynaklar:

• PHP Supported Versions
• PHP Unsupported Historical Releases

Bu nedenle PHP 5 ile yazılmış sayfalar sadece "eski teknoloji" değil, aynı zamanda doğrudan güvenlik riskidir.

Özellikle aşağıdaki başlıklar kritiktir:

• SQL Injection'a açık eski mysql_* extension kullanımları
• Prepared statement kullanılmayan dinamik SQL üretimi
• Eski session yönetimi davranışları
• Zayıf parola hash algoritmaları (MD5, SHA1)
• Eski TLS / certificate doğrulama davranışları
• Eski framework veya CMS bağımlılıkları
• PHP 7 ve PHP 8 ile kırılacak fonksiyonlar
• Güvenlik yaması alamayan runtime

PHP resmi dokümantasyonuna göre eski mysql extension PHP 5.5.0'da deprecated olmuş, PHP 7.0.0'da tamamen kaldırılmıştır. Yerine mysqli veya PDO_MySQL kullanılması önerilir.

Kaynak:

• PHP Manual — MySQL Original Extension (Removed)

Dolayısıyla MySQL migration planı yapılırken, PHP 5 kodlarının modern MySQL sürümlerine sorunsuz bağlanacağı kesinlikle varsayılmamalıdır.

2. Yola Çıkmadan Önce: Mevcut Tablo

Tipik eski ortam şu şekildedir:

RHEL 6
  └── Pacemaker / Corosync
        └── MySQL 5.7.xx
              ├── InnoDB tablolar
              ├── MyISAM tablolar
              └── PHP 5 uygulama sayfaları

Bu yapıda genellikle aşağıdaki problemler bulunur:

Sistem yöneticilerinin önemli bir kısmı bu noktada "ama burada her şey çalışıyor" der. Çalışıyor olması, güvenli olduğu anlamına gelmez. Yıllar önce kazılan, içi yamalarla dolu o rahat ortam, artık dışarıda dönüşmüş olan dünya için fazla küçüktür.

3.Hedef Mimari

Kalıcı hedef olarak aşağıdaki mimari önerilir:

Application / PHP 8.4 veya 8.5 Layer
        |
        | MySQL Router endpoint
        v
+-------------------------+
| MySQL Router x 2        |
+-------------------------+
        |
        v
+------------------------------------------------+
| MySQL InnoDB Cluster                           |
|                                                |
| mysql-db-01 : RHEL 9/10 + MySQL 8.4 LTS        |
| mysql-db-02 : RHEL 9/10 + MySQL 8.4 LTS        |
| mysql-db-03 : RHEL 9/10 + MySQL 8.4 LTS        |
+------------------------------------------------+

Önerilen hedef:

MySQL 8.4 LTS mi, MySQL 9.7 LTS mi?

Mayıs 2026 itibarıyla iki LTS hattı paralel olarak desteklenmektedir:

• MySQL 8.4 LTS (ilk yayın Temmuz 2024, en güncel sürüm 8.4.x — 2026 ikinci çeyrek): MySQL 8.0'dan gelenler için en güvenli ve test edilmiş migration yolu. Topluluk içinde en yaygın olgunluğa ulaşmış sürüm.
• MySQL 9.7 LTS (ilk yayın 21 Nisan 2026): Yeni LTS baseline. Hypergraph optimizer, Dynamic Data Masking (Enterprise), MySQL REST Service gibi yeni özellikler içerir. 8.4 LTS'den daha yeni, ancak henüz topluluk olgunluğu 8.4 kadar yüksek değil.

PHP 5 + MySQL 5.7 + RHEL 6 gibi büyük teknik borca sahip bir ortamdan çıkıyorsanız konservatif tercih MySQL 8.4 LTS'dir. İlerideki bir bakım fazında 9.7 LTS'ye in-place upgrade'in resmi olarak desteklendiğini unutmamak gerekir.

Kaynaklar:

• MySQL Supported Platforms: Database
• Red Hat — Using MySQL on RHEL 9
• Oracle Blog — MySQL 9.7.0 LTS Is Now Available

4. Neden Doğrudan MySQL 5.7'den MySQL 8.4'e Geçilmemeli?

Oracle dokümantasyonu, MySQL 5.7'den MySQL 8.4'e geçerken MySQL 8.0 serisinin atlanamayacağını açıkça belirtir. Resmi tabloda şu ifade geçer: *"A bugfix or LTS series cannot be skipped, so in this example first upgrade MySQL 5.7 to MySQL 8.0, and then upgrade MySQL 8.0 to MySQL 8.4."*

Bu nedenle doğru upgrade zinciri şudur:

MySQL 5.7.x → MySQL 8.0.46 → MySQL 8.4 LTS (8.4.x)

Kaynak:

• MySQL 8.4 Reference Manual — Upgrade Paths

Önemli olan şu: MySQL 8.0 artık Nisan 2026 itibarıyla EOL olduğu için bu adım yalnızca bir ara duraktır. Sistem 8.0 üzerinde bekletilmemeli; 8.0 doğrulaması yapıldıktan sonra 8.4 LTS'ye geçiş aynı bakım fazı içinde planlanmalıdır.

5. İşletim Sistemi Geçişi: RHEL 6'dan RHEL 9/10'a Tek Adım Yok

İşletim sistemi tarafında da atlamalı bir geçiş gerekir. Red Hat dokümantasyonuna göre desteklenen RHEL 6 → RHEL 7 in-place upgrade yolu yalnızca RHEL 6.10 → RHEL 7.9 şeklindedir. Üstelik RHEL 6.10 için yalnızca Extended Life Phase (ELP) desteği mevcuttur.

Kaynaklar:

• Red Hat — Upgrading from RHEL 6 to RHEL 7
• Red Hat — Upgrading from RHEL 7 to RHEL 8
• Red Hat — Upgrading from RHEL 8 to RHEL 9
• Red Hat — Supported Upgrade Paths

RHEL 7'den RHEL 8'e geçiş Leapp ile yapılır. RHEL 8'den RHEL 9'a geçiş için de ayrı bir Leapp süreci gerekir. RHEL 10 dokümantasyonu da genel prensip olarak in-place upgrade'in ardışık major sürümler arasında yapılabileceğini, birden fazla major version atlamak için birden fazla upgrade gerektiğini belirtir.

Bu yüzden production database sunucusunda aynı anda şunları yapmak çok risklidir:

RHEL 6 → RHEL 7 → RHEL 8 → RHEL 9
MySQL 5.7 → MySQL 8.0 → MySQL 8.4
PHP 5 → PHP 8.4 / 8.5
Pacemaker → InnoDB Cluster
MyISAM → InnoDB

Bu işlemler tek bakım penceresine sıkıştırılamaz. Pratik yol, üretim sunucusunu doğrudan in-place upgrade etmek yerine side-by-side migration ile yeni sunucular kurmaktır.

6. MyISAM Tablolar: Yolu Tıkayan En Ağır Yük

MySQL InnoDB Cluster, Group Replication üzerine kuruludur. Group Replication için InnoDB storage engine zorunludur. Oracle dokümantasyonu, Group Replication'da InnoDB kullanımını ve tablo tasarım gereksinimlerini açıkça belirtir. Aynı dokümanda, Group Replication'a dahil edilecek her tabloda primary key veya non-null unique key olması gerektiği belirtilir.

Kaynak:

• MySQL Group Replication Requirements

Yıllarca büyümüş bir veritabanında bu şartların ne kadarının sağlandığı, ne kadarının düzeltilmesi gerektiği ancak detaylı bir envanter çalışmasıyla ortaya çıkar. Büyük MyISAM tabloların InnoDB'ye dönüşümü; bakım penceresi, lock süresi, index davranışı ve uygulama transaction mantığı açısından ayrı ayrı planlanmalıdır. InnoDB row-level locking ve transaction davranışı, MyISAM table-level lock'tan farklı sonuç verebilir.

7. MySQL 8.4'ün PHP 5 Kodlarında Problem Çıkaracak Değişiklikler

Bu bölüm PHP 5 + MySQL 5.7 ortamı için özellikle kritik'tir. Yolun gerçek darboğazı buradadır: birçok geçiş projesi bütün diğer adımları doğru yaptığı halde tam bu noktada, ışıkları yanan ama içeride kimseyi tanımayan bir koridorda kaybolup geri dönmek zorunda kalır. MySQL 8.4 LTS, 8.0'a göre güvenlik tarafında ciddi sertleştirme yapmıştır ve PHP 5 ile yazılmış uygulamaların büyük çoğunluğu aşağıdaki problemnlerle karşılaşır.

7.1. mysql_native_password artık varsayılan olarak kapalı

MySQL 8.4 itibarıyla mysql_native_password authentication plugin'i sunucuda varsayılan olarak devre dışıdır. PHP 5 ile birlikte gelen eski MySQL client library'leri büyük olasılıkla caching_sha2_password (MySQL 8.0'ın yeni varsayılanı) ile konuşamaz.

Bu durum migration sırasında en yaygın görülen başarısızlık sebebidir. Plugin'i sunucu tarafında geçici olarak aktif etmek mümkündür ancak bu sadece bir nefes alma süresidir; kalıcı çözüm PHP runtime'ını ve client library'sini modernize ederek caching_sha2_password ile konuşur hale getirmektir.

Kaynak:

• MySQL 8.4 Release Notes — Authentication Changes

7.2. Foreign key parent tablolarında unique key zorunluluğu

MySQL 8.4 ile birlikte foreign key tanımlamalarındaki parent tablo kolonları için unique key zorunluluğu sıkılaştırılmıştır. Eski lenient mode'larda oluşturulmuş şemalarda mevcut foreign key tanımları kırılabilir.

7.3. Replication terminolojisi değişikliği

MySQL 8.4'te replication komutlarındaki terminoloji Primary/Secondary → Source/Replica olarak güncellendi. SHOW SLAVE STATUS artık SHOW REPLICA STATUS olarak çalışmaktadır. Legacy script ve monitoring entegrasyonları bu açıdan gözden geçirilmelidir.

7.4. PHP 5 — MySQL 8 arasında muhtemel diğer kırılmalar

Bu listenin her bir maddesi, üretim ortamında ayrı bir kontrol başlığıdır. Hangisinin sizin uygulamanızda gerçekten sorun çıkaracağı; ancak kod tabanının statik analiziyle, staging'de yapılacak bağlantı testleriyle ve eski sorguların yeniden yazılmasıyla ortaya çıkar.

8. Önerilen Geçiş Stratejisi: Side-by-Side Migration ve Geçici Bridge

Bu tip ortamlarda en güvenli yöntem side-by-side migration + geçici upgrade bridge yaklaşımıdır. Production RHEL 6 + Pacemaker ortamı doğrudan bozulmamalıdır. Eski ev, yeni eve sağ salim varılana kadar ışıkları yanık durmalıdır.

Strateji şu mantığa dayanır: Geçici bir RHEL 7.9 sistemi kurulur, MySQL 5.7 verisi bu sisteme alınır, MySQL 8.0 (8.0.46) uyumluluğu burada sağlanır, ardından aynı bakım fazı içinde yeni RHEL 9/10 + MySQL 8.4 LTS hedef mimarisine geçilir. MySQL 8.0'ın da EOL olduğu unutulmayarak bu adım hızlı bir teknik geçiş olarak ele alınır.

Yolculuğun ana hatları şöyle özetlenebilir:

Production RHEL 6 + Pacemaker + MySQL 5.7.xx
        ↓
RHEL 7.9 geçici migration bridge (MySQL 5.7 → 8.0.46)
        ↓
MyISAM → InnoDB + Primary/Unique key düzeltmeleri
        ↓
PHP 5 → PHP 8.4 / 8.5 modernizasyonu
        ↓
RHEL 9/10 + MySQL 8.4 LTS + InnoDB Cluster
        ↓
MySQL Router üzerinden kontrollü cutover
        ↓
Eski ortam read-only — sonra decommission

Bu özetin altında onlarca alt adım, doğrulama, test ve karar noktası vardır: hangi backup yönteminin kullanılacağı, geçici bridge node'un hangi network segmentinde duracağı, schema dönüşümlerinin hangi sırayla yapılacağı, PHP kod modernizasyonunun veritabanı geçişiyle nasıl koordine edileceği, cutover sırasında yazma trafiğinin nasıl durdurulacağı, rollback senaryosunda hangi noktaya dönüleceği, MySQL Shell Upgrade Checker raporlarının nasıl yorumlanacağı, MyISAM analizinden çıkan primary key'siz tabloların düzeltme sırası, authentication plugin'lerin staging testleri, replication terminolojisi nedeniyle bozulacak monitoring script'lerinin önceden tespiti, foreign key parent kolonlarındaki unique key uyumsuzluklarının çözümü, definer kullanıcılarının hedef sisteme aktarılması, character set ve collation farklarının özellikle Türkçe karakter kümesinde yarattığı sürprizlerin ele alınması...

Her bir adımın başarılı olma ihtimali tek başına yüksektir. Ama tüm bu adımların hepsinin doğru sırada, doğru zamanlamada ve birbirini bozmadan tamamlanma ihtimali — işte yolculuğun gerçek zorluğu burada başlar. Bu da yalnızca daha önce bu yolu yürümüş, hangi köşede hangi tuzağın olduğunu bilen bir ekiple çalışıldığında yönetilebilir hâle gelir.

9. Sonuç: Oradaydık ve Şimdi Buradayız

PHP 5 + MySQL 5.7 + RHEL 6 + Pacemaker mimarisi bugün artık sadece teknik borç değil, aynı zamanda güvenlik ve sürdürülebilirlik riskidir. Mayıs 2026 itibarıyla durum şu hâle gelmiştir: MySQL 5.7 Sustaining Support'ta, MySQL 8.0 EOL, PHP 5 yıllardır EOL, RHEL 6 ELP'de. Bu kombinasyonda güvenlik yaması alabilen tek bir bileşen kalmamıştır.

Bu yolculuğun başarısı bir tek şeye bağlıdır: her halkanın doğru sırada, doğru zamanda ve birbirini bozmadan tutması. Doğru bridge işletim sistemi olmasaydı, doğru ara MySQL sürümü olmasaydı, PHP authentication plugin uyumluluğu sağlanmasaydı, MyISAM tablolar primary key'siz kalsaydı, replication terminolojisi atlanmış olsaydı — bunlardan birinin bile eksik olduğu bir gerçeklikte yol yarıda kalırdı. Yolun başarıyla tamamlanması, bağımsız görünen onlarca küçük ihtimalin aynı anda doğru hizalanmasının sonucudur.

Bu tip uzun ve çok adımlı geçişlerde, işin uzmanlarıyla birlikte yürümek her zaman kazandırır. Yıllar sonra eski runbook'lar açıldığında, kapanmış ticket listesinde son madde okunduğunda ve yeni mimari sessizce çalışıyor olduğunda — Bilbo'nun kapısına döndüğünde tuttuğu o defterin son sayfasındaki gibi tek bir cümle yeterlidir:

Oradaydık ve şimdi buradayız.

Kaynaklar

MySQL — Oracle resmi dokümantasyon

• MySQL Product Support EOL Announcements
• MySQL 8.4 Reference Manual — Upgrade Paths
• MySQL 8.4 Reference Manual — Group Replication Requirements
• MySQL Shell 8.4 — InnoDB Cluster Requirements
• MySQL 8.0 Release Notes
• MySQL 8.4 Release Notes
• MySQL 9.7 Release Notes
• MySQL Enterprise High Availability
• MySQL Supported Platforms: Database
• Oracle Lifetime Support Policy (PDF)
• Oracle Blog — MySQL 9.7.0 LTS Is Now Available
• Oracle Blog — MySQL 9.7 Is Out and the Community Wins

PHP resmi dokümantasyon

• PHP Supported Versions
• PHP Unsupported Historical Releases
• PHP Manual — MySQL Original Extension (Removed)
• PHP 8.5 Release Notes
• PHP PDO_MySQL Manual
• PHP mysqli Manual

Red Hat resmi dokümantasyon

• Red Hat — Upgrading from RHEL 6 to RHEL 7
• Red Hat — Upgrading from RHEL 7 to RHEL 8
• Red Hat — Upgrading from RHEL 8 to RHEL 9
• Red Hat — Supported in-place upgrade paths
• Red Hat — Using MySQL on RHEL 9