Apakah mungkin untuk membersihkan mesin penyimpanan mysql innodb sehingga tidak menyimpan data dari tabel yang dihapus?

Atau apakah saya harus membangun kembali database baru setiap saat?

Berikut adalah jawaban yang lebih lengkap sehubungan dengan InnoDB. Ini sedikit proses yang panjang, tetapi bisa sepadan dengan usaha.

Ingatlah bahwa itu /var/lib/mysql/ibdata1adalah file tersibuk di infrastruktur InnoDB. Biasanya menampung enam jenis informasi:

• Tabel Data
• Indeks Tabel
• Data MVCC (Multiversioning Concurrency Control)
  • Segmen kembalikan
  • Batalkan Spasi
• Metadata Tabel (Kamus Data)
• Double Write Buffer (penulisan latar belakang untuk mencegah ketergantungan pada caching OS)
• Masukkan Buffer (mengelola perubahan pada indeks sekunder yang tidak unik)
• Lihat Pictorial Representation of ibdata1

Arsitektur InnoDB

Banyak orang membuat banyak ibdatafile dengan harapan untuk manajemen dan kinerja ruang disk yang lebih baik, namun kepercayaan itu keliru.

Bisakah saya lari OPTIMIZE TABLE?

Sayangnya, menjalankan OPTIMIZE TABLEterhadap tabel InnoDB yang disimpan dalam file ruang-tabel bersama ibdata1melakukan dua hal:

• Membuat data tabel dan indeks berdekatan di dalamnya ibdata1
• Membuat ibdata1tumbuh karena data yang berdekatan dan halaman indeks ditambahkan keibdata1

Namun Anda dapat, memisahkan Data Tabel dan Indeks Tabel dari ibdata1dan mengelolanya secara mandiri.

Dapatkah saya menjalankan OPTIMIZE TABLEdengan innodb_file_per_table?

Misalkan Anda untuk menambahkan innodb_file_per_tableke /etc/my.cnf (my.ini). Lalu bisakah Anda menjalankan OPTIMIZE TABLEsemua Tabel InnoDB?

Kabar Baik : Ketika Anda menjalankan OPTIMIZE TABLEdengan innodb_file_per_tablediaktifkan, ini akan menghasilkan .ibdfile untuk tabel itu. Misalnya, jika Anda memiliki tabel mydb.mytabledengan datadir /var/lib/mysql, itu akan menghasilkan yang berikut:

• /var/lib/mysql/mydb/mytable.frm
• /var/lib/mysql/mydb/mytable.ibd

The .ibdakan berisi Pages Data dan Indeks Pages untuk meja itu. Bagus.

Berita Buruk : Yang Anda lakukan hanyalah mengekstrak Halaman Data dan Halaman Indeks mydb.mytabledari saat tinggal di ibdata. Entri kamus data untuk setiap tabel, termasuk mydb.mytable, masih tetap ada dalam kamus data (Lihat Representasi Pictorial dari ibdata1 ). ANDA TIDAK BISA HANYA SIMPLY HAPUS ibdata1DENGAN TITIK INI !!! Harap dicatat bahwa ibdata1tidak menyusut sama sekali.

Pembersihan Infrastruktur InnoDB

Untuk menyusut ibdata1sekali dan untuk semua Anda harus melakukan hal berikut:

1. Buang (misalnya, dengan mysqldump) semua basis data ke dalam .sqlfile teks ( SQLData.sqldigunakan di bawah)

