Mengupgrade versi utama database yang sudah diterapkan

Halaman ini menjelaskan cara mengupgrade versi utama database dengan mengupgrade instance Cloud SQL sebagai gantinya, bukan memigrasi data.

Pengantar

Penyedia software database secara berkala merilis versi utama baru yang berisi fitur, peningkatan performa, serta peningkatan keamanan yang baru. Cloud SQL menerima versi baru setelah versi baru tersebut dirilis. Setelah Cloud SQL menawarkan dukungan untuk versi utama yang baru, Anda dapat mengupgrade instance untuk menjaga database Anda terus terupdate.

Anda dapat mengupgrade versi database dari instance secara langsung atau dengan memigrasikan data. Upgrade secara langsung adalah cara yang lebih mudah untuk mengupgrade versi utama instance Anda. Anda tidak perlu memigrasikan data atau mengubah string koneksi aplikasi. Dengan upgrade secara langsung, Anda dapat mempertahankan nama, alamat IP, dan setelan lain dari instance saat ini setelah upgrade. Upgrade secara langsung tidak mengharuskan Anda memindahkan file data dan dapat diselesaikan lebih cepat. Dalam beberapa kasus, periode nonaktif lebih singkat daripada yang diperlukan untuk memigrasikan data Anda.

Untuk MySQL 8.0.15 dan yang lebih lama, operasi upgrade MySQL secara langsung menggunakan utilitas mysql_upgrade. Untuk MySQL 8.0.16 dan yang lebih baru, operasi upgrade MySQL secara langsung ditangani oleh proses MySQL server. Untuk mengetahui informasi selengkapnya tentang operasi upgrade secara langsung, lihat Yang Diupgrade oleh Proses Upgrade MySQL

Merencanakan upgrade versi utama

  1. Pilih versi utama target.

    gcloud

    Untuk mengetahui informasi tentang menginstal dan memulai gcloud CLI, lihat Menginstal gcloud CLI. Untuk mengetahui informasi tentang cara memulai Cloud Shell, lihat Menggunakan Cloud Shell.

    Untuk memeriksa versi database yang dapat Anda targetkan untuk upgrade langsung di instance, lakukan hal berikut:

    1. Jalankan perintah berikut.
      2. gcloud sql instances describe INSTANCE_NAME

      Ganti INSTANCE_NAME dengan nama instance.

    2. Di output perintah, cari bagian yang berlabel upgradableDatabaseVersions.
    3. Setiap subbagian menampilkan versi database yang tersedia untuk upgrade. Di setiap subbagian, tinjau kolom berikut.
      • majorVersion: versi utama yang dapat Anda targetkan untuk upgrade di tempat.
      • name: string versi database yang menyertakan versi utama. Untuk Cloud SQL untuk MySQL, kolom ini juga menyertakan versi minor database.
      • displayName: nama tampilan untuk versi database.

    REST v1

    Untuk memeriksa versi database target yang tersedia untuk upgrade versi utama secara langsung, gunakan metode instances.get Cloud SQL Admin API.

    Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

    • INSTANCE_NAME: Nama instance.

    Metode HTTP dan URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    Untuk mengirim permintaan, perluas salah satu opsi berikut:

    Anda akan menerima respons JSON seperti berikut:

    
upgradableDatabaseVersions:

{
  major_version: "MYSQL_8_0"
  name: "MYSQL_8_0_36"
  display_name: "MySQL 8.0.36"
}

    REST v1beta4

    Untuk memeriksa versi database target yang tersedia untuk upgrade versi utama secara langsung pada instance, gunakan metode instances.get Cloud SQL Admin API.

    Sebelum menggunakan salah satu data permintaan, lakukan penggantian berikut:

    • INSTANCE_NAME: Nama instance.

    Metode HTTP dan URL: 

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_NAME

    Untuk mengirim permintaan, perluas salah satu opsi berikut:

    Anda akan melihat respons JSON seperti berikut:

    
upgradableDatabaseVersions:

