Büyük SQL İçe Aktarma: Zaman Aşımı ve Hata Olmadan

dump.sql dosyasını seçtiniz, Import düğmesine bastınız, ilerleme çubuğu yarıya kadar geldi ve sonra sayfa beyazladı. Ya da daha kötüsü: 504 Gateway Timeout mesajı geldi ve MySQL günlüğünü açtığınızda tablonun yarım yamalak oluşturulduğunu ve bir sonraki içe aktarmanın Table already exists hatasına takıldığını görüyorsunuz. İşte bu tam olarak çoğu site yöneticisinin saatlerini kaybettiği yerdir. Sorun ne internet hızınız ne de dökümün bozuk olması; mesele, web aracının büyük dosyalar için tasarlanmamış olmasıdır.

Büyük SQL içe aktarma phpMyAdmin'den neden başarısız olur

Web panelinden içe aktardığınızda, dosya önce tarayıcıdan PHP'ye yüklenmeli, sonra PHP onu MySQL'e aktarmalıdır. Yolunuzda üç ayrı sınır vardır ve her biri farklı bir hata mesajı verir:

• php.ini içindeki upload_max_filesize ve post_max_size — dosya daha büyükse, $_FILES boş döner ve phpMyAdmin "No file was uploaded" der.
• max_execution_time — genellikle 30 veya 60 saniye. 200 megabaytlık bir dosya bundan çok daha uzun sürer ve betik iş ortasında öldürülür.
• MySQL'deki max_allowed_packet — birçok sürümde varsayılan 4 megabayttır. Tek satırlık büyük bir INSERT bundan büyükse, önceki iki sınırı aşmış olsanız bile MySQL server has gone away hatası alırsınız.

Az söylenen bir nokta: bu değerleri paylaşımlı hosting'de yükseltmek her zaman işe yaramaz, çünkü web sunucusunun PHP önünde kendi bağımsız zaman aşımı olan bir proxy katmanı vardır. max_execution_time değerini 600 yapsanız bile, proxy 120. saniyede bağlantıyı kapatabilir. Hangi sınırın gerçekten size çarptığını bilmek için eksiksiz hosting kaynak sınırları referansına bakın; oradaki her sayı hangi parametrenin neyi saydığını belirtir.

Birinci yol: Dökümü split ile parçalayarak içe aktarma

SSH erişiminiz varsa, bu en temiz yoldur. Dosyayı küçük parçalara bölün ve her parçayı ayrı ayrı içe aktarın. Linux'taki split aracı bu işi birkaç saniyede yapar, ancak bir INSERT komutunun ortasından kesmemeye dikkat etmelisiniz.

split -l 5000 dump.sql chunk_ --additional-suffix=.sql
for f in chunk_*.sql; do
  mysql -u dbuser -p dbname < "$f" || echo "FAILED: $f"
done

5000 satır sayısı makul bir başlangıç noktasıdır; tablolarınızda çok büyük kayıtlar varsa daha da düşürün. Bu yöntemin avantajı, yedinci parça başarısız olduğunda tüm dökümü değil, yalnızca o parçayı yeniden çalıştırmanızdır. Dezavantajı da açıktır: dökümünüz işlem tabanlıysa ve tabloların birbirine yabancı anahtar bağımlılığı varsa, parçaların sıralı çalıştırılması geçici olarak constraint hatası verebilir. Bu durumda her parçanın başına SET FOREIGN_KEY_CHECKS=0; koymalı ve son parçanın sonunda tekrar açmalısınız.

Split neden her zaman yeterli değildir

Bazı dökümlerde tek bir kayıt kendisi 50 megabayttır (örneğin base64 içerikli bir LONGTEXT alanı). Burada satır bazlı split hiçbir işe yaramaz, çünkü o tek satır max_allowed_packet sınırından büyüktür. Ya paket değerini yükseltmelisiniz ya da her kaydın ayrı bir komut olması için mysqldump ile --skip-extended-insert seçeneğiyle döküm almalısınız.

İkinci yol: Tarayıcıdan yükleme yapmadan doğrudan sunucuda çalıştırma

Döküm dosyası aynı sunucudaysa, PHP'ye ve tarayıcıya hiç ihtiyacınız yoktur. Doğrudan MySQL istemcisiyle içe aktarın:

mysql -u dbuser -p --max_allowed_packet=256M dbname < /home/user/dump.sql

Bu komutun ne tarayıcı zaman aşımı ne de PHP yükleme sınırı vardır. Geriye kalan tek kısıtlama, sorguların kendi çalışma süresidir ve bu SET SESSION wait_timeout=0; ile yönetilebilir. Dosya başka bir sunucudaysa, önce scp ile taşıyın, sonra içe aktarın. 500 megabaytı iç ağ üzerinden aktarmak genellikle bir dakikadan kısa sürer; oysa aynı dosya tarayıcı üzerinden on dakika sürebilir ve sonunda başarısız olabilir.

Özel sunucuda bu yöntem neredeyse her zaman en iyi seçenektir, çünkü kaynaklar sizin elinizdedir ve içe aktarmayı hızlandırmak için innodb_buffer_pool_size değerini geçici olarak yükseltebilirsiniz. Paylaşımlı hosting'de bu parametreler değiştirilemez ve varsayılan değerlerle çalışmanız gerekir.

Üçüncü yol: Yalnızca phpMyAdmin erişilebilir olduğunda

