Mendiagnosis masalah untuk MySQL

MySQL   |  PostgreSQL   |  PostgreSQL ke AlloyDB

Memecahkan masalah error

Proses tugas migrasi mungkin mengalami error selama runtime.

• Beberapa error, seperti sandi yang salah di database sumber, dapat dipulihkan, yang berarti error tersebut dapat diperbaiki dan tugas migrasi dilanjutkan secara otomatis.
• Beberapa error tidak dapat dipulihkan, seperti posisi binlog yang hilang, yang berarti tugas migrasi harus dimulai ulang dari awal.

Saat error terjadi, status tugas migrasi akan berubah menjadi Failed, dan substatus mencerminkan status terakhir sebelum kegagalan.

Untuk memecahkan masalah error, buka tugas migrasi yang gagal untuk melihat error dan ikuti langkah-langkah yang diuraikan dalam pesan error.

Untuk melihat detail selengkapnya tentang error, buka Cloud Monitoring menggunakan link di tugas migrasi. Log difilter ke tugas migrasi tertentu.

Dalam tabel berikut, Anda dapat menemukan beberapa contoh masalah dan cara mengatasinya:

Untuk masalah ini...	Kemungkinan masalah...	Coba langkah ini...
Setelan database tujuan berbeda dengan konfigurasi Terraform yang digunakan untuk menyediakan database. (Masalah ini juga terkadang disebut sebagai penyimpangan konfigurasi.)	Saat Anda bermigrasi ke database tujuan yang ada, Layanan Migrasi Database akan mengubah setelan tertentu dari database tujuan untuk menjalankan tugas migrasi.	Anda perlu menerapkan kembali setelan yang digunakan dalam konfigurasi Terraform setelah mempromosikan tugas migrasi. Lihat Drift konfigurasi Terraform.
Pesan error: Error processing table {table_name}: MySQL Error 1118 (42000): Row size too large (>8126).	Tabel yang menggunakan kolom VARCHAR mungkin memiliki baris yang melebihi ukuran maksimum yang diizinkan oleh InnoDB (mesin penyimpanan default yang digunakan di MySQL).	Anda dapat berhenti memblokir tugas migrasi dengan mengonversi kolom ke BLOB atau TEXT, atau dengan menetapkan flag innodb_strict_mode ke off untuk sementara. Lihat Error 1118: ukuran baris terlalu besar.
Tugas migrasi gagal selama fase dump penuh dengan pesan error berikut: ERROR 1064 (42000) at {line_number}: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near {reserved_word} at {line_number}.	Masalah ini terjadi saat melakukan migrasi antar-versi MySQL. Entitas dalam versi MySQL sumber Anda mungkin menggunakan kata yang tidak diizinkan di versi MySQL yang ingin Anda migrasikan. Misalnya, di MySQL 5.7, Anda dapat menggunakan kata function dalam nama kolom. Namun, di MySQL 8.0, function adalah kata yang dicadangkan, sehingga database tujuan tidak dapat mengurai sumber Anda.	Ganti nama objek database sumber yang dirujuk dalam pesan error atau masukkan dalam tanda petik terbalik (``) untuk meng-escape sintaksis. Setelah selesai, coba lagi tugas migrasi.
Pesan error: ERROR 1109 (42S02): Unknown table in <schema name here>	Database Migration Service tidak memigrasikan skema sistem mysql, performance_schema, information_schema, ndbinfo, atau sys. Tugas migrasi Anda mungkin gagal jika database sumber berisi objek yang mereferensikan tabel dari salah satu skema ini.	Periksa database sumber Anda untuk menemukan objek yang mereferensikan tabel yang terdapat dalam skema sistem yang tidak dimigrasikan. Lihat ERROR 1109 (42S02): Tabel tidak dikenal di <schema name here>.
Pesan error: Unknown table 'COLUMN_STATISTICS' in information_schema (1109)	Relevan untuk skenario dump database manual dengan mysqldump saja. Database MySQL dalam versi yang lebih lama dari 8 tidak memiliki tabel COLUMN_STATISTICS. Utilitas mysqldump dalam versi 8 dan yang lebih baru mencoba mengekspor tabel ini secara default. Ekspor gagal karena kolom tidak ada.	Gunakan flag --column-statistics=0 saat menggunakan mysqldump.
Pesan error: Specified key was too long; max key length is 767 bytes.	Instance database sumber mungkin memiliki variabel innodb_large_prefix yang telah disetel.	Tetapkan flag innodb_large_prefix ke ON saat membuat instance tujuan, atau perbarui instance tujuan yang ada dengan flag tersebut.
Pesan error: Table definition has changed.	Ada perubahan bahasa definisi data (DDL) selama proses pembuangan.	Hindari perubahan DDL selama proses dump.
Pesan error: Access denied; you need (at least one of) the SUPER privilege(s) for this operation.	Mungkin ada peristiwa, tampilan, fungsi, atau prosedur dalam database sumber yang menggunakan super user@localhost (seperti root@localhost). Hal ini tidak didukung oleh Cloud SQL.	Lihat informasi selengkapnya tentang penggunaan DEFINER di Cloud SQL.
Pesan error: Definer user 'x' does not exist. Please create the user on the replica.	Pengguna tidak ada di replika.	Lihat informasi selengkapnya tentang penggunaan DEFINER di Cloud SQL.
Pesan error: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost.	Ada DEFINER di database sumber yang tidak ada di replika.	Lihat informasi selengkapnya tentang penggunaan DEFINER di Cloud SQL.
Pesan error: Lost connection to MySQL server during query when dumping table.	Database sumber mungkin tidak dapat dijangkau, atau file dump berisi paket yang terlalu besar.	Coba saran ini.
Pesan error: Got packet bigger than 'max_allowed_packet' bytes when dumping table.	Paket tersebut lebih besar dari yang diizinkan oleh setelan.	Gunakan dump manual dengan opsi max_allowed_packet.
Migrasi data awal berhasil, tetapi tidak ada data yang direplikasi.	Mungkin ada flag replikasi yang bentrok.	Periksa setelan tanda ini.
Migrasi data awal berhasil, tetapi replikasi data berhenti berfungsi setelah beberapa saat.	Ada banyak penyebabnya.	Coba saran berikut.
Pesan error: mysqld check failed: data disk is full.	Disk data instance tujuan penuh.	Tingkatkan ukuran disk instance tujuan. Anda dapat meningkatkan ukuran disk secara manual atau mengaktifkan peningkatan penyimpanan otomatis.
Gagal terhubung ke instance database sumber.	Terjadi masalah konektivitas antara instance database sumber dan instance tujuan.	Ikuti langkah-langkah di artikel proses debug konektivitas.
Migrasi dari database terkelola (Amazon RDS/Aurora) tidak dimulai.	Memigrasikan dari database sumber terkelola tanpa hak istimewa SUPERUSER memerlukan periode nonaktif singkat di awal migrasi.	Ikuti langkah-langkah dalam artikel ini.
Binlog tidak dikonfigurasi dengan benar di database sumber.	Definisi Binlog salah.	Untuk tugas migrasi MySQL berkelanjutan, pastikan Anda mengikuti definisi binlog yang diperlukan.
Gagal menemukan file dump.	DMS tidak dapat menemukan file dump yang diberikan.	Hal ini dapat terjadi jika tugas migrasi tidak dapat menemukan file dump di lokasi yang ditentukan. Periksa jalur dump untuk memastikan file yang tepat ada, atau ubah jalurnya. Jika Anda mengubah jalur, gunakan permintaan PATCH untuk memastikan tugas menggunakannya. Mulai ulang tugas migrasi.
Tidak dapat melanjutkan replikasi karena posisi binlog hilang.	Posisi binlog hilang dan tugas migrasi tidak dapat dilanjutkan.	Error ini dapat terjadi saat proses replikasi dijeda untuk waktu yang lama, yang menyebabkan posisi binlog hilang. Tugas migrasi tidak boleh dijeda selama jangka waktu yang mendekati periode retensi binlog. Mulai ulang tugas migrasi.
Saat memigrasikan ke instance tujuan yang ada, Anda akan menerima pesan error berikut: The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job.	Instance Cloud SQL tujuan Anda berisi data tambahan. Anda hanya dapat bermigrasi ke instance yang sudah ada dan kosong. Lihat Batasan umum.	Promosikan instance tujuan Anda untuk menjadikannya instance baca/tulis, hapus data tambahan, dan coba lagi tugas migrasi. Lihat Menghapus data tambahan dari instance tujuan yang ada.
Kegagalan menjalankan tugas migrasi karena versi database sumber dan tujuan tidak kompatibel.	Versi database sumber yang diberikan tidak kompatibel dengan versi database tujuan.	Pastikan versi database tujuan sama atau satu versi utama di atas versi tujuan sumber, lalu buat tugas migrasi baru.
Pesan Error: Unable to connect to source database server.	Layanan Migrasi Database tidak dapat membuat koneksi ke server database sumber.	Pastikan instance database sumber dan tujuan dapat berkomunikasi satu sama lain, dan bahwa Anda telah menyelesaikan semua prasyarat yang diperlukan yang muncul saat Anda menentukan setelan untuk tugas migrasi.
Pesan Error: Timeout waiting for no write traffic on source.	Memigrasikan dari database sumber terkelola tanpa hak istimewa SUPERUSER akan menyebabkan periode nonaktif singkat selama awal migrasi.	Ikuti langkah-langkah di Melakukan migrasi dari RDS MySQL tanpa hak istimewa SUPERUSER.
Pesan Error: ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist.	Mungkin ada inkonsistensi antara nilai flag lower_case_table_names untuk database sumber dan nilai flag untuk instance Cloud SQL tujuan.	Tetapkan nilai flag untuk instance Cloud SQL agar cocok dengan nilai flag untuk database sumber.
Pesan Error: ERROR 1109 (42S02) at line {line_number}: Unknown table '{table}' in {database}.	Beberapa objek di database sumber, seperti tampilan, fungsi, prosedur tersimpan, atau pemicu, mereferensikan tabel yang tidak ada lagi di database.	Periksa apakah objek ini ada. Jika ya, hapus objek dari database sumber atau tambahkan tabel yang dirujuk objek ke database sumber.
Pesan Error: ERROR 1045: Access denied for user '{user_name}'@'{replica_IP}' (using password: YES)". Check if MySQL replication user and password are correct. Not attempting further retries.	Anda memberikan sandi yang salah untuk instance sumber. Atau, instance sumber memaksa koneksi SSL; tetapi, tugas migrasi tidak dikonfigurasi untuk menggunakan sertifikasi SSL.	Konfirmasi apakah setelan nama pengguna, sandi, dan SSL sudah benar untuk instance sumber dengan menggunakan klien mysql. Jika instance sumbernya adalah Cloud SQL, lihat Mewajibkan SSL/TLS untuk memverifikasi apakah SSL/TLS diperlukan untuk koneksi TCP.
Jeda replikasi selalu tinggi.	Beban tulis terlalu tinggi untuk ditangani replika. Kelambatan replikasi terjadi saat thread Cloud SQL untuk MySQL pada replika tidak dapat mengimbangi thread I/O. Beberapa jenis kueri atau beban kerja dapat menyebabkan kelambatan replikasi tinggi yang bersifat sementara atau permanen untuk skema tertentu. Beberapa penyebab umum kelambatan replikasi adalah: Kueri lambat dilakukan pada replika. Temukan dan perbaiki. Semua tabel harus memiliki kunci utama yang unik. Setiap pembaruan pada tabel tersebut yang tidak memiliki kunci ini akan menyebabkan pemindaian tabel penuh pada replika. Kueri seperti DELETE ... WHERE field < 50000000 menyebabkan kelambatan replikasi dengan replikasi berbasis baris karena sejumlah besar update tertumpuk di replika.	Beberapa kemungkinan solusinya mencakup: Konfigurasikan replikasi paralel jika replika adalah MySQL versi 5.7 (atau yang lebih baru). Tetapkan flag innodb_flush_log_at_trx_commit pada replika ke 2. Lihat Tips untuk menggunakan flag untuk mengetahui informasi selengkapnya tentang flag ini. Edit instance Cloud SQL untuk MySQL untuk meningkatkan ukuran replika. Mengurangi beban pada database sumber. Buat indeks tabel di replika untuk setiap tabel yang tidak memiliki kunci utama yang unik. Membuat indeks tabel di database sumber. Tindakan ini memerlukan memulai ulang tugas migrasi. Identifikasi dan perbaiki kueri yang lambat di database sumber.
Pesan Error: 'Character set '#255' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file' on query.	Database sumber mungkin menggunakan set karakter atau pengurutan yang tidak didukung oleh replika Cloud SQL yang dipilih. Salah satu contohnya adalah AWS Aurora versi 2.x, yang kompatibel dengan MySQL 5.7. Namun, versi ini mendukung pengurutan utf8mb4_0900_as_ci, yang tidak didukung di Cloud SQL untuk MySQL 5.7.	Jika migrasi gagal selama fase pembuangan penuh, periksa definisi tabel sumber jika set karakter atau pengurutan yang tidak didukung digunakan. Jika memungkinkan, perbarui ke set karakter atau pengurutan yang didukung. Jika migrasi gagal selama fase CDC, periksa status replika, temukan binlog yang menyebabkan migrasi gagal, dan periksa database dan aplikasi sumber untuk menemukan pernyataan SQL yang menggunakan set karakter atau pengurutan. Jika memungkinkan, perbarui ke set karakter atau pengurutan yang didukung.