{
  major_version: "MYSQL_8_0"
  name: "MYSQL_8_0_36"
  display_name: "MySQL 8.0.36"
}

    Untuk mengetahui daftar lengkap versi database yang didukung Cloud SQL, lihat Kebijakan versi dan versi database.

  2. Pertimbangkan fitur yang ditawarkan di setiap versi utama database dan atasi ketidaksesuaian.

    Versi utama baru memperkenalkan perubahan yang tidak kompatibel yang mungkin mengharuskan Anda mengubah kode aplikasi, skema, atau setelan database. Sebelum mengupgrade instance database, tinjau kembali catatan rilis versi utama target Anda untuk menentukan ketidaksesuaian yang harus Anda atasi.

    Setelah mengupgrade ke versi yang lebih baru, nilai default beberapa variabel sistem mungkin berubah. Misalnya, nilai default character_set_server di MySQL 5.6 dan MySQL 5.7 adalah utf8. Saat Anda mengupgrade ke MySQL 8.0, nilai default character_set_server berubah menjadi utf8mb4. Untuk kembali ke utf8, Anda harus mengubah nilai flag database secara manual ke nilai lama. Lihat Mengonfigurasi flag database untuk informasi selengkapnya. Sebagian besar perubahan nilai default dilakukan oleh Komunitas MySQL (lihat selengkapnya di Upgrade Server Defaults).

  3. Jika mengupgrade dari MySQL 8.0 ke 8.4, Anda harus mengupgrade instance ke MySQL 8.0.37 atau yang lebih baru terlebih dahulu sebelum dapat mengupgrade ke MySQL 8.4. Untuk melakukan upgrade versi minor, lihat Mengupgrade versi minor database.

  4. Lakukan pemeriksaan awal untuk upgrade.

    • Jika Anda mengupgrade dari MySQL 5.7 ke 8.0, lakukan pemeriksaan awal untuk upgrade dari MySQL 5.7 ke 8.0. Anda dapat menggunakan Upgrade Checker Utility di shell MySQL.

    • Jika Anda mengupgrade dari MySQL 8.0 ke 8.4, lakukan pemeriksaan awal untuk upgrade dari MySQL 8.0 ke 8.4. Anda dapat menggunakan Upgrade Checker Utility di shell MySQL.

      Jika ada masalah yang ditemukan selama pra-pemeriksaan, perbaiki masalah tersebut sebelum melanjutkan ke upgrade. Cloud SQL tidak mendukung pemeriksaan awal selama upgrade versi utama. Upaya untuk mengupgrade instance yang gagal dalam pemeriksaan awal juga mungkin gagal.

  5. Periksa kapasitas disk dan jenis mesin instance.

    Upgrade versi utama memerlukan resource tambahan, seperti ruang disk, untuk menyimpan tabel yang diupgrade. Jika ruang disk tidak cukup, upgrade akan gagal dan di-roll back. Untuk upgrade dari MySQL 5.7 ke 8.0, memori tambahan diperlukan untuk mengonversi metadata lama ke kamus data baru. Sebelum menjalankan upgrade versi utama, pastikan Anda memiliki lebih dari 100 ribu memori untuk setiap tabel Anda dapat meningkatkan memori untuk sementara dengan mengubah jenis mesin.

  6. Untuk upgrade dari MySQL 5.7 ke MySQL 8.0, periksa perubahan izin pengguna di MySQL 8.0

    Cloud SQL untuk MySQL versi 8.0 menggunakan flag yang disebut partial_revokes, yang disetel ke ON secara default. Tidak seperti MySQL 5.7, flag ini menghapus kemampuan untuk menggunakan karakter pengganti dalam perintah GRANT database. Untuk memastikan pengguna database memiliki akses ke skema database yang benar, ubah hak istimewa pengguna database sebelum mengupgrade ke MySQL 8.0. Perbarui hak istimewa pengguna untuk menggunakan nama lengkap skema database yang diperlukan, bukan menggunakan karakter pengganti.

    Untuk mengetahui informasi lebih lanjut tentang cara kerja flag ini di MySQL 8.0, lihat Partial_revokes di MySQL 8.0.

  7. Uji upgrade dengan uji coba.

    Jalankan uji coba proses upgrade menyeluruh di lingkungan pengujian sebelum Anda mengupgrade database produksi. Anda dapat meng-clone instance untuk membuat salinan data identik yang akan digunakan untuk menguji proses upgrade.

    Selain memvalidasi bahwa upgrade berhasil diselesaikan, jalankan pengujian untuk memastikan aplikasi berperilaku seperti yang diharapkan pada database yang telah diupgrade.

  8. Tentukan waktu untuk mengupgrade.

    Upgrade mengharuskan instance menjadi tidak tersedia selama beberapa waktu. Rencanakan untuk melakukan upgrade saat aktivitas database rendah.

Mempersiapkan upgrade versi utama