2. Jatuhkan semua basis data (kecuali untuk mysqldan information_schema) CAVEAT : Sebagai tindakan pencegahan, jalankan skrip ini untuk memastikan Anda memiliki semua hibah pengguna:

   mkdir /var/lib/mysql_grants
   cp /var/lib/mysql/mysql/* /var/lib/mysql_grants/.
   chown -R mysql:mysql /var/lib/mysql_grants

3. Login ke mysql dan jalankan SET GLOBAL innodb_fast_shutdown = 0;(Ini akan sepenuhnya menghapus semua perubahan transaksi yang tersisa dari ib_logfile0dan ib_logfile1)

4. Shutdown MySQL

5. Tambahkan baris berikut ke /etc/my.cnf(atau my.inidi Windows)

   [mysqld]
   innodb_file_per_table
   innodb_flush_method=O_DIRECT
   innodb_log_file_size=1G
   innodb_buffer_pool_size=4G

   (Sidenote: Apa pun yang Anda setel untuk innodb_buffer_pool_size, pastikan innodb_log_file_size25% dari innodb_buffer_pool_size.

   Juga: innodb_flush_method=O_DIRECTtidak tersedia di Windows)

6. Hapus ibdata*dan ib_logfile*, Secara opsional, Anda dapat menghapus semua folder /var/lib/mysql, kecuali /var/lib/mysql/mysql.

7. Mulai MySQL (Ini akan membuat ulang ibdata1[10MB secara default] dan ib_logfile0dan ib_logfile1pada 1G masing-masing).

8. Impor SQLData.sql

Sekarang, ibdata1masih akan tumbuh tetapi hanya berisi tabel metadata karena setiap tabel InnoDB akan ada di luar ibdata1. ibdata1tidak akan lagi berisi data InnoDB dan indeks untuk tabel lainnya.

Misalnya, anggap Anda memiliki tabel InnoDB bernama mydb.mytable. Jika Anda melihat /var/lib/mysql/mydb, Anda akan melihat dua file yang mewakili tabel:

• mytable.frm (Header Mesin Penyimpan)
• mytable.ibd (Tabel Data dan Indeks)

Dengan innodb_file_per_tableopsi di /etc/my.cnf, Anda dapat menjalankan OPTIMIZE TABLE mydb.mytabledan file /var/lib/mysql/mydb/mytable.ibdakan benar-benar menyusut.

Saya telah melakukan ini berkali-kali dalam karir saya sebagai DBA MySQL. Faktanya, pertama kali saya melakukan ini, saya menyusutkan file 50GB ibdata1 menjadi hanya 500MB!

Cobalah. Jika Anda memiliki pertanyaan lebih lanjut tentang ini, tanyakan saja. Percayalah kepadaku; ini akan bekerja dalam jangka pendek maupun jangka panjang.

CAVEAT

Pada Langkah 6, jika mysql tidak dapat memulai kembali karena mysqlskema mulai dijatuhkan, lihat kembali pada Langkah 2. Anda membuat salinan fisik mysqlskema. Anda dapat mengembalikannya sebagai berikut:

mkdir /var/lib/mysql/mysql
cp /var/lib/mysql_grants/* /var/lib/mysql/mysql
chown -R mysql:mysql /var/lib/mysql/mysql

Kembali ke Langkah 6 dan lanjutkan

UPDATE 2013-06-04 11:13 EDT

Berkenaan dengan pengaturan innodb_log_file_size ke 25% dari innodb_buffer_pool_size pada Langkah 5, aturan blanket itu agak kuno.

Kembali July 03, 2006, Percona punya artikel bagus mengapa memilih innodb_log_file_size yang tepat . Kemudian, pada Nov 21, 2008, Percona menindaklanjuti dengan artikel lain tentang bagaimana cara menghitung ukuran yang tepat berdasarkan beban kerja puncak menjaga satu jam perubahan .

Sejak itu saya telah menulis posting di DBA StackExchange tentang menghitung ukuran log dan di mana saya mereferensikan dua artikel Percona itu.

• Aug 27, 2012: Penyetelan yang benar untuk tabel InnoDB 30GB di server dengan 48GB RAM
• Jan 17, 2013: MySQL 5.5 - Innodb - innodb_log_file_size lebih tinggi dari gabungan 4GB?

Secara pribadi, saya masih akan pergi dengan aturan 25% untuk pengaturan awal. Kemudian, karena beban kerja dapat lebih akurat ditentukan dari waktu ke waktu dalam produksi, Anda dapat mengubah ukuran log selama siklus pemeliharaan hanya dalam hitungan menit.

Mesin InnoDB tidak menyimpan data yang dihapus. Saat Anda menyisipkan dan menghapus baris, ruang yang tidak digunakan dibiarkan dialokasikan dalam file penyimpanan InnoDB. Seiring waktu, ruang keseluruhan tidak akan berkurang, tetapi seiring waktu ruang 'dihapus dan dibebaskan' akan secara otomatis digunakan kembali oleh server DB.

Anda dapat lebih lanjut menyetel dan mengelola ruang yang digunakan oleh mesin melalui re-org manual dari tabel. Untuk melakukan ini, dump data di tabel yang terkena menggunakan mysqldump, letakkan tabel, restart layanan mysql, dan kemudian buat kembali tabel dari file dump.