Error 1108: ukuran baris terlalu besar

Tabel dengan kolom yang menyimpan string panjang variabel dapat memiliki baris yang melebihi ukuran baris maksimum InnoDB default.

Hal-hal yang sebaiknya dicoba

Menyesuaikan skema tabel sumber

Masalah ini dapat terjadi lagi setiap kali Anda menjalankan pernyataan INSERT ke dalam tabel yang melebihi batas baris ukuran maksimum. Untuk menghindari masalah di masa mendatang, sebaiknya sesuaikan tabel sebelum mencoba ulang migrasi:

• Ubah tabel ROW_FORMAT menjadi DYNAMIC atau COMPRESSED dengan menjalankan kueri berikut:

  ALTER TABLE TABLE_NAME ROW_FORMAT=FORMAT_NAME;
    

  Lokasi:
  • TABLE_NAME adalah nama tabel yang barisnya melebihi batas ukuran baris maksimum
  • FORMAT_NAME adalah DYNAMIC atau COMPRESSED
  Misalnya:

  ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
    

• Mengonversi data baris menjadi BLOB atau TEXT. Salah satu cara untuk melakukan operasi ini adalah dengan fungsi CONVERT().

Menonaktifkan mode ketat InnoDB

Jika tidak dapat menyesuaikan skema tabel sumber, Anda dapat menonaktifkan validasi InnoDB untuk sementara guna menyelesaikan tugas migrasi. Perhatikan bahwa masalah ini dapat terjadi lagi selama upaya operasi tulis database pada masa mendatang, jadi sebaiknya sesuaikan skema tabel Anda jika memungkinkan.