Sebelum mengupgrade, selesaikan langkah-langkah berikut:

  1. HANYA untuk upgrade dari MySQL 5.7 ke 8.0: Periksa dan perbaiki masalah yang tidak kompatibel yang ditemukan selama proses pemeriksaan awal. Masalah umum yang ditemukan dapat mencakup:

    1. Penambahan kata kunci baru yang dicadangkan, seperti RANKS, GROUPS, FUNCTION, dalam prosedur tersimpan, pemicu, dan objek database lainnya. Lihat Kata Kunci dan Kata yang Direservasi untuk mengetahui informasi selengkapnya.
    2. Karakter UTF tidak valid dalam definisi tabel.
    3. Transisi XA yang tidak di-commit yang harus di-commit (menggunakan pernyataan XA COMMIT) atau di-roll back (menggunakan pernyataan XA ROLLBACK).
    4. Batasan kunci asing dalam nama yang melebihi 64 karakter.
    5. Jenis data spasial dalam indeks campuran kolom. Untuk mengetahui informasi selengkapnya, lihat Jenis Data Spasial.

    Untuk informasi selengkapnya, lihat Menyiapkan penginstalan untuk upgrade dan Mengupgrade ke MySQL 8.0?.

    HANYA untuk upgrade dari MySQL 8.0 ke MySQL 8.4: Periksa dan perbaiki masalah yang tidak kompatibel yang ditemukan selama proses pemeriksaan awal. Masalah umum mungkin mencakup:

    • Terminologi replikasi yang sudah tidak berlaku. Istilah MASTER dan SLAVE dihapus sepenuhnya dari MySQL 8.4. Jika Anda masih menggunakan perintah atau konfigurasi apa pun dengan istilah ini, Anda harus mengganti atau menghapusnya. Untuk mengetahui informasi selengkapnya tentang penghapusan dan penggantian istilah ini, lihat Yang Baru di MySQL 8.4 sejak MySQL 8.0.
    • Perbarui plugin autentikasi akun pengguna yang ada untuk menggunakan plugin autentikasi caching_sha2_password, bukan plugin mysql_native_password yang tidak digunakan lagi.

      Untuk mengubah akun pengguna database yang ada agar menggunakan plugin autentikasi caching_sha2_password, gunakan perintah berikut: 
           ALTER USER 'username'@'%'
     IDENTIFIED WITH caching_sha2_password BY 'user_password';
      Ganti username dan user_password dengan nilai untuk akun pengguna yang Anda perbarui.

  2. Memeriksa kapasitas disk dan jenis mesin instance

    Upgrade versi utama memerlukan ruang disk dan memori tambahan untuk menyimpan tabel yang diupgrade dan kamus data baru. Kurangnya ruang disk yang diperlukan menyebabkan upgrade gagal dan melakukan roll back ke versi aslinya. Cloud SQL merekomendasikan agar Anda memiliki memori minimum 100 ribu untuk setiap tabel.

    Catatan: Anda dapat meningkatkan memori untuk sementara dengan mengubah jenis mesin sebelum menjalankan upgrade versi utama. Untuk mempelajari lebih lanjut, lihat mengubah jenis mesin.

  3. Upgrade replika baca Anda.

    Jika menggunakan replika baca, Anda harus mengupgrade semua replika baca terlebih dahulu sebelum mengupgrade instance utama. Jika replika diupgrade tetapi instance utamanya tidak, replikasi mungkin tidak berfungsi jika yang utama menggunakan pernyataan atau fungsi yang tidak lagi didukung di versi MySQL terbaru yang digunakan oleh replika. Untuk menghindari masalah tersebut, Cloud SQL merekomendasikan agar Anda:

    1. Upgrade instance utama segera setelah mengupgrade replika.
    2. Hindari menjalankan kueri yang tidak kompatibel dengan versi baru pada instance utama hingga upgrade berhasil diselesaikan.
    3. Opsional: Jeda semua pernyataan WRITE ke instance utama hingga upgrade berhasil diselesaikan.
    4. Opsional: Hapus semua replika sebelum mengupgrade instance utama dan buat ulang replika setelah upgrade selesai.

    Jika replikasi rusak, replika akan di-roll back ke versi instance utama. Anda dapat mengupgrade replika lagi, tetapi jika masalah berlanjut, lihat FAQ.

Mengupgrade versi utama database yang sudah diterapkan

Saat Anda memulai operasi upgrade, Cloud SQL akan memeriksa konfigurasi instance Anda terlebih dahulu untuk memastikan kompatibilitasnya dengan upgrade. Setelah memverifikasi konfigurasi Anda, Cloud SQL akan membuat instance Anda tidak tersedia, membuat cadangan upgrade awal, melakukan upgrade, menyediakan instance, dan membuat cadangan pasca-upgrade.

