Upgrade di tempat

Halaman ini menjelaskan cara melakukan upgrade dan downgrade di tempat pada instance Cloud SQL.

Melakukan perubahan di tempat pada instance Cloud SQL

Anda dapat menggunakan perubahan di tempat untuk mengupgrade atau mendowngrade edisi, jenis mesin, atau jenis penyimpanan instance Cloud SQL, atau untuk mengupgrade versi databasenya. Melakukan perubahan di tempat adalah cara termudah dan paling tidak rentan error untuk mengonfigurasi ulang instance.

Sebelum memulai

Pastikan instance Anda berjalan di MySQL versi 8.0.31 atau yang lebih baru.

Jika instance Anda menggunakan MySQL versi yang lebih lama, Anda harus mengupgrade ke MySQL 8.0.31 atau yang lebih baru. Untuk mengetahui informasi selengkapnya, lihat Mengupgrade versi utama database secara langsung dan Mengupgrade versi minor database.

Perhatikan potensi perubahan penyimpanan terkait jenis mesin

Edisi yang berbeda mendukung jenis mesin yang berbeda yang menggunakan opsi penyimpanan yang berbeda. Jenis mesin C4 dan C4A berperforma tinggi menggunakan penyimpanan Hyperdisk Balanced, bukan salah satu opsi persistent disk yang digunakan oleh jenis mesin yang lebih lama.

Saat Anda mengubah edisi atau jenis mesin yang digunakan, jenis penyimpanan Anda juga dapat berubah, yang dapat menyebabkan beberapa waktu nonaktif dan perubahan biaya penyimpanan. Saat beralih ke Google Cloud Hyperdisk Balanced, ada opsi konfigurasi tambahan yang dapat Anda tentukan. Untuk mengetahui informasi selengkapnya, lihat Perubahan penyimpanan.

Memperhatikan perubahan penyimpanan log transaksi PITR

Jika Anda mengupgrade instance edisi Cloud SQL Enterprise yang menyimpan log biner yang digunakan untuk PITR di disk, perlu diketahui bahwa proses upgrade ke edisi Cloud SQL Enterprise Plus memindahkan lokasi penyimpanan log tersebut dari disk ke Cloud Storage. Untuk menentukan lokasi saat ini dari log biner PITR untuk instance Anda, lihat Memeriksa lokasi penyimpanan log transaksi yang digunakan untuk PITR.

Untuk penjelasan lengkap tentang pengaruh upgrade di tempat terhadap lokasi log biner, lihat Perubahan lokasi penyimpanan log biner untuk PITR.

Mengubah edisi instance di tempat

Bagian ini menunjukkan cara mengubah edisi instance Cloud SQL Anda secara langsung ke atau dari edisi Cloud SQL Enterprise Plus. Edisi Cloud SQL Enterprise Plus menawarkan beberapa manfaat dan peningkatan performa yang tidak dimiliki edisi Cloud SQL Enterprise. Untuk mengetahui informasi selengkapnya tentang edisi Cloud SQL, lihat Ringkasan edisi Cloud SQL.

Upgrade ke edisi Cloud SQL Enterprise Plus memerlukan waktu beberapa menit untuk diselesaikan dan memiliki periode nonaktif nyaris nol. Beralih kembali ke edisi Cloud SQL Enterprise akan menyebabkan periode nonaktif yang lebih lama. Kedua proses tersebut tidak memerlukan perubahan endpoint yang terhubung ke aplikasi Anda.

Gunakan prosedur di bagian ini untuk mengupgrade instance edisi Cloud SQL Enterprise ke edisi Cloud SQL Enterprise Plus, atau untuk mendowngrade instance edisi Cloud SQL Enterprise Plus ke edisi Cloud SQL Enterprise.

gcloud sql instances patch INSTANCE_ID \
  --edition=enterprise-plus \
  --tier=MACHINE_TYPE \
  --project=PROJECT_ID

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

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

