Tablonun sadece birinin milyonlarca satıra çıkacağı, geri kalanının ise bir milyonun altında olacağı bir uygulamamız var. Peki innodb_file_per_table ile gitmeli ya da tek bir .ibd olarak bırakmalıyız? Yapılması gereken daha fazla disk erişimine ihtiyacınız olduğu için onunla gitme derim bazı makaleler okudum? Nesil raporlama amacıyla bu tabloyla diğerlerinin arasına katılacağız.
Yanıtlar:
İnnodb_file_per_table ile gitmelisiniz ve InnoDB'nin mevcut altyapısıyla ne kadar temizlik yapmalısınız.
Birçok DB barındırma istemcileri MySQL kurulumu gördüm ve InnoDB varsayılan durumunda bırakın. Bu, sistem tablo alanının (daha iyi ibdata1 olarak bilinir) çılgınca büyümesine neden olur.
İnnodb_file_per_table dosyasına geçseniz bile, .ibd dosyasının ibdata1'den ayıklanması gerekir ve ibdata hiçbir zaman küçülmez. Örneğin, ibdata1 içinde 2GB alan mydb.mytable adlı bir tablonuz varsa, ayıklamak için aşağıdakilere ihtiyacınız vardır:
ADIM 01) /etc/my.cnf dosyasına ekleyin
[mysqld]
innodb_file_per_tableADIM 02) service mysql restart
ADIM 03) ALTER TABLE mydb.mytable ENGINE=InnoDB;
/Var/lib/mysql/mydb/mytable.ibd dosyası
Ne yazık ki, değişiklikten önce tablo tarafından işgal edilen 2GB alan geri alınamaz. InnoDB'nin altyapısını nasıl ve niçin temizleyeceğimize dair geçmiş yazıları yazdım:
Bu büyük değişikliği yaptıktan sonra innodb_open_files değerini artırmayı unutmayın (varsayılan 300) . Aksi takdirde, disk erişimi çok sınırlıdır.
Birleşimlerle ilgili olarak, birleştirme ölçütlerini destekleyen uygun dizinlere sahip olduğunuzdan emin olun.
Yeni bir kurulumda innodb_file_per_table kullanmak ibdata1'in çok yavaş büyümesine neden olur, çünkü tüm DDL'ler ibdata dışında yapılır. Daha önce de belirttiğim gibi herhangi bir InnoDB tablosunu küçültebilirsiniz:
ALTER TABLE mydb.mytable ENGINE=InnoDB;Yedeklemeler söz konusu olduğunda, .ibd dosyalarının kopyalarını oluşturmaya son derece dikkat edin. Neden?
Her .ibd dosyasının içinde tablespace_id olarak bilinen özel bir değer vardır. İbdata1 içinde tablespace_id değerlerinin bir listesi vardır. Tabloyu bırakmayı ve yeniden oluşturmayı gerektiren tablo bakımı gerçekleştirirseniz, tablespace_id öğesi farklı olur. Böyle bir .ibd dosyasının kopyasını oluşturmak, yalnızca ibdata1'in bir kopyasını da yaparsanız kullanım için veritabanına geri döndürülebilir. Bu, diğer tüm InnoDB tablolarının tablespace_id değerini tehlikeye sokar. Bunun ışığında, mysqldump yedeklemelerini gerçekleştirmeniz tercih edilir, çünkü mysqldumps verilerin mantıksal kopyalarıdır. Başka bir deyişle, yedekleme ibdata1'in zaman noktasından bağımsızdır ve çalışabilirlik sorunları olmadan yeniden yükleme yapmakta serbestsiniz.
Bahsetmediği bir şey için @RolandoMySQLDBA ile anlaşın: yedekler.
MySQL yedekleme rejiminiz işe yaradıysa ve .ibd dosyasını dosya sistemi yedekleme stratejinize dahil etmiyorsanız, bu o kadar önemli değildir. Ancak herhangi bir innodb tablosuna ONE BYTES eklemenin, akıllıca .ibd tablonuzun artımlı yedeklemesine neden olacağını ve hızlı bir şekilde yedek depolama alanınızın tükeneceğini görebilirsiniz.
Tam olarak bu duruma sahip olduğum bir uygulama var: bazı büyük masalar ve bazı küçük masalar.
Küçük olanları bırakıp ibdata1büyük dosyaları kendi dosyalarına koymaya karar verdim .
Ben ettikten bunu innodb_file_per_tablevarsayılan olarak açılır ve yalnızca bir tablo taşımak için geçici olarak kapatmak ibdata1ile ALTER TABLE.
ALTER TABLE. Bu yüzden stratejim, innodb_file_per_tableküçük bir tabloyu içine taşımak ibdata1ve daha sonra tekrar açmak için düzenli olarak açmak ve rasgele kapatmaktır .