Menggunakan impor terkelola untuk menyiapkan replikasi dari database eksternal

MySQL   |  PostgreSQL   |  SQL Server

Halaman ini menjelaskan cara menyiapkan dan menggunakan impor terkelola untuk data saat mereplikasi dari server eksternal ke Cloud SQL.

Anda harus menyelesaikan semua langkah di halaman ini. Setelah selesai, Anda dapat mengelola dan memantau instance representasi sumber dengan cara yang sama seperti yang Anda lakukan pada instance Cloud SQL lainnya.

Sebelum memulai

Sebelum Anda memulai, selesaikan langkah-langkah berikut:

1. Konfigurasi server eksternal.

2. Buat instance representasi sumber.

3. Siapkan replika Cloud SQL.

Memperbarui hak istimewa untuk pengguna replikasi

Pengguna replikasi di server eksternal dikonfigurasi untuk menerima koneksi dari host mana pun (%). Update akun pengguna ini agar hanya dapat digunakan dengan replika Cloud SQL.

Hak istimewa yang diperlukan

Ada empat jenis kombinasi migrasi dan dump.

• Jenis 1: Migrasi berkelanjutan dan dump terkelola
• Jenis 2: Migrasi berkelanjutan dan dump manual
• Jenis 3: Migrasi satu kali dan dump terkelola
• Jenis 4: Migrasi satu kali dan dump manual

Hak istimewa untuk setiap jenis kombinasi migrasi dan dumb tercantum di bawah ini.

Jenis 1

Akun pengguna harus memiliki hak istimewa berikut:

• SLAVE REPLIKASI
• MELAKSANAKAN
• SELECT
• TAMPILKAN TAMPILAN
• KLIEN REPLIKASI
• MUAT ULANG
• PEMBICARA
• (Khusus untuk migrasi dari Amazon RDS dan Amazon Aurora) KUNCI TABEL

Untuk MySQL versi 8.0 dan yang lebih baru, sebaiknya lewati hak istimewa BACKUP ADMIN untuk performa yang optimal.

Catatan: Untuk informasi selengkapnya tentang hak istimewa ini, lihat Hak istimewa yang diberikan oleh MySQL.

Tipe 2

Akun pengguna harus memiliki hak istimewa berikut:

• SLAVE REPLIKASI
• MELAKSANAKAN

Catatan: Untuk informasi selengkapnya tentang hak istimewa ini, lihatHak istimewa yang diberikan oleh MySQL.

Jenis 3

Akun pengguna harus memiliki hak istimewa berikut:

• SELECT
• TAMPILKAN TAMPILAN
• PEMBICARA
• (Dari bermigrasi dari sumber dengan setelan GTID_MODE = ON saja) MUAT ULANG

Untuk MySQL versi 8.0 dan yang lebih baru, sebaiknya lewati hak istimewa BACKUP ADMIN untuk performa yang optimal.

Catatan: Untuk informasi selengkapnya tentang hak istimewa ini, lihat Hak istimewa yang diberikan oleh MySQL.

Tipe 4

Tidak ada hak istimewa yang diperlukan.

Catatan: Untuk informasi selengkapnya tentang hak istimewa ini, lihat Hak istimewa yang diberikan oleh MySQL.

Perbarui hak istimewa

Untuk memperbarui hak istimewa, buka terminal di server eksternal dan masukkan perintah berikut.

Klien mysql

Untuk GTID:

    UPDATE mysql.user
      SET Host='NEW_HOST'
      WHERE Host='OLD_HOST'
      AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION_CLIENT,
    RELOAD ON . TO
    'USERNAME'@'HOST';
    FLUSH PRIVILEGES;

Untuk binlog:

    UPDATE mysql.user
    SET Host='NEW_HOST'
    WHERE Host='OLD_HOST'
    AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
    RELOAD ON . TO 'GCP_USERNAME'@'HOST';
    FLUSH PRIVILEGES;

contoh

UPDATE mysql.user
  SET Host='192.0.2.0'
  WHERE Host='%'
  AND User='replicationUser';
GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
RELOAD ON *.* TO 'username'@'host.com';
FLUSH PRIVILEGES;