Untuk menonaktifkan validasi InnoDB untuk sementara guna menyelesaikan tugas migrasi, ikuti langkah-langkah berikut:

Jika...	Lalu...
Jika Anda bermigrasi ke instance tujuan baru	Buat ulang tugas migrasi Anda. Di akhir langkah Menentukan tujuan, klik Tampilkan konfigurasi opsional. Di bagian Flags, pilih tanda innodb_strict_mode dan tetapkan ke Off. Setelah migrasi selesai, tetapkan tanda innodb_strict_mode ke On. Lihat Mengonfigurasi flag database dalam dokumentasi Cloud SQL untuk MySQL.
Jika Anda bermigrasi ke instance tujuan yang ada	Di Cloud SQL, buka instance tujuan dan tetapkan flag innodb_strict_mode ke Off. Lihat Mengonfigurasi flag database dalam dokumentasi Cloud SQL untuk MySQL. Buat ulang tugas migrasi Anda. Setelah migrasi selesai, tetapkan tanda innodb_strict_mode ke On. Lihat Mengonfigurasi flag database dalam dokumentasi Cloud SQL untuk MySQL.

---

Menghapus data tambahan dari instance tujuan yang ada

Saat memigrasikan ke instance tujuan yang ada, Anda akan menerima pesan error berikut: The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job.

