View a markdown version of this page

Pemecahan masalah untuk peningkatan di tempat Aurora MySQL - 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 peningkatan di tempat Aurora MySQL

Gunakan tips berikut untuk membantu memecahkan masalah terkait peningkatan di tempat Aurora MySQL. Tips ini tidak berlaku untuk klaster DB Aurora Serverless.

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.
Klaster sedang memproses pernyataan bahasa definisi data (DDL) Aurora membatalkan peningkatan. Pertimbangkan untuk menunggu dan melakukan peningkatan setelah semua pernyataan DDL 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 besar BLOBs. 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 dalam output dari perintah SQL SHOW ENGINE INNODB STATUS, atau langsung dengan menggunakan kueri SQL 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 peningkatan hanya setelah HLL menjadi 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. Transaksi atau pernyataan DDL lainnya dapat dimulai selama periode ini, sehingga akan makin 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 MyISAM menjadi 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 penyimpanan MyISAM. 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 pengguna master menggunakan perintah SQL 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 pernyataan DDL dengan menjalankan pernyataan SHOW PROCESSLIST dan mencari pernyataan CREATE, DROP, ALTER, RENAME, dan TRUNCATE dalam output. Tunggu semua pernyataan DDL 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 basis data untuk menerapkan kontrol konkurensi multiversi (MVCC).