PolarDB:Arsip dalam Format IBD

Versi yang berlaku

• MySQL 8.0.1 dengan revisi 8.0.1.1.51.2 atau lebih baru.

• Untuk menggunakan pengarsipan format IBD, buka Quota Center, temukan kuota berdasarkan Quota ID polardb_innodb_oss_enable, lalu klik Request di kolom Actions untuk mengaktifkan fitur tersebut.

Catatan penting

• Batasan baca/tulis dan transaksi (DML & DDL)

  • Dukungan DML dan transaksi: Tabel yang diarsipkan mendukung operasi DML normal seperti INSERT, UPDATE, dan DELETE, serta transaksi.

  • Batasan DDL: Operasi DDL tidak didukung. Setelah tabel diarsipkan ke OSS, Anda tidak dapat memodifikasi struktur tabel.

• Ketersediaan selama pengarsipan

  • Gangguan akses data: Secara default, data dalam tabel tidak dapat diakses selama proses pengarsipan berlangsung.

  • Solusi sementara: Untuk menjaga agar tabel tetap dapat dibaca selama pengarsipan, atur parameter polar_oss_ddl_shared menjadi ON terlebih dahulu.

• Pencadangan dan keamanan data

  • Tidak termasuk dalam pencadangan standar: Pencadangan otomatis dan manual tidak mencakup data yang disimpan di OSS.

  • Batasan pemulihan: Anda tidak dapat melakukan pemulihan database atau tabel maupun pemulihan pada titik waktu untuk data di OSS.

• Dampak performa dan rekomendasi O&M

  • Konsumsi resource selama pengarsipan: Pengarsipan data dingin mengonsumsi resource jaringan dan I/O penyimpanan. Kami merekomendasikan Anda melakukan operasi ini selama jam sepi atau pada kluster yang tidak aktif.

  • Risiko latensi tinggi: Latensi I/O OSS lebih dari 100 kali lipat dibandingkan penyimpanan blok. Evaluasi dampaknya terhadap kueri SQL berdurasi panjang.

  • Operasi tulis intensif: Sebelum menjalankan operasi tulis atau hapus intensif pada tabel OSS, pindahkan terlebih dahulu tabel tersebut kembali ke penyimpanan blok. Jika tidak, masalah berikut dapat terjadi:

    1. Polusi cache: Sejumlah besar resource kolam buffer database dikonsumsi, menyebabkan kueri SQL pada tabel lain melambat karena tidak dapat memperoleh halaman bebas.

    2. Pemblokiran checkpoint: Persistensi lambat dari banyak halaman kotor OSS menghambat kemajuan checkpoint, sehingga memperpanjang waktu pemulihan saat crash.

    3. Pemulihan crash lebih lambat: Selama pemulihan crash, replay log pada tabel OSS memicu operasi baca dan tulis OSS, yang semakin memperlambat pemulihan crash.

Arsipkan data tabel ke OSS

Ketika data dalam tabel merupakan data dingin dan tidak sensitif terhadap latensi, atau ketika akses data terkonsentrasi dan dapat di-cache dengan latensi ekor yang dapat diterima, ubah tabel penyimpanan blok menjadi tabel OSS menggunakan sintaks berikut:

ALTER TABLE table_name STORAGE_TYPE OSS;

Pindahkan data kembali ke penyimpanan blok

ALTER TABLE table_name STORAGE_TYPE NULL;

Hapus file terkait di OSS

Setelah Anda menghapus tabel OSS atau memindahkannya kembali ke penyimpanan blok, file terkait di OSS tidak dihapus secara otomatis. Setelah memastikan bahwa data tersebut tidak lagi diperlukan, gunakan sintaks berikut untuk menghapus file terkait di OSS:

CALL dbms_oss.delete_table_file('database_name', 'table_name');

Penghapusan file di OSS adalah operasi asinkron. Sistem menunggu hingga semua node dalam kluster tidak lagi bergantung pada file OSS sebelum file tersebut benar-benar dihapus. Selama periode trafik tinggi, beberapa latensi mungkin terjadi. Jika perintah gagal dan mengembalikan pesan error OSS files are still in use, tunggu sebentar lalu coba lagi.