Masalah ini dapat terjadi jika instance tujuan Anda berisi data tambahan. Anda hanya dapat bermigrasi ke instance yang sudah ada dan kosong. Lihat Batasan umum.

Hal-hal yang sebaiknya dicoba

Hapus data tambahan dari instance tujuan dan mulai lagi tugas migrasi dengan melakukan langkah-langkah berikut:

1. Hentikan tugas migrasi.
2. Pada tahap ini, instance Cloud SQL tujuan Anda berada dalam mode read-only. Promosikan instance tujuan untuk mendapatkan akses tulis.
3. Hubungkan ke instance Cloud SQL tujuan Anda.
4. Hapus data tambahan dari database instance tujuan Anda. Tujuan Anda hanya dapat berisi data konfigurasi sistem. Database tujuan tidak boleh berisi data pengguna (seperti tabel). Ada berbagai pernyataan SQL yang dapat Anda jalankan di database untuk menemukan data non-sistem, misalnya:

   SELECT schema_name FROM information_schema.SCHEMATA
   WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
     

5. Mulai tugas migrasi.

---

Drift konfigurasi Terraform

Saat Anda bermigrasi ke database tujuan yang ada, Layanan Migrasi Database akan mengubah setelan tertentu dari database tujuan untuk menjalankan tugas migrasi. Untuk database yang disediakan dengan Terraform, interaksi ini dapat menyebabkan drift konfigurasi saat konfigurasi database tujuan sebenarnya berbeda dengan konfigurasi yang ditetapkan dalam file Terraform Anda.

