InnoDB'nin mimarisi dört temel tür bilgi sayfasının kullanılmasını gerektirir.
- Tablo Veri Sayfaları
- Tablo Dizin Sayfaları
- Tablo MetaData
- MVCC Verileri (İşlem İzolasyonu ve ACID Uyumluluğunu desteklemek için )
- Geri Alma Segmentleri
- Boşluğu Geri Al
- Çift Yazma Arabelleği (işletim sistemi önbelleğe alma güvenini önlemek için arka plan yazma)
- Arabellek Ekle (benzersiz olmayan ikincil dizinlerde yapılan değişiklikleri yönetme)
İbdata1 Resimli Temsiline Bakın
Varsayılan olarak, innodb_file_per_table devre dışı bırakılmıştır. Bu, dört bilgi sayfası türünün hepsinin ibdata1 adlı tek bir dosyayı indirmesine neden olur. Birçok kişi, birden fazla ibdata dosyası oluşturarak verileri dağıtmaya çalışır. Bu, verilerin parçalanmasına ve dizin sayfalarına yol açabilir.
Bu nedenle, genellikle varsayılan ibdata1 dosyasını ve daha fazlasını kullanarak InnoDB altyapısını temizlemenizi öneririm .
InnoDB'nin çalıştığı altyapı nedeniyle kopyalama çok tehlikelidir. İki temel altyapı var.
- innodb_file_per_table devre dışı
- innodb_file_per_table etkin
İle innodb_file_per_table engelli, InnoDB'nin bilgi tüm bu tür ibdata1 içinde yaşamaktadır. Herhangi bir InnoDB tablosunun ibdata1 dışındaki tek tezahürü, InnoDB tablosunun .frm dosyasıdır. Tüm InnoDB verilerini bir kerede kopyalamak, tüm / var / lib / mysql öğelerinin kopyalanmasını gerektirir.
Tek bir InnoDB masasını kopyalamak tamamen imkansızdır. Verilerin ve buna karşılık gelen indeks tanımlarının mantıksal bir temsili olarak tablonun bir dökümünü çıkarmak için MySQL dökümünü kullanmalısınız. Daha sonra o dökümü aynı sunucudaki veya başka bir sunucudaki başka bir veritabanına yüklersiniz.
İle innodb_file_per_table etkin, tablo veri ve indeksleri sonraki .frm dosyaya veritabanı klasöründe yaşıyor. Örneğin, db1.mytable tablosu için, bu InnoDB tablosunun ibdata1 dışındaki tezahürü şöyle olacaktır:
/var/lib/mysql/db1/mytable.frm/var/lib/mysql/db1/mytable.ibd
Sistem Tablo Alanı ibdata1
Db1.mytable için tüm meta veriler hala ibdata1'de bulunur ve bunun kesinlikle bir yolu yoktur . Yinelenen kütükler ve MVCC verileri de yine de ibdata1 ile yaşıyor.
Tablo parçalanmasına gelince, işte ibdata1'e ne olur:
- innodb_file_per_table etkin : db1.mytables dosyasını
ALTER TABLE db1.mytable ENGINE=InnoDB;veyaile daraltabilirsinizOPTIMIZE TABLE db1.mytable;. Bu, /var/lib/mysql/db1/mytable.ibd dosyasında fiziksel olarak daha küçük parçalanma olmadan sonuçlanır.
- innodb_file_per_table devre dışı bırakıldı : db1.mytables dosyasını
ALTER TABLE db1.mytable ENGINE=InnoDB;ya daibdata1 ileOPTIMIZE TABLE db1.mytable;bulunduğundan daraltamazsınız. Her iki komutu da çalıştırarak masayı okumaya ve yazmaya hızlı ve bitişik hale getirin. Ne yazık ki, bu ibdata1 sonunda gerçekleşir. Bu, ibdata1'in hızla büyümesini sağlar. Bu tamamen InnoDB Temizleme Görevimde ele alındı .
Sadece .frm ve .ibd dosyalarını kopyalamayı düşünüyorsanız, incinecek dünya için aynı çizgidesiniz. Bir InnoDB tablosunun .frm ve .ibd dosyasını kopyalamak, yalnızca .ibd dosyasının tablo alanı kimliğinin ibdata1 dosyasının meta verilerindeki tablo alanı kimliği girişi ile tam olarak eşleştiğini garanti edebiliyorsanız iyidir .
Bu tablo alanı kimliği kavramı hakkında DBA StackExchange'te iki yazı yazdım
Eşleşmeyen tablo alanı kimlikleri durumunda, herhangi bir .ibd dosyasını ibdata1'e yeniden eklemek için mükemmel bir bağlantı: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . Bunu okuduktan sonra, .ibd dosyalarını kopyalamanın sadece delice olduğunu hemen fark etmeniz gerekiyor.
InnoDB için, sadece bunu hareket ettirecek bir şeye ihtiyacınız var.
CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
InnoDB tablonun bir kopyasını almak için.
Başka bir DB sunucusuna geçiriyorsanız, mysqldump kullanın.
Tüm InnoDB tablolarını tüm veritabanlarından karıştırmakla ilgili olarak, bunu yaparken bilgeliği gerçekten görebiliyorum. İşverenimin DB / Web barındırma şirketinde, aynı MySQL örneği içinde başka bir veritabanındaki kısıtlamaları başka bir veritabanında eşlenen bir veritabanında bir tablo bulunan bir MySQL İstemcisi var. Bir ortak meta veri deposuyla, birden çok veritabanında işlem desteğini ve MVCC çalışabilirliğini mümkün kılar.