Contoh

Contoh berikut mencakup operasi penghapusan tabel, penghapusan database, dan penghapusan file yang diarsipkan di OSS. Jalankan operasi tersebut dalam database uji.

1. Buat database.

   CREATE DATABASE oss;

2. Gunakan database.

   USE oss;

3. Buat tabel toss1.

   CREATE TABLE `toss1`(
     `uid` int NOT NULL AUTO_INCREMENT,
     `text_data` text NOT NULL,
     `save_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
     PRIMARY KEY(`uid`)
   ) ENGINE = InnoDB;

4. Buat prosedur tersimpan populate.

   DELIMITER |
   CREATE PROCEDURE populate(IN `cnt` INT)
   BEGIN
     DECLARE i INT DEFAULT 1;
     WHILE (i <= cnt) DO
       INSERT INTO `toss1` (`text_data`) VALUES (REPEAT("#", 6333));
       SET i = i + 1;
     END WHILE;
   END |
   DELIMITER ;

5. Panggil prosedur tersimpan untuk memasukkan data ke tabel toss1.

   CALL populate(5000);

6. Arsipkan data ke OSS.

   ALTER TABLE `toss1` STORAGE_TYPE OSS;

7. Kueri data dalam tabel toss1.

   SELECT COUNT(*) FROM `toss1`;

8. Hapus tabel toss1 di OSS.

   DROP TABLE `toss1`;

9. Hapus database OSS.

   DROP DATABASE oss;

10. Setelah memastikan bahwa data tidak lagi diperlukan, hapus file terkait di OSS.

    CALL dbms_oss.delete_table_file('oss', 'toss1');

Waktu yang dibutuhkan untuk pengarsipan data dingin

Jumlah thread konkuren yang digunakan untuk pengarsipan data dingin dikontrol oleh parameter innodb_oss_copy_worker, dan nilai parameter tersebut terikat pada spesifikasi kluster. Tabel berikut menunjukkan waktu yang dibutuhkan untuk pengarsipan data dingin dengan jumlah thread dan volume data berbeda:

Versi yang berlaku

• MySQL 8.0.2 dengan revisi 8.0.2.2.37 atau lebih baru. Tipe penyimpanan harus PSL4 atau PSL5. Disk cloud ESSD tidak didukung.

• Di konsol, buka Settings and Management > Parameters dan aktifkan parameter loose_polar_oss_enable.

• Tabel target menggunakan tablespace per tabel dan mesin penyimpanan InnoDB. Semua partisi tabel partisi harus menggunakan engine InnoDB. Tabel terkompresi dan ruang tabel umum tidak didukung.

• Jalankan operasi pengarsipan, kueri, dan pemindahan kembali pada node utama melalui Titik akhir utama, dan pastikan akun saat ini memiliki izin yang diperlukan pada tabel target.

Catatan penting

• Perilaku baca/tulis dan partisi (DML)

  • Dukungan DML dan transaksi: Tabel dan partisi yang diarsipkan tetap dapat ditulis. Operasi INSERT, UPDATE, dan DELETE serta transaksi didukung.

  • Perilaku spesifik partisi:

    • Kueri: Partisi yang diarsipkan secara otomatis dilewati secara default.

    • Pembaruan dan penghapusan: Operasi UPDATE dan DELETE tidak melewatkan partisi yang diarsipkan. Sebelum menjalankan operasi ini, verifikasi cakupan dampaknya untuk menghindari modifikasi tidak disengaja atau backlog permintaan akibat latensi OSS.

• Dukungan perubahan skema (aturan DDL)

  • Kemampuan DDL: Operasi DDL umum didukung, seperti menambah kolom, membuat indeks, dan menyesuaikan partisi (tunduk pada batasan InnoDB).

  • Pewarisan status pengarsipan: Status pengarsipan secara otomatis dipertahankan atau disesuaikan seiring perubahan skema. Namun, setelah Anda mengatur ulang partisi, kami merekomendasikan Anda memverifikasi secara manual status pengarsipan setiap partisi.

  • Batasan sintaks (tidak ada penggabungan):

    • Operasi pengarsipan dan pemindahan kembali harus dijalankan secara terpisah. Operasi tersebut tidak dapat digabungkan dengan perubahan skema lain (seperti menambah kolom atau mengubah tipe data) dalam satu pernyataan ALTER TABLE.

    • Saat menjalankan operasi pengarsipan dan pemindahan kembali, Anda tidak dapat secara eksplisit menentukan ALGORITHM=COPY atau ALGORITHM=INSTANT. Batasan ini hanya berlaku untuk operasi pengarsipan itu sendiri dan tidak memengaruhi operasi DDL COPY biasa pada tabel yang diarsipkan.

• Batasan kompresi tabel dan tablespace

  Sebelum melakukan operasi berikut, Anda harus terlebih dahulu memindahkan data tabel atau partisi terkait kembali dari OSS ke penyimpanan blok. Operasi pemindahan kembali tidak mengubah mesin penyimpanan InnoDB tabel tersebut.

  • Aktifkan kompresi tabel: ROW_FORMAT=COMPRESSED dan kompresi halaman tidak didukung dalam keadaan diarsipkan. Pindahkan data kembali sebelum mengaktifkan kompresi.

  • Pindahkan ke ruang tabel umum: Ruang tabel umum memungkinkan beberapa tabel berbagi file data yang sama. Pengarsipan OSS mengharuskan setiap tabel atau partisi menggunakan file .ibd independen. Oleh karena itu, tabel dalam ruang tabel umum tidak didukung untuk pengarsipan. Pindahkan data kembali sebelum memindahkan tabel yang diarsipkan ke ruang tabel umum.

  • Impor atau buang tablespace: Sebelum menjalankan IMPORT TABLESPACE (impor file tablespace) atau DISCARD TABLESPACE (buang tablespace yang digunakan tabel), pindahkan data kembali terlebih dahulu. DISCARD TABLESPACE bukanlah operasi pemindahan kembali dan tidak dapat digunakan untuk memindahkan data kembali ke penyimpanan blok.

• Enkripsi Data Transparan (TDE)

  • TDE didukung sepenuhnya. Operasi pengarsipan dan pemindahan kembali tidak mengubah properti enkripsi yang ada pada tabel.

  • Untuk memodifikasi properti enkripsi, gunakan algoritma default atau tentukan secara eksplisit ALGORITHM=COPY. ALGORITHM=INPLACE tidak didukung.

• Pencadangan, keamanan, dan rekomendasi O&M

  • Pengarsipan bukan pencadangan: Operasi DROP dan TRUNCATE menghapus atau mengosongkan data di OSS secara fisik. Jangan gunakan pengarsipan sebagai alternatif pencadangan.

  • Pemblokiran konkurensi dan konsumsi resource: Operasi pengarsipan dan pemindahan kembali mengunci tabel target, yang dapat memblokir baca/tulis konkuren dan mengonsumsi resource jaringan serta I/O penyimpanan. Kami merekomendasikan Anda menjalankan operasi ini selama jam sepi.

  • Rekomendasi modifikasi massal: Karena latensi akses OSS lebih tinggi daripada penyimpanan blok, kami merekomendasikan Anda memindahkan data yang diarsipkan kembali ke penyimpanan blok sebelum melakukan modifikasi massal.

Arsipkan data tabel ke OSS

Pengarsipan cocok untuk data yang jarang diakses dan tidak sensitif terhadap latensi. Menentukan CREATE TABLE dengan STORAGE_TYPE tidak secara otomatis mengarsipkan tabel yang baru dibuat. Buat tabel terlebih dahulu, lalu jalankan operasi pengarsipan:

ALTER TABLE table_name STORAGE_TYPE=HYBRID_OSS;

Sintaks ini juga berlaku untuk tabel partisi. Setelah pernyataan dieksekusi, semua partisi dalam tabel tersebut diarsipkan.

Arsipkan partisi tertentu ke OSS

-- Arsipkan satu partisi.
ALTER TABLE table_name MODIFY PARTITION p0 STORAGE_TYPE=HYBRID_OSS;

-- Arsipkan beberapa partisi.
ALTER TABLE table_name MODIFY PARTITION p0, p1 STORAGE_TYPE=HYBRID_OSS;

Arsipkan seluruh tabel jika semua data dalam tabel merupakan data dingin. Arsipkan hanya partisi tertentu jika hanya beberapa partisi yang berisi data dingin. Jangan mengarsipkan partisi yang sama lebih dari sekali. Jika tabel berisi subpartisi, Anda dapat menentukan nama subpartisi. Jika Anda menentukan nama partisi induk, semua subpartisi di bawah partisi induk tersebut akan diarsipkan.

Kueri data yang diarsipkan

Tabel reguler yang diarsipkan dapat dikueri secara langsung seperti sebelum pengarsipan. Tabel partisi secara default hanya mengkueri partisi yang tidak diarsipkan. Untuk menyertakan partisi yang diarsipkan dalam kueri, tambahkan WITH ARCHIVED ke pernyataan, atau nonaktifkan filter partisi yang diarsipkan untuk session saat ini.

• Kueri tunggal: Tambahkan WITH ARCHIVED setelah nama tabel. Ini hanya berlaku untuk pernyataan yang mencakup klausa ini dan cocok untuk kueri data yang diarsipkan satu kali:

  -- Kueri partisi yang tidak diarsipkan.
  SELECT * FROM table_name;
  
  -- Kueri data, termasuk partisi yang diarsipkan.
  SELECT * FROM table_name WITH ARCHIVED;

• Session saat ini: Setelah Anda menonaktifkan filter partisi yang diarsipkan untuk session saat ini, kueri biasa akan menyertakan partisi yang diarsipkan. Metode ini berlaku untuk seluruh session saat ini dan cocok untuk skenario di mana Anda perlu terus-menerus mengkueri data yang diarsipkan:

  SET SESSION prune_archived_oss_partitions=OFF;

  Nilai default parameter prune_archived_oss_partitions adalah ON. Setelah Anda mengaturnya menjadi OFF, kueri tetap menyaring data berdasarkan kondisi WHERE dan aturan partisi normal. Untuk mengembalikan perilaku default, atur parameter ini menjadi ON.

Periksa status pengarsipan

SHOW CREATE TABLE table_name;

Dalam output, jika tabel atau partisi berisi STORAGE_TYPE=HYBRID_OSS, objek tersebut telah diarsipkan.

Pindahkan data kembali ke penyimpanan blok

Operasi pemindahan kembali mempertahankan data bisnis Anda dan membatalkan status pengarsipan tabel atau partisi terkait.

-- Pindahkan kembali tabel reguler. Untuk tabel partisi, semua partisi yang diarsipkan dipindahkan kembali.
ALTER TABLE table_name STORAGE_TYPE=NULL;

-- Pindahkan kembali hanya partisi tertentu.
ALTER TABLE table_name MODIFY PARTITION p0 STORAGE_TYPE=NULL;

-- Pindahkan kembali semua partisi yang diarsipkan.
ALTER TABLE table_name MODIFY PARTITION ALL STORAGE_TYPE=NULL;

Gunakan pernyataan pertama ketika Anda perlu memulihkan seluruh tabel atau semua partisi yang diarsipkan dari tabel partisi. Gunakan MODIFY PARTITION untuk menentukan partisi ketika Anda hanya perlu memulihkan partisi individual. Partisi yang ditentukan harus dalam keadaan diarsipkan. Saat Anda menggunakan ALL, semua partisi yang saat ini diarsipkan dipilih.

Contoh

Contoh berikut menunjukkan operasi pada tabel reguler dan tabel partisi. Jalankan contoh tersebut dalam database uji. Contoh ini menggunakan jumlah data kecil untuk mendemonstrasikan operasi. Ruang penyimpanan aktual yang dihemat tergantung pada ukuran tabel.