Properti	Deskripsi
NEW_HOST	Tentukan IP keluar dari replika Cloud SQL.
OLD_HOST	Nilai saat ini yang ditetapkan ke Host yang ingin Anda ubah.
USERNAME	Akun pengguna replikasi di server eksternal.
GCP_USERNAME	Nama pengguna untuk akun pengguna.
HOST	Nama host untuk akun pengguna.

Memverifikasi setelan replikasi Anda

Setelah penyiapan selesai, pastikan replika Cloud SQL dapat direplikasi dari server eksternal.

Setelan sinkronisasi eksternal berikut harus benar.

• Konektivitas antara replika Cloud SQL dan server eksternal
• Hak istimewa pengguna replikasi
• Kompatibilitas versi
• Replika Cloud SQL belum direplikasi
• Binlog diaktifkan di server eksternal
• GTID diaktifkan jika Anda mencoba melakukan sinkronisasi eksternal dari server eksternal RDS dan menggunakan bucket Google Cloud

Untuk memverifikasi setelan ini, buka terminal Cloud Shell dan masukkan perintah berikut:

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/verifyExternalSyncSettings

contoh

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/myreplica/verifyExternalSyncSettings

contoh dengan tanda sinkronisasi

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/verifyExternalSyncSettings

Panggilan ini menampilkan daftar jenis sql#externalSyncSettingErrorList.

Jika daftar kosong, berarti tidak ada error. Respons tanpa error akan muncul seperti ini:

  {
    "kind": "sql#externalSyncSettingErrorList"
  }

Properti	Deskripsi
SYNC_MODE	Pastikan Anda dapat menjaga replika Cloud SQL dan server eksternal tetap sinkron setelah replikasi disiapkan. Mode sinkronisasi mencakup EXTERNAL_SYNC_MODE_UNSPECIFIED, ONLINE, dan OFFLINE.
SYNC_PARALLEL_LEVEL	Verifikasi setelan yang mengontrol kecepatan transfer data dari tabel database. Nilai berikut ini tersedia: min: Memerlukan jumlah resource komputasi terendah pada database. Ini adalah kecepatan paling lambat untuk mentransfer data. optimal: Memberikan performa yang seimbang dengan beban optimal pada database. max: Memberikan kecepatan tertinggi untuk mentransfer data, tetapi hal ini dapat menyebabkan peningkatan beban pada database. Catatan: Nilai default untuk parameter ini adalah optimal karena setelan ini memberikan kecepatan yang baik untuk mentransfer data dan memiliki dampak yang wajar pada database. Sebaiknya gunakan nilai ini.
SYNC_FLAGS	Daftar tanda sinkronisasi awal untuk diverifikasi. Hanya direkomendasikan jika Anda berencana menggunakan tanda sinkronisasi kustom saat mereplikasi dari sumber. Untuk daftar tanda yang diizinkan, lihat Tanda sinkronisasi awal.
PROJECT_ID	ID project Google Cloud Anda.
REPLICA_INSTANCE_ID	ID replika Cloud SQL Anda.

Izin kunci baca global

Jika Anda tidak memiliki izin untuk mengakses kunci baca global di server eksternal, seperti yang mungkin terjadi pada Amazon RDS dan Amazon Aurora, jeda penulisan ke server Anda seperti yang dijelaskan dalam langkah-langkah berikut:

1. Buka Logs Explorer, lalu pilih replika Cloud SQL Anda dari daftar resource. Anda akan melihat daftar log terbaru untuk replika Cloud SQL Anda. Abaikan untuk saat ini.
2. Buka terminal dan masukkan perintah di Mulai replikasi pada server eksternal untuk mereplikasi dari server eksternal.

3. Kembali ke Logs Explorer. Ketika Anda melihat log sebagai berikut, hentikan penulisan ke database di server eksternal Anda. Dalam kebanyakan kasus, ini hanya diperlukan selama beberapa detik.

      DUMP_IMPORT(START): Start importing data, please pause any write to the
      external primary database.
   

4. Ketika Anda melihat entri log berikut di Logs Explorer, aktifkan kembali penulisan ke database pada server eksternal Anda.

      DUMP_IMPORT(SYNC): Consistent state on primary and replica. Writes to the
      external primary may resume.
   
   

Memulai replikasi pada server eksternal