Hal-hal yang sebaiknya dicoba

Jangan mencoba menerapkan ulang konfigurasi Terraform saat tugas migrasi sedang berjalan. Anda dapat menyesuaikan konfigurasi yang diperlukan dengan aman setelah database tujuan dipromosikan. Database Migration Service melakukan perubahan berikut pada instance Cloud SQL tujuan Anda:

• Konfigurasi pencadangan ditetapkan ke nilai default.
• Pemulihan point-in-time direset ke nilai default.

Anda dapat mengalami drift konfigurasi jika konfigurasi Terraform Anda berisi setelan untuk salah satu fitur ini. Jika Anda perlu memperbaiki konfigurasi database tujuan, tunggu hingga tugas migrasi selesai dan database tujuan dipromosikan. Kemudian, lakukan langkah-langkah berikut: 1. Jalankan perintah `terraform plan` untuk melihat pratinjau modifikasi Anda. 1. Jalankan perintah `terraform apply` untuk menyesuaikan kembali setelan database tujuan Anda.

---

ERROR 1109 (42S02): Tabel tidak dikenal di <schema name here>

Tugas migrasi gagal dengan pesan berikut: ERROR 1109 (42S02): Unknown table in <schema name here> , misalnya: ERROR 1109 (42S02) at line X: Unknown table 'GLOBAL_STATUS' in information_schema.

Masalahnya mungkin adalah

Database Migration Service tidak memigrasikan skema sistem mysql, performance_schema, information_schema, ndbinfo, atau sys (lihat Batasan yang diketahui). Tugas migrasi Anda mungkin gagal jika database sumber berisi objek yang mereferensikan tabel dari salah satu skema ini.

Hal-hal yang sebaiknya dicoba

Periksa database sumber Anda untuk menemukan objek yang mereferensikan tabel dari skema sistem. Di database sumber, jalankan kueri berikut:

# Query to check routines or functions definitions.
SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND ROUTINE_DEFINITION like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%'

# Query to check view definitions.
SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND view_definition like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%'

