Pemecahan masalah untuk Aurora Peningkatan di tempat saya SQL - Amazon Aurora

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pemecahan masalah untuk Aurora Peningkatan di tempat saya SQL

Gunakan tips berikut untuk membantu memecahkan masalah dengan peningkatan Aurora My in-place. SQL Tips ini tidak berlaku untuk Aurora Serverless klaster DB.

Alasan peningkatan di tempat dibatalkan atau lambat Efek Solusi untuk memungkinkan peningkatan di tempat selesai dalam periode pemeliharaan
Replika Lintas wilayah Aurora Terkait belum ditambal Aurora membatalkan peningkatan. Tingkatkan replika Aurora Cross-region dan coba lagi.
Klaster memiliki transaksi XA dalam status siap Aurora membatalkan peningkatan. Komit atau kembalikan semua transaksi XA yang disiapkan.
Cluster memproses pernyataan bahasa definisi data (DDL) apa pun Aurora membatalkan peningkatan. Pertimbangkan untuk menunggu dan melakukan peningkatan setelah semua DDL pernyataan selesai.
Klaster memiliki perubahan yang tidak dikomit untuk banyak baris Peningkatan mungkin memerlukan waktu lama.

Proses peningkatan mengembalikan perubahan yang tidak dikomit. Indikator untuk kondisi ini adalah nilai TRX_ROWS_MODIFIED dalam tabel INFORMATION_SCHEMA.INNODB_TRX.

Pertimbangkan untuk melakukan peningkatan hanya setelah semua transaksi besar dilakukan atau dikembalikan.
Klaster memiliki jumlah catatan undo yang tinggi Peningkatan mungkin memerlukan waktu lama.

Bahkan jika transaksi yang tidak dikomit tidak memengaruhi sejumlah besar baris, transaksi ini mungkin berkaitan dengan volume besar data. Misalnya, Anda mungkin memasukkan besarBLOBs. Aurora tidak akan secara otomatis mendeteksi atau menghasilkan peristiwa untuk jenis aktivitas transaksi ini. Indikator untuk kondisi ini adalah panjang daftar riwayat (HLL). Proses peningkatan mengembalikan perubahan yang tidak dikomit.

Anda dapat memeriksa HLL output dari SHOW ENGINE INNODB STATUS SQL perintah, atau langsung dengan menggunakan SQL query berikut:

SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

Anda juga dapat memantau RollbackSegmentHistoryListLength metrik di Amazon CloudWatch.

Pertimbangkan untuk melakukan upgrade hanya setelah HLL lebih kecil.
Klaster sedang dalam proses melakukan komit transaksi log biner besar Peningkatan mungkin memerlukan waktu lama.

Proses peningkatan menunggu sampai perubahan log biner diterapkan. Lebih banyak transaksi atau DDL pernyataan dapat dimulai selama periode ini, yang selanjutnya memperlambat proses peningkatan.

Jadwalkan proses peningkatan saat klaster tidak sibuk menghasilkan perubahan replikasi log biner. Aurora tidak akan secara otomatis mendeteksi atau membuat peristiwa untuk kondisi ini.
Inkonsistensi skema yang dihasilkan dari penghapusan atau kerusakan file Aurora membatalkan peningkatan.

Ubah mesin penyimpanan default untuk tabel sementara dari My ISAM ke InnoDB. Lakukan langkah-langkah berikut ini:

  1. Ubah parameter DB default_tmp_storage_engine menjadi InnoDB.

  2. Boot ulang klaster DB.

  3. Setelah boot ulang, konfirmasikan bahwa parameter DB default_tmp_storage_engine diatur ke InnoDB. Gunakan perintah berikut ini.

    show global variables like 'default_tmp_storage_engine';

  4. Pastikan untuk tidak membuat tabel sementara yang menggunakan mesin ISAM penyimpanan Saya. Kami menyarankan agar Anda menjeda beban kerja basis data apa pun dan tidak membuat koneksi basis data baru karena Anda akan segera melakukan peningkatan.

  5. Coba lagi peningkatan di tempat.
Pengguna master dihapus Aurora membatalkan peningkatan.
penting

Jangan hapus pengguna master.

Namun, jika karena alasan tertentu Anda kebetulan menghapus pengguna master, kembalikan menggunakan SQL perintah berikut:

CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, 
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, 
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;

Untuk detail selengkapnya tentang masalah pemecahan masalah yang menyebabkan precheck upgrade gagal, lihat blog berikut:

Anda dapat menggunakan langkah-langkah berikut untuk melakukan pemeriksaan Anda sendiri untuk beberapa kondisi di tabel sebelumnya. Dengan demikian, Anda dapat menjadwalkan peningkatan pada saat Anda mengetahui basis data dalam keadaan yang memungkinkan peningkatan berhasil diselesaikan dengan cepat.

  • Anda dapat memeriksa transaksi XA terbuka dengan menjalankan pernyataan XA RECOVER. Anda kemudian dapat meng-commit atau mengembalikan transaksi XA sebelum memulai peningkatan.

  • Anda dapat memeriksa DDL pernyataan dengan mengeksekusi SHOW PROCESSLIST pernyataan dan mencariCREATE,,DROP, ALTERRENAME, dan TRUNCATE pernyataan dalam output. Izinkan semua DDL pernyataan selesai sebelum memulai peningkatan.

  • Anda dapat memeriksa jumlah total baris yang tidak dikomit dengan mengueri tabel INFORMATION_SCHEMA.INNODB_TRX. Tabel ini berisi satu baris untuk setiap transaksi. Kolom TRX_ROWS_MODIFIED berisi jumlah baris yang diubah atau dimasukkan oleh transaksi.

  • Anda dapat memeriksa panjang daftar riwayat InnoDB dengan menjalankan pernyataan SHOW ENGINE INNODB STATUS SQL dan mencari History list length dalam output. Anda juga dapat memeriksa nilai secara langsung dengan menjalankan kueri berikut: 

    SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

    Panjang daftar riwayat sesuai dengan jumlah informasi undo yang disimpan oleh database untuk menerapkan kontrol konkurensi multi-versi (). MVCC