Setelah memverifikasi bahwa Anda dapat mereplikasi dari server eksternal, mulai replikasi. Kecepatan dalam melakukan replikasi untuk proses impor awal adalah hingga 500 GB per jam. Namun, kecepatan ini dapat bervariasi berdasarkan tingkat mesin, ukuran disk data, throughput jaringan, dan sifat database Anda.

Perhatian: Saat Anda memulai impor dari database pada layanan terkelola, seperti Amazon RDS atau Amazon Aurora, Cloud SQL akan memerintahkan Anda untuk menghentikan penulisan untuk beberapa detik agar dump data konsisten. Untuk menghindari periode nonaktif untuk penulisan ke instance utama layanan terkelola, Anda dapat memilih replika baca sebagai sumber replikasi Anda, bukan instance utama. Selama fase ketika penghentian operasi tulis diperlukan, Anda dapat menghentikan replikasi ke replika baca sumber untuk sementara lalu melanjutkan replikasi setelah fase penghentian penulisan selesai.

Selama proses impor awal, jangan lakukan operasi DDL pada server eksternal. Hal tersebut dapat menyebabkan inkonsistensi selama proses impor. Setelah proses impor selesai, replika menggunakan log biner pada server eksternal untuk mengikuti status server eksternal saat ini.

curl

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "skipVerification": "SKIP_VERIFICATION",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/startExternalSync

contoh

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync

contoh dengan tanda sinkronisasi

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "skipVerification": false,
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync

Properti	Deskripsi
SYNC_MODE	Pastikan Anda dapat menjaga replika Cloud SQL dan server eksternal tetap sinkron setelah replikasi disiapkan.
SKIP_VERIFICATION	Apakah akan melewati langkah verifikasi bawaan sebelum menyinkronkan data Anda. Parameter ini hanya direkomendasikan jika Anda telah memverifikasi setelan replikasi.
SYNC_PARALLEL_LEVEL	Menyediakan setelan yang mengontrol kecepatan transfer data dari tabel database. Nilai berikut ini tersedia: min: Memerlukan jumlah resource komputasi terendah pada database. Ini adalah kecepatan paling lambat untuk mentransfer data. optimal: Memberikan performa yang seimbang dengan beban optimal pada database. max: Memberikan kecepatan tertinggi untuk mentransfer data, tetapi hal ini dapat menyebabkan peningkatan beban pada database. Catatan: Nilai default untuk parameter ini adalah optimal karena setelan ini memberikan kecepatan yang baik untuk mentransfer data dan memiliki dampak yang wajar pada database. Sebaiknya gunakan nilai ini.
SYNC_FLAGS	Daftar tanda sinkronisasi awal untuk diverifikasi. Hanya direkomendasikan jika Anda berencana menggunakan tanda sinkronisasi kustom saat mereplikasi dari sumber. Untuk daftar tanda yang diizinkan, lihat Tanda sinkronisasi awal.
PROJECT_ID	ID project Google Cloud Anda.
REPLICA_INSTANCE_ID	ID replika Cloud SQL Anda.

Tanda sinkronisasi awal

Untuk bermigrasi dengan tanda database kustom, Anda dapat menggunakan tanda yang diizinkan berikut:

• --add-drop-database
• --add-drop-table
• --add-drop-trigger
• --add-locks
• --allow-keywords
• --all-tablespaces
• --apply-slave-statements
• --column-statistics
• --comments
• --compact
• --compatible
• --complete-insert
• --compress
• --compression-algorithms
• --create-options
• --default-character-set
• --delayed-insert
• --disable-keys
• --dump-date
• --events
• --extended-insert
• --fields-enclosed-by
• --fields-escaped-by
• --fields-optionally-enclosed-by
• --fields-terminated-by
• --flush-logs
• --flush-privileges
• --force
• --get-server-public-key
• --hex-blob
• --ignore-error
• --ignore-read-lock-error
• --ignore-table
• --insert-ignore
• --lines-terminated-by
• --lock-all-tables
• --lock-tables
• --max-allowed-packet
• --net-buffer-length
• --network-timeout
• --no-autocommit
• --no-create-db
• --no-create-info
• --no-data
• --no-defaults
• --no-set-names
• --no-tablespaces
• --opt
• --order-by-primary
• --pipe
• --quote-names
• --quick
• --replace
• --routines
• --secure-auth
• --set-charset
• --shared-memory-base-name
• --show-create-skip-secondary-engine
• --skip-opt
• --ssl-cipher
• --ssl-fips-mode
• --ssl-verify-server-cert
• --tls-ciphersuites
• --tls-version
• --triggers
• --tz-utc
• --verbose
• --xml
• --zstd-compression-level