# Query to check trigger definitions.
SELECT TRIGGER_SCHEMA, TRIGGER_NAME FROM information_schema.TRIGGERS
WHERE TRIGGER_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND event_object_table = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'

# Query to check constraint definitions.
SELECT TABLE_SCHEMA, TABLE_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND REFERENCED_TABLE_NAME = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'

Jika kueri ini menampilkan hasil, pertimbangkan untuk menghapus objek kode yang relevan dan lakukan migrasi lagi.

---

Tabel 'COLUMN_STATISTICS' yang tidak diketahui dalam information_schema

Saat menjalankan utilitas mysqldump versi 8 atau yang lebih baru untuk mengekspor versi database MySQL yang lebih lama dari 8, Anda akan mengalami error ini: Unknown table 'COLUMN_STATISTICS' in information_schema (1109).

Masalahnya mungkin adalah

Database MySQL dalam versi yang lebih lama dari 8 tidak memiliki tabel COLUMN_STATISTICS. Utilitas mysqldump dalam versi 8 dan yang lebih baru mencoba mengekspor tabel ini secara default. Ekspor gagal karena kolom tidak ada.

Hal-hal yang sebaiknya dicoba

Tambahkan flag --column-statistics=0 ke perintah mysqldump untuk menghapus tabel COLUMN_STATISTICS dari ekspor. Untuk informasi selengkapnya, lihat Mengekspor database MySQL menggunakan mysqldump.

---

Kunci yang ditentukan terlalu panjang; panjang maksimal kunci adalah 767 byte

Anda melihat error Specified key was too long; max key length is 767 bytes.

Masalahnya mungkin adalah

Database sumber mungkin memiliki variabel innodb_large_prefix yang ditetapkan. Hal ini memungkinkan awalan kunci indeks lebih dari 767 byte. Nilai defaultnya adalah OFF untuk MySQL 5.6.

Hal-hal yang sebaiknya dicoba

Tetapkan flag innodb_large_prefix ke ON saat membuat database tujuan, atau perbarui database tujuan yang ada dengan flag tersebut.

---

Definisi tabel telah berubah

Anda melihat error Table definition has changed.

Masalahnya mungkin adalah

Terjadi perubahan DDL selama proses dump.

Hal-hal yang sebaiknya dicoba

Jangan ubah tabel atau lakukan perubahan DDL lainnya selama proses dump.Anda dapat menggunakan skrip untuk memverifikasi bahwa operasi DDL dihentikan.

---

Akses ditolak; Anda memerlukan (setidaknya salah satu) hak istimewa SUPER untuk operasi ini

Anda melihat error Access denied; you need (at least one of) the SUPER privilege(s) for this operation.

Masalahnya mungkin adalah

Mungkin ada peristiwa, tampilan, fungsi, atau prosedur dalam database sumber yang menggunakan super user@localhost (seperti root@localhost). Hal ini tidak didukung oleh Cloud SQL.

Hal-hal yang sebaiknya dicoba

Lihat dokumen ini tentang memigrasikan database dengan klausa DEFINER.

---

Pesan error: Definer user 'x' does not exist. Please create the user on the replica.

Anda melihat error Definer user 'x' does not exist. Please create the user on the replica.

Masalahnya mungkin adalah

Penyebab utamanya adalah pengguna di database sumber dengan klausa DEFINER tidak ada di database replika.

Hal-hal yang sebaiknya dicoba

Lihat dokumen ini tentang memigrasikan database dengan klausa DEFINER. Anda mungkin perlu membuat pengguna di database replika.

---

Pesan error: ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost

Anda melihat error ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost.

Masalahnya mungkin adalah

Penyebab utamanya adalah pengguna di database sumber dengan klausa DEFINER tidak ada di database replika dan pengguna tersebut di-cross-reference dalam definisi objek di database sumber.

Hal-hal yang sebaiknya dicoba

Lihat dokumen ini tentang memigrasikan database dengan klausa DEFINER. Anda mungkin perlu membuat satu atau beberapa pengguna di database replika.

---

