13 Ekim 2026 - 09:31
phpMyAdmin ile Büyük SQL Dosyası İçe Aktarma: Limit ve Zaman Aşımı Görseli
Veritabanları

phpMyAdmin ile Büyük SQL Dosyası İçe Aktarma: Limit ve Zaman Aşımı

Yorumlar

SQL yedeğini seçiyorsunuz, içe aktarma başlıyor ve birkaç dakika sonra boş bir ekran ya da zaman aşımı hatası geliyor. İlk refleks dosyayı yeniden yüklemek oluyor. Oysa önceki deneme bazı tabloları oluşturmuş, hatta binlerce satırı yazmış olabilir. Aynı dosyayı tekrar çalıştırmak bu kez başka bir hatayla durabilir.

Büyük SQL dosyalarında önce başarısızlığın hangi katmanda olduğunu ayırmak gerekir: dosya henüz PHP'ye ulaşmadı mı, phpMyAdmin çalışırken mi süre doldu, yoksa MySQL bir SQL komutunu mu reddetti? Bu üç durumun çözümü aynı değildir. Aşağıdaki akış, üretim veritabanına tekrar tekrar deneme yapmak yerine ayrı bir geri yükleme alanında ilerler.

Hata mesajı hangi sınıra işaret ediyor?

  • Dosya seçilirken boyut sınırı: PHP'nin upload_max_filesize ve post_max_size değerlerini inceleyin.
  • 413 Request Entity Too Large: İstek PHP'ye gelmeden web sunucusu veya ters vekil tarafından reddediliyor olabilir.
  • 504 veya bağlantının kapanması: Üst katmandaki bekleme süresi dolmuş olabilir. Bu mesaj veritabanı işleminin kesin durduğunu göstermez.
  • 1153 / packet bigger than max_allowed_packet: Dosyanın toplam boyutundan çok, içindeki tek bir SQL ifadesi veya iletişim paketi önemlidir.
  • 1062 veya 1273: Bunlar yükleme limitinden bağımsız kayıt çakışması ve collation sorunlarıdır.

Hatanın tam metnini, saatini ve varsa SQL satır numarasını kaydedin. phpMyAdmin ekranındaki mesajı web sunucusu ve PHP hata günlükleriyle karşılaştırın. Sadece tarayıcının bekleme simgesine bakarak aktarımın sürdüğüne veya bittiğine karar vermeyin.

PHP limitini doğru yerde kontrol edin

Terminalde görülen PHP ayarları, phpMyAdmin'i çalıştıran PHP-FPM havuzunun ayarlarıyla aynı olmak zorunda değildir. Hosting panelindeki ilgili alan adının PHP yapılandırmasını veya web isteğinin kullandığı SAPI'yi kontrol edin. İnternete açık bir phpinfo() sayfası bırakmayın.

Örneğin 150 MB civarında bir yükleme için aşağıdaki değerler yalnızca bir başlangıç örneğidir; sunucunun kaynakları ve diğer limitler ayrıca değerlendirilmelidir. post_max_size, dosyayla birlikte gönderilen form verilerine de yer bırakmalıdır.

INI
upload_max_filesize = 192M
post_max_size = 224M

Yapılandırma değişikliğinin ilgili PHP hizmetinde etkinleştiğini doğrulayın. Yükleme kabul edildi diye bellek ve çalışma süresi sorunlarının çözüldüğünü varsaymayın. Sunucunun RAM miktarını gözetmeden yüksek memory_limit tanımlamak veya bütün zaman aşımlarını sınırsız yapmak, ortak sunucuda başka siteleri de etkileyebilir. Dosya büyüdükçe tarayıcı üzerinden aktarım yerine istemci kullanmak genellikle daha yönetilebilir olur.

Komut satırından önce yedeğin hedefini okuyun