Untuk mengetahui nilai yang diizinkan, lihat Dokumen publik MySQL.

Memonitor migrasi

Setelah memulai replikasi dari server eksternal, Anda perlu memantau replikasi. Untuk mempelajari lebih lanjut, lihat Memantau replikasi. Setelah itu, Anda dapat menyelesaikan migrasi.

Memecahkan masalah

Pertimbangkan opsi pemecahan masalah berikut:

Masalah	Pemecahan masalah
Replika baca tidak mulai direplikasi pada saat pembuatan.	Mungkin ada error yang lebih spesifik di file log. Periksa log di Cloud Logging untuk menemukan error yang sebenarnya.
Tidak dapat membuat replika baca - error invalidFlagValue.	Salah satu tanda dalam permintaan tidak valid. Ini bisa berupa tanda yang Anda berikan secara eksplisit atau tanda yang ditetapkan ke nilai default. Pertama, pastikan nilai tanda max_connections lebih besar dari atau sama dengan nilai pada tanda utama. Jika flag max_connections sudah ditetapkan dengan tepat, periksa log di Cloud Logging untuk menemukan error yang sebenarnya.
Tidak dapat membuat replika baca - error tidak diketahui.	Mungkin ada error yang lebih spesifik di file log. Periksa log di Cloud Logging untuk menemukan error yang sebenarnya. Jika error-nya adalah: set Service Networking service account as servicenetworking.serviceAgent role on consumer project, makan nonaktifkan dan aktifkan kembali Service Networking API. Tindakan ini akan membuat akun layanan yang diperlukan untuk melanjutkan prosesnya.
Disk penuh.	Ukuran disk instance utama dapat penuh selama pembuatan replika. Edit instance utama untuk mengupgradenya ke ukuran disk yang lebih besar.
Instance replika menggunakan terlalu banyak memori.	Replika menggunakan memori sementara untuk meng-cache operasi baca yang sering diminta, yang dapat menyebabkannya menggunakan lebih banyak memori daripada instance utama. Mulai ulang instance replika untuk mengklaim kembali ruang memori sementara.
Replikasi dihentikan.	Batas penyimpanan maksimum tercapai dan peningkatan penyimpanan otomatis tidak diaktifkan. Edit instance untuk mengaktifkan automatic storage increase.
Jeda replikasi selalu tinggi.	Beban tulis terlalu tinggi untuk ditangani replika. Kelambatan replikasi terjadi saat thread SQL pada replika tidak dapat mengikuti thread IO. 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 pada replika. Temukan dan perbaiki. Semua tabel harus memiliki kunci utama/unik. Setiap update pada tabel tersebut tanpa kunci utama/unik akan menyebabkan pemindaian tabel penuh pada replika tersebut. 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. Tetapkan flag innodb_flush_log_at_trx_commit pada replika baca ke 2. Lihat Tips menggunakan tanda untuk informasi selengkapnya tentang tanda ini. Edit instance untuk meningkatkan ukuran replika. Kurangi beban pada database. Kirim traffic baca ke replika baca. Indeks tabel. Iidentifikasi dan perbaiki kueri penulisan yang lambat. Buat ulang replika.
Kelambatan replikasi tiba-tiba melonjak.	Hal ini disebabkan oleh transaksi yang berjalan lama. Saat sebuah transaksi (satu pernyataan atau beberapa pernyataan) di-commit pada instance sumber,on waktu mulai transaksi dicatat dalam log biner. Saat menerima peristiwa binlog ini, replika akan membandingkan stempel waktu tersebut dengan stempel waktu saat ini untuk menghitung kelambatan replikasi. Oleh karena itu, transaksi yang berjalan lama pada sumber akan langsung mengakibatkan kelambatan replikasi yang besar pada replika. Jika jumlah perubahan baris dalam transaksi besar, replika juga akan menghabiskan waktu lama untuk menjalankannya. Selama waktu tersebut, kelambatan replikasi meningkat. Setelah replika menyelesaikan transaksi ini, periode untuk mengejar ketertinggalan akan bergantung pada beban kerja tulis pada sumber dan kecepatan pemrosesan replika. Untuk menghindari transaksi yang panjang, beberapa solusi yang memungkinkan mencakup: Memecah transaksi menjadi beberapa transaksi kecil Memotong satu kueri tulis besar menjadi beberapa batch yang lebih kecil Cobalah untuk memisahkan kueri SELECT yang panjang dari transaksi yang dicampur dengan DML
Mengubah tanda replikasi paralel akan menghasilkan error.	Nilai yang salah ditetapkan untuk salah satu atau beberapa tanda ini. Pada instance utama yang menampilkan pesan error, tetapkan tanda replikasi paralel: Ubah tanda binlog_transaction_dependency_tracking dan transaction_write_set_extraction: binlog_transaction_dependency_tracking=COMMIT_ORDER transaction_write_set_extraction=OFF Tambahkan tanda slave_pending_jobs_size_max: slave_pending_jobs_size_max=33554432 Ubah tanda transaction_write_set_extraction: transaction_write_set_extraction=XXHASH64 Ubah tanda binlog_transaction_dependency_tracking: binlog_transaction_dependency_tracking=WRITESET
Pembuatan replika gagal dengan waktu tunggu.	Transaksi tanpa komitmen yang berjalan lama pada instance utama dapat menyebabkan pembuatan replika baca gagal. Buat ulang replika setelah menghentikan semua kueri yang berjalan.