Saat Anda mengupgrade ke MySQL 8.0, Cloud SQL akan otomatis menyediakan instance Anda pada versi minor default.

Konsol

  1. Di konsol Google Cloud, buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Untuk membuka halaman Ringkasan instance, klik nama instance.
  3. Klik Edit.
  4. Di bagian Info instance, klik tombol Upgrade dan konfirmasi bahwa Anda ingin membuka halaman upgrade.
  5. Di halaman Memilih versi database, klik daftar Versi database untuk upgrade dan pilih salah satu versi utama database yang tersedia.
  6. Klik Lanjutkan.
  7. Di kotak ID Instance, masukkan nama instance, lalu klik tombol Mulai upgrade.
Operasi ini memerlukan waktu beberapa menit hingga selesai.

Pastikan versi utama database yang telah diupgrade muncul di bawah nama instance pada halaman Ringkasan instance.

gcloud

  1. Mulai upgrade.

    Gunakan perintah gcloud sql instances patch dengan flag --database-version.

    Sebelum menjalankan perintah, ganti variabel berikut:

    • INSTANCE_NAME: nama instance
    • DATABASE_VERSION: Enum untuk versi utama database, yang harus lebih baru dari versi saat ini. Tentukan versi database untuk versi utama yang tersedia sebagai target upgrade untuk instance. Anda bisa mendapatkan enum ini sebagai langkah pertama Merencanakan upgrade. Jika Anda memerlukan daftar lengkap enum versi database, lihat SqlDatabaseEnums.
    gcloud sql instances patch INSTANCE_NAME \
--database-version=DATABASE_VERSION

    Upgrade versi utama memerlukan waktu beberapa menit untuk diselesaikan. Anda mungkin melihat pesan yang menunjukkan bahwa operasi memerlukan waktu lebih lama dari yang diperkirakan. Anda dapat mengabaikan pesan ini atau menjalankan perintah gcloud sql operations wait untuk menutup pesan.

  2. Dapatkan nama operasi upgrade.

    Gunakan perintah gcloud sql operations list dengan flag --instance.

    Sebelum menjalankan perintah, ganti variabel INSTANCE_NAME dengan nama instance. 

    gcloud sql operations list --instance=INSTANCE_NAME

  3. Pantau status upgrade.

    Gunakan perintah gcloud sql operations describe.

    Sebelum menjalankan perintah, ganti variabel OPERATION dengan nama operasi upgrade yang diambil di langkah sebelumnya. 

    gcloud sql operations describe OPERATION

REST v1

  1. Mulai upgrade secara langsung.

    Gunakan permintaan PATCH dengan metode instances:patch.

    Sebelum menggunakan data permintaan apa pun, ganti variabel berikut:

    • PROJECT_ID: ID project.
    • INSTANCE_NAME: Nama instance.

    Metode HTTP dan URL: 

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_NAME

    Meminta isi JSON: 

    {
  "databaseVersion": DATABASE_VERSION
}

    Ganti DATABASE_VERSION dengan enum untuk versi utama database, yang harus lebih baru dari versi saat ini. Tentukan versi database untuk versi utama yang tersedia sebagai target upgrade untuk instance. Anda bisa mendapatkan enum ini sebagai langkah pertama Merencanakan upgrade. Jika Anda memerlukan daftar lengkap enum versi database, lihat SqlDatabaseVersion.

  2. Dapatkan nama operasi upgrade.

    Gunakan permintaan GET dengan metode operations.list setelah mengganti PROJECT_ID dengan ID project.

    Metode HTTP dan URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations

  3. Pantau status upgrade.

    Gunakan permintaan GET dengan metode operations.get setelah mengganti variabel berikut:

    • PROJECT_ID: ID project.
    • OPERATION_NAME: Nama operasi upgrade yang diambil di langkah sebelumnya.

    Metode HTTP dan URL: 

    GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operation/OPERATION_NAME

Terraform

Untuk memperbarui versi database, gunakan resource Terraform dan penyedia Terraform untuk Google Cloud, versi 4.34.0 atau yang lebih baru.