{
  "settings": {
      "tier": "MACHINE_TYPE",
      "edition": "ENTERPRISE_PLUS",
      "dataCacheConfig": {
        "dataCacheEnabled": true
      },
  }
}

curl -X PATCH \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d @request.json \
     "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method PATCH `
    -Headers $headers `
    -ContentType: "application/json; charset=utf-8" `
    -InFile request.json `
    -Uri "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-16T02:32:12.281Z",
  "operationType": "UPDATE",
  "name": "OPERATION_ID",
  "targetId": "INSTANCE_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Opsi untuk perubahan di tempat

Mengubah edisi instance Cloud SQL Anda dapat memerlukan perubahan seri mesinnya, yang pada gilirannya memengaruhi jenis penyimpanannya.

Perubahan mesin

Saat mengubah edisi, Anda juga harus mengubah jenis mesin. Lihat Memilih seri mesin untuk mengetahui informasi selengkapnya tentang seri mesin yang didukung Cloud SQL.

Saat mengupgrade dari edisi Cloud SQL Enterprise ke edisi Cloud SQL Enterprise Plus, Anda dapat memilih antara seri mesin N2, C4A, dan C4.

Saat melakukan downgrade dari edisi Cloud SQL Enterprise Plus ke edisi Cloud SQL Enterprise, Anda dapat memilih antara core khusus tujuan umum, dan seri mesin N4.

Anda juga dapat mengubah jenis mesin tanpa mengubah edisi. Setelah memilih untuk mengedit instance, buka subbagian Mesin di Konfigurasi Mesin di area Sesuaikan instance Anda. Dengan menggunakan drop-down, Anda dapat memilih jenis mesin lain. Anda juga dapat memilih jumlah VCPU yang berbeda, serta mengaktifkan atau menonaktifkan cache data jika sesuai.

Untuk informasi umum lainnya, lihat juga dokumentasi Compute Engine untuk seri mesin N2, C4A, C4, dan N4.

Perubahan penyimpanan

Jika Anda beralih dari seri mesin tujuan umum atau N2 ke seri mesin N4, C4A, atau C4, penyimpanan Anda akan dimigrasikan dari Solid-state drive (SSD) ke penyimpanan Google Cloud Hyperdisk seimbang. Upgrade ini umumnya memerlukan waktu non-operasional minimal.

Penyimpanan Google Cloud Hyperdisk Balanced dapat disesuaikan untuk kasus penggunaan Anda dengan menetapkan hal berikut:

• Kapasitas penyimpanan
• IOPS yang disediakan
• Throughput yang disediakan

Google Cloud Hyperdisk Balanced menetapkan nilai IOPS dan throughput default serta batas berdasarkan konfigurasi instance Anda, yang mencakup jenis mesin dan kapasitas penyimpanan. Kapasitas penyimpanan membatasi nilai default, dan jenis mesin menetapkan nilai maksimum untuk IOPS dan throughput. Lihat Memilih opsi penyimpanan untuk mengetahui detailnya.

Perubahan lokasi log biner untuk PITR

Jika instance edisi Cloud SQL Enterprise Anda menyimpan log transaksi untuk PITR di disk, memulai proses upgrade ke edisi Cloud SQL Enterprise Plus akan mengalihkan lokasi penyimpanan log ini ke Cloud Storage.

Ketentuan berikut berlaku untuk perubahan lokasi:

• Proses ini memerlukan waktu sekitar durasi setelan konfigurasi transactionLogRetentionDays PITR untuk menyelesaikan peralihan ke Cloud Storage.
• Jika Anda telah menetapkan nilai untuk flag expire_logs_days atau binlog_expire_logs_seconds di instance Anda, nilai tersebut akan dipertahankan.
• Selama peralihan ke Cloud Storage, Anda tidak dapat mengubah nilai untuk tanda expire_logs_days atau binlog_expire_logs_seconds di instance Anda.
• Selama peralihan ke Cloud Storage, sebaiknya jangan ubah setelan konfigurasi PITR transactionLogRetentionDays. Meskipun Anda meningkatkan transactionLogRetentionDays, log biner tidak akan disimpan di disk lebih lama dari default 7 hari untuk instance edisi Cloud SQL Enterprise.

• Saat peralihan sedang berlangsung, Cloud SQL hanya menyimpan log di disk untuk nilai minimum salah satu dari berikut ini:
  • Setelan konfigurasi transactionLogRetentionDays PITR dari sebelum pengalihan, yang secara default adalah 7 hari.
  • Flag expire_logs_days atau binlog_expire_logs_seconds yang ditetapkan secara manual di instance Anda.
• Setelah peralihan, Cloud SQL mempertahankan jumlah log biner yang sama di disk seperti yang Anda miliki sebelum peralihan kecuali jika Anda telah menyetel flag expire_logs_days atau binlog_expire_logs_seconds di instance Anda. Jika Anda telah menyetel flag ini, Cloud SQL akan menyimpan log biner di disk berdasarkan nilai minimum setelan konfigurasi transactionLogRetentionDays atau nilai flag.

Default penyimpanan log dan cadangan edisi Cloud SQL Enterprise Plus

Setelah peralihan ke Cloud Storage selesai untuk suatu instance, Cloud SQL tetap menyimpan salinan log biner di disk untuk tujuan replikasi. Menyimpan log biner di disk dapat berguna jika Anda ingin menjelajahi log biner dengan utilitas mysqlbinlog.

Jika Anda mengonfigurasi tanda expire_logs_days dan binlog_expire_logs_seconds di instance sebelum upgrade, nilai yang dikonfigurasi akan tetap utuh.

Setelah pengalihan, karena log biner yang digunakan untuk melakukan PITR kini disimpan di Cloud Storage, pastikan nilai flag mencerminkan retensi log transaksi di disk yang Anda harapkan. Cloud SQL hanya menyimpan log di disk untuk nilai minimum salah satu dari berikut ini:

• setelan konfigurasi PITR transactionLogRetentionDays sebelum pengalihan, 7 hari secara default
• flag expire_logs_days atau binlog_expire_logs_seconds yang ditetapkan secara manual di instance Anda

Jika Anda ingin menghemat ruang disk, setelah upgrade selesai, konfigurasi nilai flag expire_logs_days atau binlog_expire_logs_seconds ke nilai yang setara dengan 1 hari sehingga Anda dapat mengurangi ukuran disk yang dialokasikan dan biaya penyimpanan disk. Untuk mengetahui informasi selengkapnya tentang penyimpanan log transaksi dan PITR, lihat Penyimpanan log untuk PITR.

Setelah upgrade ke edisi Cloud SQL Enterprise Plus selesai, periode retensi log transaksi default untuk semua instance yang diupgrade ditingkatkan menjadi 14 hari. Untuk peningkatan ini, dan peningkatan lain yang Anda konfigurasi untuk periode retensi data log transaksi, diperlukan waktu hingga nilai baru dan yang ditingkatkan tercapai untuk mencapai periode retensi penuh PITR. Misalnya, jika nilai lama untuk hari penyimpanan log transaksi adalah 7 dan nilai baru ditingkatkan menjadi 14, maka periode PITR untuk 7 hari pertama setelah upgrade hanya 7 hari. Pada hari ke-8, periode PITR menjadi 8 hari, pada hari ke-9 menjadi 9 hari, hingga periode retensi akhirnya ditingkatkan menjadi 14 hari pada hari ke-14.

Selain itu, jumlah default cadangan otomatis ditingkatkan dari 8 menjadi 15.

Jika Anda mengupgrade ke edisi Cloud SQL Enterprise Plus setelah melakukan upgrade versi utama, Anda tidak akan dapat melakukan PITR ke point-in-time yang terjadi sebelum upgrade versi utama. Batasan ini berlaku meskipun periode retensi Anda mencakup jangka waktu tersebut. Anda dapat memulihkan instance ke point-in-time setelah Anda memulai upgrade versi utama.