Selain itu, untuk MySQL, pertimbangkan juga opsi berikut:

Masalah	Pemecahan masalah
Lost connection to MySQL server during query when dumping table.	Sumbernya mungkin tidak tersedia, atau file dump berisi paket yang terlalu besar. Pastikan kabel primer eksternal tersedia untuk terhubung. Anda juga dapat mengubah nilai tanda net_read_timeout dan net_write_timeout pada instance sumber untuk menghentikan error. Untuk informasi selengkapnya tentang nilai yang diizinkan untuk tanda ini, lihat Mengonfigurasi tanda database. Untuk mempelajari lebih lanjut cara menggunakan tanda mysqldump untuk migrasi impor terkelola, lihat Tanda sinkronisasi awal yang diizinkan dan default
Migrasi data awal berhasil, tetapi tidak ada data yang direplikasi.	Salah satu kemungkinan penyebabnya adalah database sumber Anda telah menentukan flag replikasi yang menyebabkan beberapa atau semua perubahan database tidak direplikasi. 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 pada instance utama untuk melihat setelan saat ini.
Migrasi data awal berhasil tetapi replikasi data berhenti berfungsi setelah beberapa saat.	Hal-hal yang sebaiknya dicoba: Periksa metrik replikasi untuk instance replika Anda di bagian Cloud Monitoring pada konsol Google Cloud. Error dari thread IO MySQL atau thread SQL dapat ditemukan di Cloud Logging dalam file mysql.err log. Error ini juga dapat ditemukan saat menghubungkan ke instance replika. Jalankan perintah SHOW SLAVE STATUS, dan periksa kolom berikut dalam output: Slave_IO_Running Slave_SQL_Running Last_IO_Error Last_SQL_Error
mysqld check failed: data disk is full.	Disk data instance replika penuh. Tingkatkan ukuran disk instance replika. Anda dapat meningkatkan ukuran disk secara manual atau mengaktifkan peningkatan penyimpanan otomatis.

Meninjau log replikasi Anda

Saat Anda memverifikasi setelan replikasi, log akan dihasilkan.

Anda dapat melihat log ini dengan mengikuti langkah-langkah berikut:

1. Buka Logs Viewer di konsol Google Cloud.

   Buka Logs Viewer

2. Pilih replika Cloud SQL dari dropdown Instance.
3. Pilih file log replication-setup.log.

Jika replika Cloud SQL tidak dapat terhubung ke server eksternal, konfirmasi hal berikut:

• Setiap firewall di server eksternal akan dikonfigurasi untuk mengizinkan koneksi dari alamat IP keluar replika Cloud SQL.
• Konfigurasi SSL/TLS Anda sudah benar.
• Pengguna, host, dan sandi replikasi Anda sudah benar.

Langkah selanjutnya

• Pelajari cara mengupdate instance.
• Pelajari cara mengelola replika.
• Pelajari cara memantau instance.
• Pelajari cara mempromosikan replika Cloud SQL.