resource "google_sql_database_instance" "instance" {
  name             = "mysql-instance"
  region           = "us-central1"
  database_version = "MYSQL_8_0"
  settings {
    tier = "db-n1-standard-2"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Menerapkan perubahan

Untuk menerapkan konfigurasi Terraform di project Google Cloud, selesaikan langkah-langkah di bagian berikut.

Menyiapkan Cloud Shell

  1. Luncurkan Cloud Shell.

  2. Tetapkan project Google Cloud default tempat Anda ingin menerapkan konfigurasi Terraform.

    Anda hanya perlu menjalankan perintah ini sekali per project, dan dapat dijalankan di direktori mana pun.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Variabel lingkungan akan diganti jika Anda menetapkan nilai eksplisit dalam file konfigurasi Terraform.

Menyiapkan direktori

Setiap file konfigurasi Terraform harus memiliki direktorinya sendiri (juga disebut modul root).

  1. Di Cloud Shell, buat direktori dan file baru di dalam direktori tersebut. Nama file harus memiliki ekstensi .tf—misalnya main.tf. Dalam tutorial ini, file ini disebut sebagai main.tf. 
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf

  2. Jika mengikuti tutorial, Anda dapat menyalin kode contoh di setiap bagian atau langkah.

    Salin kode contoh ke dalam main.tf yang baru dibuat.

    Atau, salin kode dari GitHub. Tindakan ini direkomendasikan jika cuplikan Terraform adalah bagian dari solusi menyeluruh.

  3. Tinjau dan ubah contoh parameter untuk diterapkan pada lingkungan Anda.
  4. Simpan perubahan Anda.
  5. Lakukan inisialisasi Terraform. Anda hanya perlu melakukan ini sekali per direktori. 
    terraform init

    Secara opsional, untuk menggunakan versi penyedia Google terbaru, sertakan opsi -upgrade: 

    terraform init -upgrade

Menerapkan perubahan

  1. Tinjau konfigurasi dan pastikan resource yang akan dibuat atau diupdate oleh Terraform sesuai yang Anda inginkan: 
    terraform plan

    Koreksi konfigurasi jika diperlukan.

  2. Terapkan konfigurasi Terraform dengan menjalankan perintah berikut dan memasukkan yes pada prompt: 
    terraform apply

    Tunggu hingga Terraform menampilkan pesan "Apply complete!".

  3. Buka project Google Cloud Anda untuk melihat hasilnya. Di Konsol Google Cloud, buka resource Anda di UI untuk memastikan bahwa Terraform telah membuat atau mengupdatenya.

Menghapus perubahan

Untuk menghapus perubahan Anda, lakukan langkah-langkah berikut:

  1. Untuk menonaktifkan perlindungan penghapusan, di file konfigurasi Terraform Anda, tetapkan argumen deletion_protection ke false. 
    deletion_protection =  "false"
  2. Terapkan konfigurasi Terraform dengan menjalankan perintah berikut dan memasukkan yes pada prompt: 
    terraform apply

  1. Hapus resource yang sebelumnya diterapkan dengan konfigurasi Terraform Anda dengan menjalankan perintah berikut dan memasukkan yes pada prompt:

    terraform destroy

Saat Anda mengajukan permintaan upgrade secara langsung, Cloud SQL akan melakukan pemeriksaan upgrade awal terlebih dahulu. Jika Cloud SQL menentukan bahwa instance Anda belum siap untuk diupgrade, permintaan upgrade Anda akan gagal dengan pesan yang menyarankan cara mengatasi masalah tersebut. Lihat juga Memecahkan masalah upgrade versi utama.

Cadangan upgrade otomatis

Saat Anda melakukan upgrade versi utama, Cloud SQL secara otomatis membuat dua pencadangan on-demand, yang disebut cadangan upgrade:

  • Cadangan upgrade pertama adalah cadangan pra-upgrade, yang segera dibuat sebelum memulai upgrade. Anda dapat menggunakan cadangan ini untuk memulihkan instance database ke statusnya pada versi sebelumnya.
  • Cadangan upgrade kedua adalah cadangan pasca-upgrade, yang segera dibuat setelah penulisan baru diizinkan ke instance database yang diupgrade.

Saat Anda melihat daftar cadangan, cadangan upgrade akan dicantumkan dengan jenis On-demand. Cadangan upgrade diberi label agar Anda dapat mengidentifikasinya dengan cepat. Misalnya, jika Anda mengupgrade dari MySQL 5.7 ke MySQL 8.0, cadangan pra-upgrade Anda akan diberi label Pre-upgrade backup, MYSQL_5_7 to MYSQL_8_0. dan cadangan pasca-upgrade Anda diberi label Post-upgrade backup, MYSQL_8_0 from MYSQL_5_7. Jika Anda mengupgrade dari MySQL 8.0 ke MySQL 8.4, cadangan pra-upgrade Anda akan diberi label Pre-upgrade backup, MYSQL_8_0 to MYSQL_8_4. dan cadangan pasca-upgrade Anda diberi label Post-upgrade backup, MYSQL_8_4 from MYSQL_8_0.

Seperti pencadangan on demand lainnya, cadangan upgrade akan tetap ada hingga Anda menghapusnya atau menghapus instance. Jika PITR diaktifkan, Anda tidak dapat menghapus cadangan upgrade saat cadangan upgrade berada di periode retensi. Jika perlu menghapus cadangan upgrade, Anda harus menonaktifkan PITR atau menunggu hingga cadangan upgrade tidak lagi berada dalam periode retensi.

Menyelesaikan upgrade versi utama

Setelah selesai mengupgrade instance utama, lakukan langkah-langkah berikut untuk menyelesaikan upgrade:

  1. Melakukan pengujian penerimaan.

    Jalankan pengujian untuk mengonfirmasi bahwa performa sistem yang telah diupgrade berjalan seperti yang diharapkan.

  2. Opsional: Perbarui hak istimewa pengguna.

    Jika Anda telah mengupgrade ke MySQL 8.0, perlu diperhatikan bahwa MySQL telah mengubah sistem pengelolaan keamanan dan akun. Untuk mengetahui informasi selengkapnya, lihat What is New in MySQL 8.0

    Hal ini dapat menyebabkan pengguna yang dibuat di instance versi MySQL 5.7 tidak memiliki hak istimewa yang sama dengan pengguna yang dibuat langsung di MySQL 8.0. Misalnya, pengguna yang mengupgrade dari MySQL 5.7 mungkin tidak memiliki hak istimewa CREATE ROLE dan DROP ROLE karena hak istimewa ini tidak ada di MySQL 5.7. Cloud SQL merekomendasikan agar Anda mereset hak istimewa pengguna setelah mengupgrade versi untuk memperbaiki masalah terkait hak istimewa pengguna.

    Jika Anda telah mengupgrade dari MySQL 8.0 ke MySQL 8.4, akan ada perubahan tambahan pada hak istimewa pengguna, termasuk penambahan hak istimewa yang diperkenalkan di MySQL 8.4 dan penghapusan hak istimewa yang ada di MySQL 8.0. Untuk mengetahui informasi selengkapnya, lihat Hak istimewa pengguna MySQL 8.4 (cloudsqlsuperuser).

    Anda dapat memperbarui hak istimewa pengguna di MySQL 8.0 atau MySQL 8.4 dengan melakukan hal berikut:

    1. Membuat pengguna dengan peran yang diberikan cloudsqlsuperuser.

    2. Gunakan pengguna yang dibuat untuk mencabut semua hak istimewa sebelumnya dari pengguna yang diupgrade dengan:

      REVOKE ALL PRIVILEGES ON *.* FROM user@host

    3. Memberikan hak istimewa yang diharapkan kepada pengguna yang diupgrade.

  3. Opsional: Buat cadangan.

    Meskipun Cloud SQL membuat cadangan secara otomatis setelah Anda mengupgrade instance utama, Cloud SQL merekomendasikan agar membuat cadangan sendiri sehingga Anda dapat memulihkan database, jika perlukan.

  4. Opsional: Jika Anda telah mengupgrade ke Cloud SQL untuk MySQL 8.4, update juga semua konektor, klien, dan shell MySQL ke MySQL 8.4.

Memecahkan masalah upgrade versi utama

Cloud SQL menampilkan pesan error jika Anda mencoba perintah upgrade yang tidak valid, misalnya, jika instance Anda berisi flag database tidak valid untuk versi baru.

Jika permintaan upgrade gagal, periksa sintaksis permintaan upgrade Anda. Jika permintaan memiliki struktur yang valid, coba lihat saran berikut.

Melihat log upgrade

Jika terjadi masalah dengan permintaan upgrade yang valid, Cloud SQL akan menayangkan log error ke projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err. Setiap entri log berisi label dengan ID instance untuk membantu Anda mengidentifikasi instance dengan error upgrade. Cari error upgrade tersebut dan selesaikan error tersebut.

Untuk melihat log error, ikuti langkah-langkah berikut:

  1. Di Konsol Google Cloud, buka halaman Instance Cloud SQL.

    Buka Instance Cloud SQL

  2. Untuk membuka halaman Ringkasan instance, klik nama instance.

  3. Di panel Operations and logs di halaman Ringkasan, klik link View MySQL error logs.

    Halaman Logs Explorer akan terbuka.

  4. Lihat log sebagai berikut:

    • Untuk mencantumkan semua log in error dalam sebuah project, pilih nama log dalam filter log Nama log.

    Untuk informasi selengkapnya tentang filter kueri, lihat Kueri lanjutan

    • Guna memfilter log error upgrade untuk satu instance, masukkan kueri berikut di kotak Masukkan semua kolom, setelah mengganti DATABASE_ID

    dengan project ID yang diikuti dengan nama instance dalam format ini: project_id:instance_name.

    resource.type="cloudsql_database"
resource.labels.database_id="DATABASE_ID"
logName : "projects/PROJECT_ID/logs/cloudsql.googleapis.com%2Fmysql.err"

    Misalnya, untuk memfilter log error upgrade berdasarkan instance bernama shopping-db yang berjalan di project buylots, gunakan filter kueri berikut: 

     resource.type="cloudsql_database"
 resource.labels.database_id="buylots:shopping-db"
 logName : "projects/buylots/logs/cloudsql.googleapis.com%2Fmysql.err"

Pulihkan ke versi utama sebelumnya

Jika sistem database yang telah diupgrade tidak berfungsi seperti yang diharapkan, Anda mungkin perlu memulihkan instance ke versi sebelumnya. Anda melakukannya dengan memulihkan cadangan pra-upgrade ke instance pemulihan Cloud SQL, yang merupakan instance baru yang menjalankan versi upgrade.

Untuk memulihkan ke versi sebelumnya, lakukan langkah-langkah berikut:

  1. Identifikasi cadangan pra-upgrade Anda.

    Lihat Cadangan upgrade otomatis.

  2. Buat instance pemulihan.

    Buat instance Cloud SQL baru menggunakan veri utama yang dijalankan Cloud SQL saat cadangan pra-upgrade dibuat. Tetapkan flag dansetelan instance yang sama dengan yang digunakan instance asli.

  3. Pulihkan cadangan pra-upgrade Anda.

    Pulihkan cadangan pra-upgrade Anda ke instance pemulihan. Mungkin memerlukan waktu beberapa menit untuk menyelesaikan proses.

  4. Tambahkan replika baca Anda.

    Jika Anda menggunakan replika baca, tambahkan satu per satu.

  5. Hubungkan aplikasi Anda.

    Setelah memulihkan sistem database Anda, perbarui aplikasi Anda dengan detail mengenai instance pemulihan dan replika bacanya. Anda dapat melanjutkan penyaluran traffic pada versi pra-upgrade database Anda.

Batasan

Bagian ini mencantumkan batasan untuk upgrade versi utama yang diterapkan.

  • Anda tidak dapat melakukan upgrade versi utama di tempat pada replika eksternal.
  • Mengupgrade instance dari MySQL 5.7 ke 8.0 yang memiliki lebih dari 512,000 tabel mungkin memerlukan waktu tunggu lama dan dapat mencapai batas waktu.
  • Mengupgrade instance dari MySQL 8.0 ke 8.4 yang memiliki lebih dari 512.000 tabel mungkin memerlukan waktu tunggu lama dan dapat mencapai batas waktu.

  • Saat mengupgrade dari MySQL 8.0 ke 8.4, jika Anda telah mengupgrade replika ke MySQL 8.4, tetapi tidak mengupgrade instance utama, Anda dapat membuat akun pengguna baru di instance utama yang tidak diupgrade dengan plugin autentikasi mysql_native_password yang tidak digunakan lagi. Untuk menghindari situasi ini, pastikan Anda mengupgrade instance utama segera setelah mengupgrade replika, atau hanya membuat akun pengguna baru di instance utama menggunakan perintah berikut.

    CREATE USER USERNAME'@'% IDENTIFIED WITH caching_sha2_password BY 'PASSWORD';

    Ganti USERNAME dan PASSWORD dengan nilai yang sesuai.

FAQ

Pertanyaan berikut mungkin muncul saat mengupgrade versi utama database.

Apakah instance saya tidak tersedia selama upgrade?
Tentu saja. Instance Anda tetap tidak tersedia selama beberapa waktu saat Cloud SQL melakukan upgrade.
Berapa lama waktu yang diperlukan untuk melakukan upgrade?

Proses upgrade satu instance biasanya memerlukan waktu kurang dari 10 menit. Jika konfigurasi instance Anda menggunakan sejumlah kecil vCPU atau memori, upgrade mungkin memerlukan waktu lebih lama.

Jika instance Anda menghosting terlalu banyak database atau tabel, atau database Anda berukuran sangat besar, upgrade mungkin memerlukan waktu berjam-jam atau bahkan waktu habis, karena waktu upgrade sesuai dengan jumlah objek dalam database Anda. Jika Anda memiliki beberapa instance yang perlu diupgrade, total waktu upgrade Anda akan meningkat secara proporsional.

Dapatkah saya memantau setiap langkah dalam proses upgrade?
Saat Cloud SQL mengizinkan Anda untuk memantau apakah operasi upgrade masih berlangsung, Anda tidak dapat melacak setiap langkah di setiap upgrade.
Dapatkah saya membatalkan upgrade setelah memulainya?
Tidak, Anda tidak dapat membatalkan upgrade setelah dimulai. Jika upgrade gagal, Cloud SQL akan otomatis memulihkan instance Anda di versi sebelumnya.
Apa yang terjadi dengan setelan saya selama upgrade?

Saat Anda melakukan upgrade versi tama secara langsung, Cloud SQL menyimpan setelan database Anda, termasuk nama instance, alamat IP, nilai flag yang dikonfigurasi secara eksplisit, dan data pengguna. Namun, nilai default variabel sistem mungkin berubah. Misalnya, nilai default flag character_set_server di MySQL 5.7 adalah utf8. Saat Anda mengupgrade ke MySQL 8.0, nilai default flag akan berubah menjadi utf8mb4. Untuk mengembalikannya utf8, atur nilai flag kembali ke nilai sebelumnya.

Untuk mempelajari lebih lanjut, lihat Mengonfigurasi flag database. Jika flag tertentu atau nilai tertentu tidak lagi didukung dalam versi target Anda, Cloud SQL secara otomatis akan menghapus flag tersebut selama upgrade.

Apa yang dapat saya lakukan jika replikasi terputus setelah mengupgrade replika?
Jika replikasi terputus setelah mengupgrade replika, maka akan di-roll back ke versi MySQL instance utama. Anda dapat mengupgrade replika lagi, tetapi jika masalah berlanjut, replikasi mungkin akan terputus lagi.

Jika replika tidak di-roll back, Anda memiliki dua opsi:

  1. Hapus replika yang terputus, buat replika baru, dan upgrade replika barunya.

    Jika upgrade gagal lagi, hal ini mungkin disebabkan oleh perubahan yang tidak kompatibel yang ditambahkan ke aplikasi utama saat diupgrade. Identifikasi masalah selama proses upgrade, perbaiki instance utama, lalu coba upgrade replika. Lihat memecahkan masalah untuk mengetahui informasi selengkapnya.

  2. Mengupgrade instance utama

    Operasi upgrade instance utama akan membuat ulang replika jika thread replika tidak berfungsi.

Mengapa replika saya yang sudah diupgrade roll back ke versi lama?

Jika upgrade tidak berhasil, replika akan di-roll back ke versi instance utama. Anda dapat mengupgrade replika lagi, tetapi jika tetap berlanjut, Anda dapat memeriksa log mysql.err pada replika untuk menemukan sumbernya. Telusuri kata kunci seperti [REPL]... failed executing transaction.... end_log_pos...; Failure Reason.

Jika pesan error berisi Access denied for AuthId.... dengan perubahan hak istimewa pengguna, kemungkinan ada kueri yang dijalankan menggunakan hak istimewa pengguna MySQL 5.7 pada skema mysql dan sistem, dan mungkin gagal karena perubahan pada sistem manajemen keamanan dan akun di MySQL 8.0. Untuk mengatasi masalah ini, Anda harus menghentikan kueri pada instance utama sebelum mengupgrade ke versi baru, lalu coba mengupgrade replika. Cloud SQL merekomendasikan agar Anda juga menghentikan sementara semua kueri seperti itu di instance utama sebelum mengupgrade ke versi baru karena dapat menyebabkan masalah serupa.

Jika alasan kegagalan tidak terlihat, seperti Access denied for AuthID.... di log MySQL, berarti masalah Anda kemungkinan disebabkan oleh data baru yang tidak kompatibel yang mungkin telah ditambahkan ke instance utama setelah replika diupgrade. Lihat menyiapkan upgrade versi utama untuk mengetahui cara memperbaiki masalah ketikdakcocokan data sebelum melakukan upgrade lagi.

Langkah berikutnya