Koneksi ke server MySQL terputus selama kueri saat membuang tabel

Anda melihat error Lost connection to MySQL server during query when dumping table.

Masalahnya mungkin adalah

• Instance database sumber mungkin tidak dapat dijangkau dari instance tujuan.
• Database sumber mungkin memiliki tabel dengan blob besar atau string panjang yang memerlukan penetapan max_allowed_packet ke angka yang lebih besar di database sumber.

Hal-hal yang sebaiknya dicoba

• Pastikan instance database sumber aktif dan dapat dijangkau.
• Konfigurasi flag max-allowed-packet dalam tugas migrasi, lalu mulai ulang tugas migrasi. Atau, buat dump manual dengan opsi max_allowed_packet untuk membuang data dan bermigrasi dengan file dump.
• Meningkatkan max_allowed_packet kemungkinan besar akan memerlukan penyesuaian setelan net_read_timeout dan net_write_timeout di database sumber (umumnya harus ditingkatkan hingga error koneksi berhenti).

---

Mendapatkan paket yang lebih besar dari byte 'max_allowed_packet' saat membuang tabel

Anda melihat error Got packet bigger than 'max_allowed_packet' bytes when dumping table.

Masalahnya mungkin adalah

Paket tersebut lebih besar dari yang diizinkan oleh setelan.

Hal-hal yang sebaiknya dicoba

Buat tugas migrasi menggunakan dump manual dengan opsi max_allowed_packet untuk melakukan dump data dan bermigrasi dengan file dump.

---

Tidak ada data yang direplikasi

Migrasi data awal berhasil, tetapi tidak ada data yang direplikasi.

Masalahnya mungkin adalah

Kemungkinan penyebab utamanya adalah database sumber Anda memiliki flag replikasi yang menyebabkan beberapa atau semua perubahan database tidak direplikasi.

Hal-hal yang sebaiknya dicoba

Pastikan tanda replikasi seperti binlog-do-db, binlog-ignore-db, replicate-do-db, atau replicate-ignore-db tidak ditetapkan dengan cara yang bertentangan.
Jalankan perintah show master status di database sumber untuk melihat setelan saat ini.

---

Migrasi data awal berhasil, tetapi replikasi data berhenti berfungsi setelah beberapa saat

Migrasi data awal berhasil, tetapi replikasi data berhenti berfungsi setelah beberapa saat.

Masalahnya mungkin adalah

Ada banyak penyebab utama masalah ini.

Hal-hal yang sebaiknya dicoba

• Periksa metrik replikasi untuk instance tujuan Anda di UI Cloud Monitoring.
• Error dari thread IO MySQL atau thread SQL dapat ditemukan di Cloud Logging dalam file log mysql.err.
• Error ini juga dapat ditemukan saat menghubungkan ke instance tujuan. Jalankan perintah SHOW REPLICA STATUS, dan periksa kolom ini dalam output:
  • Replica_IO_Running
  • Replica_SQL_Running
  • Last_IO_Error
  • Last_SQL_Error

  Catatan: SHOW REPLICA STATUS adalah alias yang diperkenalkan di MySQL 8.0.22. Untuk versi sebelumnya (MySQL 5.7, MySQL 8.0), gunakan alias lama perintah status. Untuk informasi selengkapnya, lihat Pernyataan status dalam dokumentasi MySQL.

  Jika Anda mendapatkan error fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file' in Last_IO_Error, hal ini mungkin disebabkan oleh setelan retensi binlog yang tidak memadai di instance sumber.

  Jika Anda mendapatkan error error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIES, hal ini mungkin disebabkan oleh instance tujuan yang gagal terhubung kembali ke sumber karena masalah konektivitas atau autentikasi.

---

Pemeriksaan mysqld gagal: disk data penuh

Anda melihat error mysqld check failed: data disk is full.

Masalahnya mungkin adalah

Disk data instance tujuan mungkin penuh.

Hal-hal yang sebaiknya dicoba

Tingkatkan ukuran disk instance tujuan.

---

Gagal terhubung ke database sumber

Gagal terhubung ke database sumber.

