Pertama, kita akan memahami penyimpanan di RDS Aurora. Ada 2 jenis penyimpanan di Aurora. Toko instan adalah penyimpanan lokal tempat menyimpan objek sementara dan penyimpanan utama untuk data. Oleh karena itu, ketika Anda menjalankan ALTER di atas meja, itu akan menghasilkan tabel temp dan RDS aurora akan menggunakan penyimpanan instan untuk menyimpan tabel temp. Untuk instance Anda yang merupakan instance db.r3.large, ia memiliki penyimpanan lokal 1×32 GB, jadi jika objek sementara Anda pada instance menjadi lebih besar dari ukuran ini, Anda akan mendapatkan kesalahan “tabel penuh”. Selain itu, batas penyimpanan lokal berbeda dari total volume penyimpanan tersedia untuk instans Aurora Anda, dan berdasarkan penggunaan database Anda, volume penyimpanan Amazon Aurora Anda akan bertambah secara otomatis, hingga 64 TB, dalam peningkatan 10 GB.Mengapa masalah ini terjadi meskipun volume penyimpanan Amazon Aurora otomatis bertambah hingga 64 TB.?
Ubah di meja besar di RDS solusi untuk tabel penuh Kesalahan
- Untuk mengatasi masalah ini, Anda dapat meningkatkan skala instance untuk mendapatkan lebih banyak penyimpanan lokal untuk menjalankan ALTER Anda, ubah tabel, lalu perkecil jenis instance. Hal ini menyebabkan beberapa waktu henti saat jenis instans peningkatan/penurunan versi.
- Anda juga dapat menggunakan:perintah “pt-online-schema-change”, jika Anda menggunakan perintah ini akan membuat tabel asli tetap tersedia untuk digunakan tanpa downtime atau tidak ada kunci meja.
Hasil:
Jika Anda mengubah tabel dengan pt -online-schema-change perintah di sebuah meja yang berukuran 35-40GB maka akan memakan waktu sekitar 30 jam.pt-online-schema-change tidak mengunci meja. Perintah ini membuat pemicu pada tabel asli. Tetapi untuk ini, diperlukan hak pengguna super. ketika Anda menggunakan prosedur toko, Anda akan mendapatkan kesalahan:Mengapa menggunakan perintah pt-online-schema-change dan mengapa mengaktifkan “log_bin_trust_function_creators “ dalam grup parameter DB? ?
#1419 – Anda tidak memiliki hak SUPER dan pencatatan biner diaktifkan (Anda *mungkin* ingin menggunakan variabel log_bin_trust_function_creators yang kurang amanAlasan: Galat ini terjadi pada instans RDS saat Anda mencoba menggunakan "Prosedur tersimpan". Anda akan segera mengetahui bahwa memberikan hak istimewa super untuk pengguna tidak akan berfungsi. Jadi satu-satunya cara untuk membuat semuanya berfungsi adalah dengan menyetel log_bin_trust_function_creators ke 1. Sesuai dengan dokumen Percona: Intinya adalah membuat pemicu di server dengan log biner yang diaktifkan memerlukan pengguna dengan hak istimewa SUPER (yang tidak mungkin dilakukan di Amazon RDS). Pesan kesalahan menentukan solusi. Kita perlu mengaktifkan variabel dalam grup parameter DB " log_bin_trust_function_creators". Mengaktifkannya seperti mengatakan ke server: “Saya memercayai pemicu dan fungsi pengguna biasa, dan itu tidak akan menyebabkan masalah, jadi izinkan pengguna saya untuk membuatnya.” Karena fungsionalitas database tidak akan berubah, ini menjadi masalah mempercayai pengguna Anda. log_bin_trust_function_creators adalah variabel global yang dapat diubah secara dinamis. Mencoba menemukan detail lebih lanjut tentang "Super_priv", Saat Anda memeriksa izin pengguna di tabel pengguna database MySQL. Anda dapat melihat bahwa Super_priv tidak disetel untuk siapa pun kecuali pengguna rdsadmin.
MySQL> select User,Super_priv from user; +-----------+------------+ | User | Super_priv | +-----------+------------+ | rdsadmin | Y | | root | N | | dbuser | N | +-----------+------------+ 3 rows in set (0.00 sec)
Di sini "root" adalah pengguna Master dan "dbuser" adalah pengguna DB pengguna ini dibuat oleh kami dan pengguna "rdsadmin" secara otomatis dibuat oleh AWS yang kami tidak memiliki akses ke pengguna ini. rdsadmin Pengguna MySQL digunakan oleh Amazon untuk pekerjaan pemeliharaan dan manajemen.
Ini adalah akhir dari tutorial, cara Mengubah Tabel Besar di Solusi RDS menjadi Tabel Penuh Error.