Bazı hosting'ler SSH vermez ve yalnızca web paneliniz vardır. Bu durumda iki şey yapabilirsiniz. Birincisi, dosyayı gzip ile sıkıştırın; phpMyAdmin .sql.gz dosyasını kendisi açar ve aktarım hacmini yüzde 80'e kadar azaltır. İkincisi, kendi partial import seçeneğini kullanın: Import sekmesinde "Partial import" bölümünü açın ve her seferdeki satır sayısını örneğin 2000 yapın. phpMyAdmin dosyayı belirtilen satırdan kendisi devam ettirir.

Bu yöntem yavaştır ve 500 megabayt üzeri dökümler için pratikte kullanılamaz. Büyük dökümlerle sık sık uğraşıyorsanız, SSH erişimli Linux hosting'e geçme zamanı gelmiştir; farkı tam da bu anlarda görürsünüz.

Burada hata yapıyorlar

En sık gördüğüm hata şudur: kullanıcı içe aktarmayı yarıda bırakır, sonra baştan yeniden çalıştırır ve Table 'x' already exists hatasına çarpar. Sonra tabloları elle silmeye başlar ve tabloların birbirine yabancı anahtarı olduğu için silme de başarısız olur. Belirtisi şudur: phpMyAdmin'de tablo listesini görürsünüz ama kayıt sayısı sıfırdır veya yarımdır. Doğru yol, her yeniden denemeden önce veritabanını tamamen boşaltmaktır:

DROP DATABASE dbname;
CREATE DATABASE dbname CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

İkinci hata: collation'ı görmezden gelmek. Döküm utf8mb4_unicode_ci ile oluşturulmuşsa ve hedef veritabanı latin1 ise, içe aktarma başarılı olur ama Farsça metinler sonradan سلام biçiminde görünür. Bu, içe aktarmadan sonra düzeltilemez; veritabanını baştan doğru collation ile oluşturmalısınız.

Başlamadan önce üç şeyi kontrol edin

1. Dosyanın boyutunu ve satır sayısını bilin: wc -l dump.sql ve du -h dump.sql.
2. Kaynak ve hedef MySQL sürümlerini karşılaştırın. MySQL 8'den alınan bir döküm, MySQL 5.7 sunucusunda sıklıkla syntax hatası verir, özellikle collation tanımlarında.
3. Yeterli disk alanı olduğundan emin olun. 200 megabaytlık bir döküm, içe aktarmadan sonra genellikle iki ila üç katı yer kaplar, çünkü indeksler eklenir.

Hedef sunucunun durumunu hızlıca kontrol etmek ve doğru şekilde resolve edildiğinden emin olmak için DNS ve ağ kontrol aracı işinizi görür. Veritabanında herhangi bir değişiklik yapmadan önce sağlıklı bir yedek almak istiyorsanız, ücretsiz web yöneticisi araçları iyi bir başlangıç noktasıdır.

Özetle: SSH'ınız varsa, asla tarayıcıdan içe aktarmayın. SSH'ınız yoksa, dosyayı sıkıştırın ve partial import'u düşük satır sayısıyla çalıştırın. Ve her yeniden denemeden önce veritabanını tamamen silin ki yinelenen tablo hatasıyla uğraşmayın.

Sık sorulan sorular

Büyük SQL içe aktarma neden MySQL server has gone away hatasıyla durur?

Bu hata neredeyse her zaman max_allowed_packet ile ilgilidir. Bir INSERT komutu bu değerden büyük olduğunda, MySQL sunucusu bağlantıyı kapatır. Birçok kurulumda varsayılan değer 4 megabayttır. Bunu 64 veya 256 megabayta yükseltin ya da her kaydın ayrı bir komut olması için dökümü --skip-extended-insert ile alın.

SQL dosyasını gzip ile sıkıştırıp doğrudan içe aktarabilir miyim?

Evet, hem phpMyAdmin hem de MySQL komut satırı istemcisi .sql.gz dosyasını okur. Komut satırında zcat dump.sql.gz | mysql -u user -p dbname kullanmanız yeterlidir. Sıkıştırma aktarım hacmini büyük ölçüde azaltır ve metin dökümlerinde genellikle yüzde 70 ila 85 arasında tasarruf sağlar.

İçe aktarmadan sonra Farsça metinler neden soru işareti veya garip karakterler olarak görünür?

Sorun collation'dır, içe aktarma değil. Hedef veritabanı CHARACTER SET utf8mb4 ve COLLATE utf8mb4_unicode_ci ile oluşturulmuş olmalıdır. Döküm bu ayarlarla oluşturulmuşsa ama hedef latin1 ise, baytlar yanlış yorumlanır. Bu, içe aktarmadan sonra onarılamaz; veritabanını doğru collation ile yeniden oluşturmalı ve dökümü tekrar içe aktarmalısınız.

2 gigabaytlık bir döküm için hangi yöntemi önerirsiniz?

Bu boyutta phpMyAdmin'i bir kenara bırakın. En iyi seçenek, dosyayı scp ile sunucuya taşımak ve doğrudan mysql < dump.sql çalıştırmaktır. SSH'ınız yoksa, dökümü 50 megabaytlık parçalara bölün ve her parçayı ayrı ayrı içe aktarın. Paylaşımlı hosting'de bir gigabayt üzeri dökümler genellikle kaynak sınırına takılır ve daha üst bir plana geçiş için destekle görüşmeniz daha iyi olur.