Masalahnya mungkin adalah

Terjadi masalah konektivitas antara instance database sumber dan instance tujuan.

Hal-hal yang sebaiknya dicoba

Ikuti langkah-langkah di artikel proses debug konektivitas.

---

Migrasi dari database terkelola (Amazon RDS/Aurora) tidak dimulai

Tugas migrasi gagal dimulai.

Masalahnya mungkin adalah

Bermigrasi dari database sumber terkelola tanpa hak istimewa SUPERUSER memerlukan periode nonaktif singkat di awal migrasi.

Hal-hal yang sebaiknya dicoba

• Untuk Amazon RDS, ikuti langkah-langkah di artikel ini.
• Untuk Amazon Aurora, ikuti langkah-langkah dalam artikel ini.

---

Binlog salah dikonfigurasi di database sumber

Anda melihat error yang menunjukkan masalah pada log biner.

Masalahnya mungkin adalah

Hal ini dapat terjadi untuk tugas migrasi MySQL berkelanjutan jika konfigurasi binlog salah di database sumber.

Hal-hal yang sebaiknya dicoba

Pastikan Anda mengikuti definisi di sini.

---

Gagal membaca file dump yang diberikan

Anda melihat error yang menunjukkan masalah pada file dump.

Masalahnya mungkin adalah

DMS tidak dapat menemukan file dump yang diberikan.

Hal-hal yang sebaiknya dicoba

1. Periksa jalur dump untuk memastikan file yang tepat ada, atau ubah jalurnya
2. Jika Anda mengubah jalur, gunakan permintaan PATCH untuk memastikan tugas menggunakannya.
3. Mulai ulang tugas migrasi.

---

Tidak dapat melanjutkan replikasi karena posisi binlog hilang

Posisi binlog hilang.

Masalahnya mungkin adalah

Error ini dapat terjadi jika proses replikasi dijeda untuk waktu yang lama, yang menyebabkan posisi binlog hilang. Tugas migrasi tidak boleh dijeda untuk jangka waktu yang mendekati periode retensi binlog.

Hal-hal yang sebaiknya dicoba

Mulai ulang tugas migrasi.

---

Kegagalan menjalankan tugas migrasi karena versi database sumber dan tujuan tidak kompatibel

Versi database sumber dan tujuan bukan merupakan kombinasi yang didukung.

Masalahnya mungkin adalah

Versi database sumber yang diberikan tidak kompatibel dengan versi database tujuan.

Hal-hal yang sebaiknya dicoba

Pastikan versi database tujuan sama atau satu versi utama di atas versi tujuan sumber, lalu buat tugas migrasi baru.

---

Tidak dapat terhubung ke server database sumber

Anda melihat error Unable to connect to source database server.

Masalahnya mungkin adalah

Layanan Migrasi Database tidak dapat membuat koneksi ke server database sumber.

Hal-hal yang sebaiknya dicoba

Verifikasi bahwa instance database sumber dan tujuan dapat saling berkomunikasi. Kemudian, pastikan Anda telah menyelesaikan semua prasyarat yang diperlukan yang muncul saat Anda menentukan setelan untuk tugas migrasi.

---

Penggunaan disk instance tujuan Cloud SQL turun menjadi nol

Penggunaan disk tiba-tiba turun menjadi nol selama migrasi.

Masalahnya mungkin adalah

Mungkin ada kegagalan saat mengimpor data dump lengkap. Jika hal ini terjadi, proses migrasi akan mencoba melakukan pemuatan data lainnya. Proses ini pertama-tama menghapus data yang ada di instance tujuan (Inilah sebabnya Anda melihat penggunaan disk turun menjadi nol), lalu mencoba memuat ulang data.

Hal-hal yang sebaiknya dicoba

Buka Logs Explorer, lalu pilih instance tujuan dari daftar resource. Cari pesan log yang serupa: DUMP_STAGE(RETRY): Attempt .../...: import failed: error..."; Clearing database and trying again." Temukan pesan setelah teks import failed: dan coba selesaikan masalah yang mendasarinya.