İstemciye test veritabanının adını vermek tek başına koruma değildir. Döküm içinde USE eski_veritabani, CREATE DATABASE veya DROP TABLE bulunabilir. Dosyanın başlangıcını ve şema komutlarını inceleyin; orijinal yedeği değiştirmeyin. Dökümün yalnızca seçilen test alanına yazabileceği kısıtlı bir kullanıcıyla çalışın.

Test alanı boş olmalı; yeterli disk alanı bulunmalı ve uygulama bu alana bağlı olmamalıdır. Gerçek müşteri verisi içeren yedeği web kök dizinine koymayın. Aktarım kullanıcısına bütün sunucuda yetki vermek, yanlış hedef riskini büyütür. Yedeğin tablo tanımlarında kullandığı motorlar ve sunucuya özel özellikler de hedefte desteklenmelidir.

mysql istemcisinde SOURCE ile içe aktarma

Aşağıdaki ilk komut işletim sistemi terminalinde çalışır. restore_user ve restore_test örnek adlardır; test hesabı ve veritabanı önceden hazırlanmalıdır. Parolayı komutun içine yazmayın, istemcinin sormasını bekleyin.

SHELL
mysql --default-character-set=utf8mb4 -u restore_user -p restore_test

Bağlantı açıldığında önce sunucuyu ve seçili veritabanını kontrol edin. Son satırdaki dosya yolu, mysql istemcisinin çalıştığı bilgisayardaki dosyadır. Uzak sunucuya bağlandığınız için yol kendiliğinden uzak sunucuya ait olmaz.

SQL
SELECT @@hostname, VERSION(), DATABASE();
SOURCE /secure/backups/site.sql;

Windows'ta boşluk içermeyen bir yol için SOURCE C:/Backups/site.sql; kullanılabilir. Bu yöntem, PowerShell'de farklı davranan kabuk yönlendirmesiyle uğraşmadan dosyayı istemciye okutur. Ekrandaki ilk hata dahil bütün mesajları inceleyin; son satırın başarılı görünmesi önceki komutların tamamının başarılı olduğu anlamına gelmez. Hata sonrası devam davranışını kullandığınız istemci sürümünde doğrulayın.

Dosya yüklendi ama paket hatası devam ediyor

SQL
SHOW VARIABLES LIKE 'max_allowed_packet';

Bu değer sunucu tarafını gösterir; istemcinin de paket sınırı vardır. Tek bir çok büyük INSERT veya BLOB alanı sınırı aşabilir. Ölçüm yapmadan tüm sunucu için çok yüksek bir değer belirlemeyin. Kaynaktan yeniden yedek alınabiliyorsa daha küçük INSERT gruplarıyla döküm üretmek değerlendirilebilir; ancak tek bir büyük alanı bu yöntem küçültmez. Sorun aktarımdaki toplam dosya boyutu değilse dosyayı sıkıştırmak da çözüm değildir.

SQL dosyasını metin satırlarından rastgele bölmeyin. Bir metin alanı, yorum veya INSERT ifadesi birden fazla satıra yayılabilir. Benzer şekilde bütün dosyayı transaction içine almak, DDL komutlarının örtük commit davranışını ortadan kaldırmaz.

Yarıda kalan aktarımı yeniden başlatmadan önce

Canlı tabloları boşaltmak yerine başarısız test alanını inceleyin ve yeni, temiz bir test alanı hazırlayın. Kayıt çakışması oluştuysa Duplicate Entry 1062 teşhis akışı ile hangi kayıtların önceden yazıldığını belirleyin. Aktarım tamamlandığında ise geri yükleme doğrulama kontrollerini uygulayın; dosyanın kabul edilmiş olması, yedeğin eksiksiz geri döndüğü anlamına gelmez.

Teknik başvuru: phpMyAdmin FAQ, MySQL dosyadan komut çalıştırma ve paket boyutu hataları.

Benzer Yazılar

Yorumlar ()

Henüz yorum yok. İlk yorum yapan sen ol!

Yorum Yap