Bermigrasi dari AWS ke Google Cloud: Bermigrasi dari Amazon RDS dan Amazon Aurora untuk MySQL ke Cloud SQL untuk MySQL

Last reviewed 2024-08-16 UTC

Google Cloud menyediakan alat, produk, panduan, dan layanan profesional untuk bermigrasi dari Amazon Relational Database Service (RDS) atau Amazon Aurora ke Cloud SQL untuk MySQL.

Dokumen ini ditujukan untuk administrator cloud dan database yang ingin merencanakan, mengimplementasikan, dan memvalidasi project migrasi database. Hal ini juga dimaksudkan bagi pengambil keputusan yang sedang mengevaluasi peluang untuk bermigrasi dan menginginkan contoh tentang seperti apa migrasi itu.

Dokumen ini berfokus pada migrasi database homogen, yaitu migrasi di mana {i>database<i} sumber dan tujuan menggunakan teknologi {i>database<i} yang sama. Di beberapa panduan migrasi ini, sumbernya adalah Amazon RDS atau Amazon Aurora untuk MySQL, dan tujuannya adalah Cloud SQL untuk MySQL.

Dokumen ini adalah bagian dari rangkaian multi-bagian tentang migrasi dari AWS ke Google Cloud yang mencakup dokumen berikut:

• Mulai
• Bermigrasi dari Amazon EC2 ke Compute Engine
• Bermigrasi dari Amazon S3 ke Cloud Storage
• Bermigrasi dari Amazon EKS ke GKE
• Melakukan migrasi dari Amazon RDS dan Amazon Aurora untuk MySQL ke Cloud SQL untuk MySQL (dokumen ini)
• Bermigrasi dari Amazon RDS untuk SQL Server ke Cloud SQL untuk SQL Server

Untuk migrasi ke Google Cloud ini, sebaiknya ikuti framework migrasi yang dijelaskan di Bermigrasi ke Google Cloud: Memulai.

Diagram berikut menggambarkan jalur perjalanan migrasi Anda.

Anda mungkin bermigrasi dari lingkungan sumber ke Google Cloud dalam sebuah iterasi—misalnya, Anda mungkin memigrasikan beberapa beban kerja terlebih dahulu dan beban kerja lainnya nanti. Untuk setiap iterasi migrasi terpisah, Anda mengikuti fase framework migrasi umum:

1. Lakukan penilaian dan temukan workload dan data Anda.
2. Rencanakan dan bangun fondasi di Google Cloud.
3. Memigrasikan workload dan data Anda ke Google Cloud.
4. Mengoptimalkan lingkungan Google Cloud Anda.

Untuk mengetahui informasi selengkapnya tentang fase framework ini, lihat Bermigrasi ke Google Cloud: Memulai.

Untuk merancang rencana migrasi yang efektif, sebaiknya Anda memvalidasi setiap langkah dari rencana, dan memastikan bahwa Anda memiliki strategi rollback. Untuk membantu Anda memvalidasi rencana migrasi Anda, lihat Bermigrasi ke Google Cloud: Praktik terbaik untuk memvalidasi rencana migrasi.

Menilai lingkungan sumber

Pada fase penilaian, Anda menentukan persyaratan dan ketergantungan untuk memigrasikan lingkungan sumber Anda ke Google Cloud.

Fase penilaian sangat penting untuk keberhasilan migrasi Anda. Anda harus mendapatkan pengetahuan mendalam tentang beban kerja yang ingin Anda migrasikan, dependensi mereka, dan tentang lingkungan Anda saat ini. Anda perlu memahami titik awal agar berhasil merencanakan dan menjalankan migrasi Google Cloud.

Fase penilaian terdiri dari tugas-tugas berikut:

1. Mem-build inventaris workload yang komprehensif.
2. Membuat katalog workload Anda sesuai dengan properti dan dependensinya.
3. Latih dan ajari tim Anda di Google Cloud.
4. Buat eksperimen dan bukti konsep di Google Cloud.
5. Hitung total biaya kepemilikan (TCO) lingkungan target.
6. Pilih strategi migrasi untuk workload Anda.
7. Pilih alat migrasi Anda.
8. Tentukan jadwal dan rencana migrasi.
9. Validasi rencana migrasi Anda.

Fase penilaian {i>database<i} membantu Anda memilih ukuran dan spesifikasi instance database Cloud SQL target yang cocok dengan sumber untuk kebutuhan performa yang serupa. Berikan perhatian khusus pada ukuran dan throughput {i>disk<i}, IOPS, dan jumlah vCPU. Migrasi mungkin bermasalah atau gagal karena kesalahan menentukan ukuran instance database target. Ukuran yang salah dapat menyebabkan migrasi yang lama waktu, masalah performa database, error database, dan tingkat masalah performa. Saat menentukan instance Cloud SQL, tetap bahwa performa {i>disk<i} didasarkan pada ukuran {i>disk<i} dan jumlah vCPU.

Bagian berikut bergantung pada Bermigrasi ke Google Cloud: Menilai dan menemukan workload Anda, dan mengintegrasikan informasi dalam dokumen tersebut.

Membuat inventaris instance Amazon RDS atau Amazon Aurora

Untuk menentukan cakupan migrasi, buat inventaris dan kumpulkan informasi tentang instance Amazon RDS atau Amazon Aurora Anda. Sebaiknya Anda mengotomatiskan proses ini dengan menggunakan alat khusus, karena pendekatan manual rentan terhadap kesalahan dan dapat menyebabkan asumsi yang salah.

Amazon RDS atau Amazon Aurora dan Cloud SQL mungkin tidak memiliki fitur, spesifikasi instance, atau operasi. Beberapa fungsi mungkin berupa diimplementasikan secara berbeda atau tidak tersedia. Area perbedaan mungkin meliputi infrastruktur, penyimpanan, autentikasi dan keamanan, replikasi, pencadangan, tinggi ketersediaan, model kapasitas resource, dan fitur mesin database tertentu integrasi, dan ekstensi. Bergantung pada jenis mesin database, instance ukuran, dan arsitektur, ada juga perbedaan dalam nilai {i>default<i} setelan parameter database.

Tolok ukur dapat membantu Anda untuk lebih memahami beban kerja yang akan dimigrasikan dan berkontribusi untuk menentukan arsitektur migrasi yang tepat lingkungan target. Mengumpulkan informasi tentang kinerja adalah penting untuk membantu memperkirakan kebutuhan performa target Google Cloud lingkungan fleksibel App Engine. Konsep dan alat {i>benchmark<i} dijelaskan secara rinci di Fase Melakukan pengujian dan validasi proses migrasi, tetapi juga berlaku untuk tahap pembuatan inventaris.

Alat untuk penilaian

Sebagai penilaian awal untuk infrastruktur Anda saat ini, sebaiknya yang Anda gunakan Pusat Migrasi Google Cloud bersama dengan alat penilaian {i>database<i} khusus lainnya seperti migVisor dan Alat Penilaian Migrasi Database (DMA).

Dengan Migration Center, Anda dapat melakukan penilaian lengkap lanskap aplikasi dan database Anda, termasuk kesesuaian teknis untuk migrasi database ke Google Cloud. Anda menerima ukuran dan konfigurasi rekomendasi untuk setiap database sumber, dan membuat total biaya kepemilikan (TCO) untuk server dan database.

Untuk mengetahui informasi selengkapnya tentang cara menilai lingkungan AWS Anda menggunakan Migration Center, lihat Mengimpor data dari penyedia cloud lainnya.

Selain Migration Center, Anda dapat menggunakan migVisor. migVisor mendukung berbagai mesin {i>database<i} dan sangat cocok untuk migrasi heterogen. Sebagai pengantar migVisor, lihat ringkasan migVisor.

migVisor dapat mengidentifikasi artefak dan fitur {i>database<i} eksklusif yang tidak kompatibel yang dapat menyebabkan {i>default<i} migrasi, dan dapat mengarahkan ke solusi. migVisor dapat juga merekomendasikan solusi target Google Cloud, termasuk ukuran awal dan tentang arsitektur ini.

Output penilaian database migVisor memberikan hal berikut:

• Penemuan dan analisis komprehensif dari deployment database saat ini.
• Laporan mendetail tentang kompleksitas migrasi, berdasarkan pada kepemilikan fitur yang digunakan oleh {i>database<i} Anda.
• Laporan keuangan dengan detail tentang penghematan biaya setelah migrasi, migrasi biaya, dan anggaran operasi yang baru.
• Rencana migrasi bertahap untuk memindahkan database dan aplikasi terkait dengan gangguan minimal terhadap bisnis.

Untuk melihat beberapa contoh output penilaian, lihat migVisor - Alat penilaian migrasi Cloud.

Perhatikan bahwa migVisor meningkatkan penggunaan server database untuk sementara. Biasanya, beban tambahan ini kurang dari 3%, dan dapat dijalankan di luar puncak dalam jam kerja lokal mereka.

Output penilaian migVisor membantu Anda membuat inventaris lengkap RDS Anda instance Compute Engine. Laporan ini mencakup properti umum (versi mesin {i>database<i} dan edisi, CPU, dan ukuran memori), serta detail tentang topologi {i>database<i}, kebijakan cadangan, setelan parameter, dan penyesuaian khusus yang sedang digunakan.

Jika Anda lebih suka menggunakan alat {i>open source<i}, Anda dapat menggunakan skrip pengumpul data dengan (atau sebagai ganti dari) alat yang disebutkan. Skrip ini dapat membantu Anda mengumpulkan informasi (tentang beban kerja, fitur, objek database, dan kode database) serta membangun inventaris {i>database<i}. Selain itu, skrip biasanya menyediakan database terperinci penilaian migrasi, termasuk estimasi upaya migrasi.

Kami merekomendasikan alat {i>open source<i} DMA, yang dibuat oleh teknisi Google. Menawarkan database yang lengkap dan akurat penilaian, termasuk fitur yang digunakan, logika database, dan objek database (termasuk skema, tabel, tampilan, fungsi, pemicu, dan data prosedur).

Untuk menggunakan DMA, download skrip pengumpulan untuk mesin database Anda dari Repositori Git, dan ikuti petunjuknya. Kirim file output ke Google Cloud untuk analisis data. Google Cloud membuat dan mengirimkan pembacaan penilaian database, serta memberikan langkah selanjutnya dalam perjalanan migrasi.

Mengidentifikasi dan mendokumentasikan cakupan migrasi dan periode nonaktif yang terjangkau

Pada tahap ini, Anda mendokumentasikan informasi penting yang memengaruhi strategi dan alat migrasi. Sekarang, Anda dapat menjawab pertanyaan pertanyaan:

• Apakah database Anda lebih besar dari 5 TB?
• Apakah ada tabel besar dalam {i>database<i} Anda? Apakah lebih besar dari 16 TB?
• Lokasi database (region dan zona), dan apa saja yang dekat dengan aplikasi?
• Seberapa sering data berubah?
• Apa model konsistensi data Anda?
• Apa saja opsi untuk database tujuan?
• Seberapa kompatibelkah database sumber dan tujuan?
• Apakah data harus berada di beberapa lokasi fisik?
• Apakah ada data yang dapat dikompresi dan diarsipkan, atau ada data yang tidak membutuhkan migrasi sama sekali?

Untuk menentukan cakupan migrasi, tentukan data yang akan disimpan dan yang akan dimigrasikan. Bermigrasi semua {i>database<i} Anda mungkin membutuhkan waktu dan upaya yang cukup besar. Beberapa data mungkin tetap berada di cadangan database sumber. Misalnya, tabel {i>logging<i} lama atau data arsip mungkin tidak diperlukan. Atau, Anda mungkin memutuskan untuk memindahkan data setelah proses migrasi, tergantung pada strategi dan alat Anda.

Tetapkan dasar migrasi data yang membantu Anda membandingkan dan mengevaluasi terhadap hasil dan dampaknya. Dasar pengukuran ini adalah titik referensi yang mewakili sebelum dan sesudah migrasi serta membantu Anda mengambil keputusan. Penting untuk melakukan pengukuran di lingkungan sumber yang dapat membantu Anda mengevaluasi keberhasilan migrasi data Anda. Pengukuran tersebut mencakup berikut ini:

• Ukuran dan struktur data Anda.
• Kelengkapan dan konsistensi data Anda.
• Durasi dan performa transaksi bisnis yang paling penting dan proses.

Tentukan berapa lama periode nonaktif yang dapat Anda lakukan. Apa saja dampak bisnis dari periode nonaktif? Apakah ada periode aktivitas {i>database<i} rendah, di mana ada lebih sedikit pengguna yang terpengaruh oleh periode nonaktif? Jika ya, berapa lama periode tersebut dan kapan hal itu terjadi? Pertimbangkan untuk memiliki periode nonaktif hanya tulis sebagian, sedangkan hanya baca semua permintaan tetap dilayani.

Menilai proses deployment dan administrasi Anda

Setelah Anda membangun inventaris, nilai operasional dan deployment proses untuk {i>database<i} Anda untuk menentukan bagaimana Anda perlu mengadaptasinya memfasilitasi migrasi. Proses-proses ini mendasar bagaimana Anda mempersiapkan dan memelihara lingkungan produksi.

Pertimbangkan cara Anda menyelesaikan tugas-tugas berikut:

• Tentukan dan terapkan kebijakan keamanan untuk instance Anda: Untuk misalnya, Anda mungkin perlu mengganti Amazon Security Groups. Anda dapat menggunakan Peran IAM Google, aturan firewall VPC, dan Kontrol Layanan VPC untuk mengontrol akses ke instance Cloud SQL Anda dan membatasi data dalam VPC.

• Menambahkan patch dan mengonfigurasi instance Anda: Alat deployment yang ada mungkin perlu diperbarui. Misalnya, Anda mungkin menggunakan di grup parameter Amazon atau grup opsi Amazon. Alat penyediaan Anda mungkin perlu disesuaikan untuk menggunakan Cloud Storage atau Secret Manager untuk membaca daftar konfigurasi Anda.

• Mengelola infrastruktur pemantauan dan pemberitahuan: Kategori metrik untuk instance database sumber Amazon Anda memberikan kemampuan observasi selama proses migrasi. Kategori metrik mungkin mencakup Amazon CloudWatch, Insight Performa, Pemantauan yang Ditingkatkan, dan daftar proses OS.

Menyelesaikan penilaian

Setelah Anda membuat inventaris dari Amazon RDS atau Amazon Aurora lingkungan, selesaikan sisa kegiatan fase penilaian sebagai dijelaskan dalam Bermigrasi ke Google Cloud: Menilai dan menemukan workload Anda.

Merencanakan dan membangun fondasi Anda

Pada fase perencanaan dan build, Anda akan menyediakan dan mengonfigurasi infrastruktur untuk melakukan hal berikut:

• Dukung workload Anda di lingkungan Google Cloud.
• Menghubungkan lingkungan sumber dan lingkungan Google Cloud Anda ke menyelesaikan migrasi.

Fase perencanaan dan build terdiri dari tugas-tugas berikut:

1. Buat hierarki resource.
2. Mengonfigurasi Identity and Access Management (IAM) Google Cloud.
3. Menyiapkan penagihan.
4. Menyiapkan konektivitas jaringan.
5. Perketat keamanan Anda.
6. Siapkan logging, pemantauan, dan pemberitahuan.

Untuk informasi selengkapnya tentang setiap tugas ini, lihat Bermigrasi ke Google Cloud: Rencanakan dan bangun dasar Anda.

Jika Anda berencana menggunakan Database Migration Service untuk migrasi, lihat Metode jaringan untuk MySQL untuk memahami konfigurasi jaringan yang tersedia untuk skenario migrasi.

Pemantauan dan pemberitahuan

Gunakan Google Cloud Monitoring, yang mencakup dasbor standar untuk beberapa produk Google Cloud, termasuk dasbor pemantauan Cloud SQL. Atau, Anda dapat sebaiknya gunakan solusi pemantauan pihak ketiga yang terintegrasi dengan Google Cloud, seperti Datadog dan Splunk. Untuk informasi selengkapnya, lihat Tentang kemampuan observasi database.

Memigrasikan instance Amazon RDS dan Amazon Aurora untuk MySQL ke Cloud SQL untuk MySQL

Untuk memigrasikan instance, Anda melakukan langkah-langkah berikut:

1. Pilih strategi migrasi: replikasi berkelanjutan atau terjadwal dan pemeliharaan mesin.

2. Pilih alat migrasi, tergantung pada strategi yang Anda pilih dan lainnya.

3. Menentukan rencana dan linimasa migrasi untuk setiap migrasi database, termasuk tugas persiapan dan pelaksanaan.

4. Menentukan tugas persiapan yang harus dilakukan untuk memastikan migrasi {i>tool<i} tersebut dapat bekerja dengan baik.

5. Menentukan tugas eksekusi, yang mencakup aktivitas kerja yang menerapkan migrasi.

6. Tentukan skenario penggantian untuk setiap tugas eksekusi.

7. Melakukan pengujian dan validasi, yang dapat dilakukan dalam staging terpisah lingkungan fleksibel App Engine.

8. Lakukan migrasi.

9. Melakukan migrasi sistem produksi.

10. Bersihkan lingkungan sumber dan konfigurasikan instance target.

11. Melakukan penyesuaian dan pengoptimalan.

Setiap fase dijelaskan di bagian berikut.

Memilih strategi migrasi

Pada langkah ini, Anda memiliki informasi yang cukup untuk dievaluasi dan memilih salah satu mengikuti strategi migrasi yang paling sesuai dengan kasus penggunaan Anda untuk {i>database<i}:

• Pemeliharaan terjadwal (juga disebut migrasi satu kali): Pendekatan ini ideal jika Anda mampu memberikan waktu henti. Opsi ini relatif lebih murah dan kompleksitasnya, karena workload dan layanan Anda tidak memerlukan banyak pemfaktoran ulang. Namun, jika migrasi gagal sebelum selesai, Anda harus memulai ulang proses, yang memperpanjang waktu henti.

• Replikasi berkelanjutan (juga disebut migrasi trickle): Untuk dalam database sangat penting, opsi ini menawarkan risiko kehilangan data yang lebih rendah dan periode nonaktif yang nyaris nol. Upaya tersebut dibagi menjadi beberapa bagian, jadi jika terjadi kegagalan, {i>rollback<i} dan pengulangan membutuhkan waktu yang lebih singkat. Namun, pengaturan lebih rumit dan membutuhkan lebih banyak perencanaan dan waktu. Upaya tambahan juga yang diperlukan untuk memfaktorkan ulang aplikasi yang terhubung ke database instance Compute Engine. Pertimbangkan salah satu variasi berikut:

  • Menggunakan Y (menulis dan membaca) yakni bentuk migrasi paralel, yang menduplikasi data di kedua platform dan instance tujuan selama migrasi.
  • Menggunakan microservice akses data, yang mengurangi upaya pemfaktoran ulang yang diperlukan oleh pendekatan Y (menulis dan membaca).

Untuk informasi selengkapnya tentang strategi migrasi data, lihat Mengevaluasi pendekatan migrasi data.

Diagram berikut menunjukkan diagram alir berdasarkan contoh pertanyaan yang Anda saat menentukan strategi migrasi untuk satu database:

Diagram alir sebelumnya menunjukkan poin keputusan berikut:

• Apakah Anda mampu memberikan waktu nonaktif?

  • Jika tidak, gunakan strategi migrasi replikasi berkelanjutan.
  • Jika ya, lanjutkan ke poin keputusan berikutnya.

• Bisakah Anda menanggung periode nonaktif yang diwakili oleh periode cut-over saat memigrasikan data? Batas waktu {i>cut-over<i} menunjukkan jumlah waktu yang dibutuhkan cadangan database, mentransfernya ke Cloud SQL, memulihkannya, dan kemudian beralih aplikasi Anda.

  • Jika tidak, gunakan strategi migrasi replikasi berkelanjutan.
  • Jika ya, gunakan strategi migrasi pemeliharaan terjadwal.

Strategi dapat bervariasi untuk {i>database<i} yang berbeda, bahkan ketika strategi tersebut berada di instance yang sama. Kombinasi strategi dapat memberikan hasil yang optimal. Misalnya, memigrasikan database yang kecil dan jarang digunakan dengan menggunakan pemeliharaan terjadwal pendekatan yang berbeda, tetapi menggunakan replikasi berkelanjutan untuk {i>database<i} yang sangat penting di mana mengalami {i>downtime<i} adalah biaya yang mahal.

Biasanya, migrasi dianggap selesai ketika peralihan antara instance sumber awal dan instance target berlangsung. Tiap replikasi (jika digunakan) dihentikan dan semua pembacaan dan penulisan dilakukan pada instance target. Beralih saat kedua instance dalam proses sinkronisasi berarti tidak ada kehilangan data dan akan minimal periode nonaktif.

Untuk informasi selengkapnya tentang strategi dan deployment migrasi data, lihat Klasifikasi migrasi database.

Meminimalkan periode nonaktif dan dampak terkait migrasi

Konfigurasi migrasi yang tidak menyediakan periode nonaktif aplikasi memerlukan pengaturan yang rumit. Temukan keseimbangan yang tepat antara kompleksitas penyiapan dan periode nonaktif dijadwalkan selama jam kerja dengan traffic rendah.

Setiap strategi migrasi memiliki konsekuensi dan beberapa dampak yang terkait dengan proses migrasi. Misalnya, proses replikasi melibatkan beberapa instance sumber Anda, dan aplikasi Anda mungkin terpengaruh oleh dan replikasi akan terhambat. Aplikasi (dan pelanggan) mungkin harus menunggu selama periode nonaktif aplikasi, setidaknya selama jeda replikasi berlangsung sebelum menggunakan {i>database<i} baru. Dalam praktiknya, faktor-faktor berikut dapat meningkatkan periode nonaktif:

• Kueri database dapat memerlukan waktu beberapa detik untuk diselesaikan. Pada saat migrasi, kueri yang sedang berlangsung mungkin dibatalkan.
• {i>Cache<i} mungkin butuh waktu hingga penuh jika {i>database<i} berukuran besar atau memiliki memori buffer yang besar.
• Aplikasi dihentikan di sumber dan dimulai ulang di Google Cloud mungkin mengalami sedikit keterlambatan hingga koneksi ke Google Cloud instance database dibuat.
• Rute jaringan ke aplikasi harus diubah rutenya. Tergantung cara Entri DNS sudah disiapkan, ini bisa memakan waktu. Saat Anda memperbarui DNS data, kurangi TTL sebelum migrasi.

Praktik umum berikut dapat membantu meminimalkan periode nonaktif dan dampaknya:

• Temukan jangka waktu saat periode nonaktif akan berdampak minimal pada sebagian besar workload standar dan berbasis cloud. Misalnya, di luar jam kerja normal, selama akhir pekan, atau masa pemeliharaan terjadwal lainnya.
• Identifikasi bagian dari beban kerja Anda yang dapat mengalami migrasi dan batas waktu produksi pada berbagai tahap. Aplikasi Anda mungkin memiliki berbagai komponen yang dapat diisolasi, diadaptasi, dan dimigrasikan tanpa yang efektif. Misalnya, frontend, modul CRM, layanan backend, dan platform pelaporan. Modul semacam itu dapat memiliki {i>database<i} mereka sendiri yang dapat dijadwalkan untuk migrasi lebih awal atau lebih lambat.
• Jika Anda dapat membeli beberapa latensi pada database target, pertimbangkan menerapkan migrasi bertahap. Gunakan transfer data inkremental secara bertahap, dan menyesuaikan sebagian workload agar dapat bekerja dengan data yang sudah usang pada target di instance Compute Engine.
• Pertimbangkan untuk memfaktorkan ulang aplikasi Anda guna mendukung migrasi yang minimal yang efektif. Misalnya, adaptasikan aplikasi Anda untuk menulis ke bahasa sumber dan target database, dan karena itu menerapkan replikasi tingkat aplikasi.

Pilih alat migrasi Anda

Faktor terpenting untuk keberhasilan migrasi adalah memilih lokasi yang tepat alat migrasi. Setelah strategi migrasi ditentukan, tinjau dan putuskan pada alat migrasi.

Ada banyak alat yang tersedia, masing-masing dioptimalkan untuk kasus penggunaan migrasi tertentu. Kasus penggunaan dapat mencakup hal berikut:

• Strategi migrasi (pemeliharaan terjadwal atau replikasi berkelanjutan).
• Mesin database sumber dan target serta versi mesin.
• Lingkungan tempat instance sumber dan instance target berada.
• Ukuran database. Semakin besar {i>database<i}, semakin banyak waktu yang dibutuhkan untuk memigrasikan cadangan awal.
• Frekuensi perubahan database.
• Ketersediaan untuk menggunakan layanan terkelola untuk migrasi.

Untuk memastikan migrasi dan cut-over yang lancar, Anda dapat menggunakan deployment aplikasi pola, orkestrasi infrastruktur, dan aplikasi migrasi kustom. Namun, alat khusus yang disebut layanan migrasi terkelola dapat memfasilitasi proses pemindahan data, aplikasi, atau bahkan seluruh infrastruktur dari satu lingkungan Anda ke lingkungan lain. Mereka menjalankan ekstraksi data dari {i>database<i} sumber, memindahkan data ke database target dengan aman, dan secara opsional dapat memodifikasi data selama pengiriman. Dengan kemampuan ini, model ini merangkum logika yang kompleks migrasi dan menawarkan kemampuan pemantauan migrasi.

Layanan migrasi terkelola memberikan keuntungan berikut:

• Meminimalkan periode nonaktif: Layanan menggunakan replikasi bawaan kemampuan mesin {i>database<i} jika tersedia, dan melakukan promosi replika.

• Memastikan integritas dan keamanan data: Data disimpan dengan aman dan ditransfer secara andal dari sumber ke database tujuan.

• Memberikan pengalaman migrasi yang konsisten: Migrasi yang berbeda teknik dan pola yang sama dapat dikonsolidasikan menjadi antarmuka dengan menggunakan {i>executable<i} migrasi {i>database<i}, yang dapat Anda kelola dan memantau.

• Menawarkan model migrasi yang tangguh dan terbukti: Database migrasi adalah peristiwa yang jarang terjadi tetapi merupakan peristiwa kritis. Untuk menghindari kesalahan pemula dengan solusi yang ada, Anda dapat menggunakan alat bantu dari pakar, alih-alih membangun solusi khusus.

• Mengoptimalkan biaya: Biaya layanan migrasi terkelola mungkin lebih mahal lebih efektif daripada menyediakan server dan sumber daya tambahan untuk solusi migrasi.

Bagian selanjutnya menjelaskan rekomendasi alat migrasi, yang bergantung pada strategi migrasi yang dipilih.

Alat untuk migrasi pemeliharaan terjadwal

Diagram berikut menunjukkan diagram alir dengan pertanyaan yang dapat membantu Anda memilih alat migrasi untuk satu database, saat Anda menggunakan migrasi pemeliharaan terjadwal strategi:

Diagram alir sebelumnya menunjukkan poin keputusan berikut:

• Apakah Anda lebih memilih layanan migrasi terkelola?
  • Jika ya, sebaiknya gunakan Database Migration Service.
  • Jika tidak, sebaiknya lakukan migrasi menggunakan cadangan bawaan mesin database.

Menggunakan layanan migrasi terkelola memberikan beberapa keuntungan, yaitu yang dibahas dalam Memilih alat migrasi Anda dari dokumen ini.

Subbagian berikut menjelaskan alat yang dapat digunakan untuk satu kali migrasi, beserta keterbatasan dan praktik terbaiknya.

Database Migration Service untuk migrasi pemeliharaan terjadwal

Database Migration Service mengelola replikasi sinkronisasi awal dan pengambilan data perubahan berkelanjutan (CDC), dan menyediakan status operasi migrasi.

Dengan Database Migration Service, Anda bisa membuat tugas migrasi yang dapat dikelola dan memverifikasi. Sebaiknya Anda menggunakan Database Migration Service, karena layanan ini mendukung migrasi ke Cloud SQL untuk MySQL melalui tugas migrasi satu kali. Untuk {i>database<i} berukuran besar, Anda dapat menggunakan paralelisme data dump di Database Migration Service.

Untuk informasi selengkapnya tentang arsitektur migrasi database dan tentang Database Migration Service, lihat Memigrasikan database ke Cloud SQL untuk MySQL menggunakan Database Migration Service dan Fidelitas migrasi untuk MySQL.

Untuk informasi selengkapnya tentang batasan dan prasyarat Database Migration Service, lihat berikut ini:

• Batasan umum dalam Database Migration Service.
• Kuota dan batas di Database Migration Service.
• Konfigurasi sumber Anda di Database Migration Service.

Cadangan mesin database bawaan

Jika periode nonaktif yang signifikan dapat diterima, dan database sumber Anda dapat relatif statis, Anda dapat menggunakan file dump dan load balancing bawaan mesin database (terkadang juga disebut pencadangan dan pemulihan).

Beberapa upaya diperlukan untuk pengaturan dan sinkronisasi, terutama untuk jumlah database, tetapi cadangan mesin {i>database<i} biasanya sudah tersedia dan mudah digunakan.

Cadangan mesin database memiliki batasan umum berikut:

• Pencadangan dapat rentan error, terutama jika dilakukan secara manual.
• Data tidak aman jika cadangan tidak dikelola dengan benar.
• Cadangan tidak memiliki kemampuan pemantauan yang tepat.
• Upaya diperlukan untuk melakukan penskalaan, jika banyak {i>database<i} yang dimigrasikan menggunakan alat ini.

Jika Anda memilih pendekatan ini, pertimbangkan batasan-batasan berikut dan cara terbaik praktik:

• Jika database Anda relatif kecil (di bawah 10 GB), sebaiknya gunakan mysqldump. Tidak ada batas tetap, tetapi ukuran database yang ideal untuk mysqldump biasanya di bawah 10 GB.

• Jika Anda mengimpor database yang berukuran lebih besar dari 10 GB, Anda mungkin memerlukan beberapa dan strategi untuk meminimalkan waktu henti database. Beberapa strateginya adalah sebagai berikut:

  • Ekspor skema dan data di subbagian, tanpa kunci sekunder.
  • Manfaatkan stempel waktu. Jika salah satu tabel Anda menggunakan stempel waktu Anda dapat menggunakan fitur perintah {i>mysqldump<i} yang memungkinkan Anda tentukan klausa WHERE untuk memfilter berdasarkan kolom stempel waktu.
  • Pertimbangkan pendekatan lain seperti menggunakan mydumper dan myloader alat.

Dump dan cadangan database biasanya tidak mencakup akun pengguna MySQL. Kapan bersiap untuk melakukan migrasi, tinjau semua akun pengguna di instance sumber. Sebagai Anda dapat menjalankan perintah SHOW GRANTS untuk setiap pengguna guna meninjau sekumpulan hak istimewa saat ini dan lihat apakah ada yang dibatasi di yang disebut Cloud SQL. Demikian pula, pt-show-grants dari Percona juga dapat mencantumkan hibah.

Pembatasan pada hak istimewa pengguna di Cloud SQL dapat memengaruhi migrasi saat memigrasikan objek database yang memiliki atribut DEFINER. Sebagai contoh, prosedur yang disimpan mungkin memiliki {i>definer <i} yang super istimewa untuk menjalankan perintah SQL mengubah variabel global yang tidak diizinkan di Cloud SQL. Untuk kasus seperti ini, Anda mungkin perlu menulis ulang kode prosedur yang tersimpan atau non-tabel seperti prosedur yang disimpan sebagai langkah migrasi terpisah. Untuk selengkapnya informasi, memeriksa Praktik terbaik untuk mengimpor dan mengekspor data.

Untuk bacaan lebih lanjut tentang batasan dan praktik terbaik, lihat berikut ini:

• Cloud SQL untuk MySQL tentang pengguna.
• Praktik terbaik untuk mengimpor dan mengekspor data dengan Cloud SQL untuk MySQL.
• Masalah Umum Cloud SQL untuk MySQL.

Pendekatan lain untuk migrasi pemeliharaan terjadwal

Sebagai bagian dari penggunaan impor terkelola untuk menyiapkan replikasi dari MySQL eksternal dalam {i>database<i}, ada pemuatan awal data dari {i>database<i} eksternal ke instance Cloud SQL. Pendekatan ini menggunakan layanan yang mengekstrak data dari server eksternal - dalam hal ini {i>instance<i} RDS - dan mengimpornya ke instance Cloud SQL secara langsung.

Untuk database besar (berukuran beberapa TB), cara yang lebih cepat adalah menggunakan impor kustom pemuatan awal yang menggunakan alat mydumper dan myloader.

Pertimbangkan untuk mengekspor tabel dari database MySQL Anda ke file CSV, yang kemudian dapat diimpor ke Cloud SQL untuk MySQL. Untuk mengekspor data dari instance RDS, Anda dapat menggunakan AWS Database Migration Service (AWS DMS) dan bucket S3 sebagai target.

Untuk informasi selengkapnya dan langkah-langkahnya, lihat Menggunakan impor terkelola untuk menyiapkan replikasi dari database eksternal.

Alat untuk migrasi replikasi berkelanjutan

Diagram berikut menunjukkan diagram alir dengan pertanyaan yang dapat membantu Anda memilih alat migrasi untuk satu database, saat Anda menggunakan replikasi berkelanjutan strategi migrasi:

Diagram alir sebelumnya menunjukkan poin keputusan berikut:

• Apakah Anda lebih suka menggunakan layanan migrasi terkelola?

  • Jika ya, dapatkah Anda memberikan waktu henti operasi tulis selama beberapa detik, tergantung pada jumlah tabel dalam {i>database<i} Anda?

    • Jika ya, gunakan Database Migration Service.
    • Jika tidak, pelajari opsi migrasi lainnya.

  • Jika tidak, Anda harus mengevaluasi apakah replikasi bawaan mesin database didukung:

    • Jika ya, sebaiknya gunakan replikasi bawaan.
    • Jika tidak, sebaiknya Anda mempelajari opsi migrasi lainnya.

Bagian berikut ini menjelaskan alat-alat yang dapat digunakan untuk migrasi, beserta keterbatasan dan praktik terbaiknya.

Database Migration Service untuk migrasi replikasi berkelanjutan

Database Migration Service memberikan dukungan yang lancar untuk migrasi berkelanjutan melalui penggunaan jenis tugas migrasi berkelanjutan. Hanya tugas migrasi berkelanjutan yang dapat dipromosikan, yang menandakan replikasi untuk berhenti.

Jika Anda memilih alat ini, pertimbangkan batasan berikut dan sebaiknya praktik:

• Hindari transaksi yang berjalan lama selama migrasi. Dalam kasus tersebut, sebaiknya migrasi dari replika baca jika Anda tidak bermigrasi dari AWS Aurora.
• Untuk daftar lengkap batasan, lihat Batasan umum.

Replikasi bawaan mesin database

Replikasi bawaan mesin database adalah opsi alternatif untuk Database Migration Service untuk migrasi berkelanjutan.

Replikasi {i>database<i} mewakili proses penyalinan dan distribusi data dari database yang disebut {i>database<i} utama ke {i>database<i} lain yang disebut replika. Penting dimaksudkan untuk meningkatkan aksesibilitas data dan meningkatkan fault tolerance serta keandalan suatu sistem {i>database<i}. Meskipun migrasi database bukan replikasi database, ia dapat berhasil digunakan sebagai alat untuk mencapai sasaran ini. Replikasi {i>database<i} biasanya merupakan proses berkelanjutan yang terjadi secara {i>real time<i} saat data disisipkan, diperbarui, atau dihapus di di skrip untuk menyiapkan database. Hal ini dapat dilakukan sebagai operasi satu kali, atau serangkaian operasional bisnis.

Sebagian besar mesin database modern menerapkan berbagai cara untuk mencapai database replikasi. Salah satu jenis replikasi dapat dicapai dengan menyalin dan mengirimkan menulis log atau log transaksi utama ke replikanya. Pendekatan ini disebut replikasi fisik atau biner. Jenis replikasi lainnya bekerja dengan mendistribusikan pernyataan SQL mentah yang diterima {i>database<i} utama, bukan mereplikasi perubahan tingkat sistem file.

Cloud SQL mendukung replikasi untuk MySQL. Namun, ada beberapa prasyarat dan batasan,

Prasyarat:

• Pastikan Anda menggunakan MySQL 5.5, 5.6, 5.7, atau 8.0 di Amazon Anda instance RDS atau Amazon Aurora.
• Pastikan log biner diaktifkan.
• Untuk mempercepat fase dump penuh awal, pilih mesin yang cukup besar dari perspektif ukuran CPU dan memori.
• Jika Anda perlu mempercepat fase CDC, Anda dapat mencoba mengonfigurasi replikasi paralel dan aktifkan proses flushing berperforma tinggi.
• Jika replika Cloud SQL diaktifkan dengan alamat IP internal karena alamat IP keluar tidak statis, konfigurasikan Amazon Firewall server RDS atau Amazon Aurora untuk mengizinkan rentang IP internal yang dialokasikan untuk akses layanan pribadi dari jaringan VPC yang yang digunakan replika Cloud SQL sebagai jaringan pribadinya. Untuk informasi selengkapnya, lihat Tentang mereplikasi dari server eksternal dan Mengonfigurasi akses layanan pribadi.

Batasan:

• Jika Anda memiliki satu tabel besar dan banyak indeks sekunder di {i>database<i}, dump penuh awal mungkin memerlukan waktu lebih lama.
• Jika server eksternal Anda berisi klausul DEFINER (tampilan, acara, pemicu, atau prosedur tersimpan), tergantung pada urutan telah dijalankan, replikasi mungkin akan gagal. Pelajari lebih lanjut DEFINER penggunaan dan solusi potensial dalam Cloud SQL.
• InnoDB adalah satu-satunya mesin database yang didukung di Cloud SQL. Memigrasikan MyISAM dapat menyebabkan inkonsistensi data dan memerlukan validasi data. Lihat Mengonversi tabel dari MyISAM ke InnoDB.

Pendekatan lain untuk migrasi replikasi berkelanjutan

Pendekatan migrasi replikasi berkelanjutan lainnya mencakup hal berikut:

• Faktorkan ulang aplikasi Anda untuk melakukan Y (menulis dan membaca) atau gunakan microservice akses data.

  • Replikasi berkelanjutan dilakukan oleh aplikasi Anda.
  • Upaya migrasi difokuskan pada pemfaktoran ulang atau pengembangan yang terhubung ke instance database Anda.
  • Aplikasi pembaca kemudian difaktorkan ulang dan di-deploy secara bertahap untuk menggunakan instance target.

• Replikasikan perubahan yang mendekati real-time dari instance MySQL Anda dengan menggunakan Aliran data.

  • Datastream adalah layanan CDC dan replikasi serverless yang dapat digunakan dengan Amazon RDS atau Amazon Aurora untuk mereplikasi dan menyinkronkan data.
  • Gunakan Datastream untuk mereplikasi perubahan dari instance MySQL Anda untuk BigQuery atau Cloud Storage, lalu menggunakan Dataflow atau Dataproc untuk memasukkan data ke instance Cloud SQL Anda.

Untuk mengetahui informasi selengkapnya tentang replikasi dengan Datastream, lihat berikut ini:

• Mengonfigurasi database Amazon RDS untuk MySQL di Datastream
• Mengonfigurasi database MySQL Amazon Aurora di Datastream
• Menstreaming perubahan pada data secara real time dengan Datastream

Alat pihak ketiga untuk migrasi replikasi berkelanjutan

Dalam beberapa kasus, mungkin lebih baik menggunakan satu alat pihak ketiga untuk sebagian besar database mesin Linux dan Windows. Kasus tersebut mungkin terjadi jika Anda lebih suka menggunakan layanan migrasi terkelola dan Anda perlu memastikan bahwa database target selalu melakukan sinkronisasi mendekati real-time dengan sumber, atau jika Anda memerlukan transformasi yang lebih kompleks seperti pembersihan, restrukturisasi, dan adaptasi selama proses migrasi.

Jika Anda memutuskan untuk menggunakan alat pihak ketiga, pilih salah satu opsi berikut rekomendasi, yang dapat Anda gunakan untuk sebagian besar mesin database.

Seri adalah platform dalam memori end-to-end untuk mengumpulkan, memfilter, mengubah, memperkaya, menggabungkan, menganalisis, dan mengirimkan data secara real time:

• Kelebihan:

  • Menangani migrasi kompleks dan volume data yang besar.
  • Pengambilan data perubahan bawaan untuk SQL Server.
  • Template koneksi dan pipeline tanpa kode yang telah dikonfigurasi sebelumnya.
  • Mampu menangani {i>database<i} yang sangat penting dan beroperasi dengan beban transaksional yang berat.
  • Pengiriman tepat satu kali.

• Kekurangan:

  • Bukan sumber terbuka.
  • Biayanya bisa menjadi mahal, terutama untuk migrasi yang panjang.
  • Beberapa batasan dalam operasi bahasa definisi data (DDL) propagasi. Untuk informasi selengkapnya, lihat Operasi DDL yang didukung dan Catatan dan batasan evolusi skema.

Untuk informasi selengkapnya tentang Striim, lihat Menjalankan Striim di Google Cloud.

Debezium adalah platform terdistribusi {i>open source<i} untuk CDC, dan dapat mengalirkan perubahan data ke pelanggan eksternal:

• Kelebihan:

  • Sumber terbuka.
  • Dukungan komunitas yang kuat.
  • Hemat biaya.
  • Kontrol terperinci pada baris, tabel, atau database.
  • Dirancang khusus untuk menangkap perubahan secara real time dari log transaksi database.

• Kekurangan:

  • Memerlukan pengalaman khusus dengan Kafka dan ZooKeeper.
  • Pengiriman perubahan data setidaknya satu kali, yang berarti bahwa Anda memerlukan penanganan duplikasi.
  • Penyiapan pemantauan manual menggunakan Grafana dan Prometheus.
  • Tidak ada dukungan untuk replikasi batch inkremental.

Untuk informasi selengkapnya tentang migrasi Debezium, lihat Replikasi Data Hampir Real Time menggunakan Debezium.

Fivetran adalah platform perpindahan data otomatis untuk memindahkan data dari dan di seluruh data cloud di berbagai platform Google.

• Kelebihan:

  • Template koneksi dan pipeline tanpa kode yang telah dikonfigurasi sebelumnya.
  • Menyebarkan perubahan skema apa pun dari sumber Anda ke database target.
  • Pengiriman data Anda berubah tepat satu kali, yang berarti Anda tidak memerlukan penanganan duplikasi.

• Kekurangan:

  • Bukan sumber terbuka.
  • Dukungan untuk transformasi data yang kompleks terbatas.

Menentukan rencana dan jadwal migrasi

Agar migrasi database dan cuti produksi berhasil, sebaiknya Anda mempersiapkan rencana migrasi yang jelas dan komprehensif. Untuk membantu mengurangi dampak terhadap bisnis Anda, sebaiknya Anda membuat daftar item pekerjaan yang diperlukan.

Menentukan cakupan migrasi akan mengungkapkan tugas pekerjaan yang harus Anda lakukan sebelumnya, selama, dan setelah proses migrasi {i>database<i}. Misalnya, jika Anda memutuskan untuk untuk memigrasikan tabel tertentu dari {i>database<i}, Anda mungkin perlu melakukan pra-migrasi atau pascamigrasi untuk menerapkan pemfilteran ini. Anda juga memastikan bahwa migrasi database tidak memengaruhi perjanjian tingkat layanan (SLA) dan kelangsungan bisnis yang sudah ada rencana Anda sendiri.

Sebaiknya dokumentasi perencanaan migrasi Anda menyertakan hal-hal berikut dokumen:

• Dokumen desain teknis (TDD)
• Matriks RACI
• Linimasa (seperti rencana T-Minus)

Migrasi {i>database<i} adalah proses berulang, dan migrasi pertama sering lebih lambat dari yang berikutnya. Biasanya, migrasi yang terencana dengan baik akan berjalan tanpa masalah, tetapi masalah yang tidak direncanakan masih bisa muncul. Sebaiknya Anda selalu memiliki rollback rencana Anda sendiri. Sebagai praktik terbaik, ikuti panduan dari Bermigrasi ke Google Cloud: Praktik terbaik untuk memvalidasi rencana migrasi.

TDD

TDD mendokumentasikan semua keputusan teknis yang dibuat untuk proyek tersebut. Sertakan berikut ini di TDD:

• Persyaratan dan kekritisan bisnis
• Batas waktu pemulihan (RTO)
• Toleransi jumlah data yang hilang (RPO)
• Detail migrasi database
• Perkiraan upaya migrasi
• Rekomendasi validasi migrasi

Matriks RACI

Beberapa proyek migrasi membutuhkan matriks RACI, yang merupakan proyek umum dokumen manajemen yang mendefinisikan individu atau kelompok mana yang tugas dan hasil kerja dalam proyek migrasi.

Linimasa

Siapkan linimasa untuk setiap database yang perlu dimigrasikan. Sertakan semua tugas kerja yang harus diselesaikan, dan tanggal mulai serta perkiraan akhir yang ditentukan tanggal.

Untuk setiap lingkungan migrasi, sebaiknya buat paket T-minus. Rencana T-minus disusun sebagai jadwal hitung mundur, dan mencantumkan semua tugas yang diperlukan untuk menyelesaikan proyek migrasi, beserta kelompok yang bertanggung jawab dan perkiraan durasi.

Linimasa harus memperhitungkan tidak hanya tugas persiapan pra-migrasi tetapi juga memvalidasi, mengaudit, atau menguji tugas-tugas yang terjadi setelah transfer data berlangsung.

Durasi tugas migrasi biasanya bergantung pada ukuran database, tetapi ada juga aspek lain yang perlu dipertimbangkan, seperti kompleksitas logika bisnis, penggunaan, dan ketersediaan tim.

Rencana T-Minus mungkin terlihat seperti berikut:

Tanggal	Fase	Kategori	Tasks	Peran	T-minus	Status
1/11/2023	Pra-migrasi	Penilaian	Buat laporan penilaian	Tim discovery	-21	Selesai
7/11/2023	Pra-migrasi	Persiapan target	Desain lingkungan target seperti yang dijelaskan oleh dokumen desain	Tim migrasi	-14	Selesai
15/11/2023	Pra-migrasi	Tata kelola perusahaan	Tanggal migrasi dan persetujuan T-Minus	Kepemimpinan	-6	Selesai
18/11/2023	Migrasi	Menyiapkan DMS	Membuat profil koneksi	Engineer migrasi cloud	-3	Selesai
19/11/2023	Migrasi	Menyiapkan DMS	Membangun dan memulai tugas migrasi	Engineer migrasi cloud	-2	Belum dimulai
19/11/2023	Migrasi	Memantau DMS	Memantau Tugas DMS dan perubahan DDL di instance sumber	Engineer migrasi cloud	-2	Belum dimulai
21/11/2023	Migrasi	DMS Cutover	Promosikan replika DMS	Engineer migrasi cloud	0	Belum dimulai
21/11/2023	Migrasi	Validasi migrasi	Validasi migrasi database	Tim migrasi	0	Belum dimulai
21/11/2023	Migrasi	Pengujian aplikasi	Menjalankan pengujian kemampuan dan performa	Tim migrasi	0	Belum dimulai
22/11/2023	Migrasi	Tata kelola perusahaan	Validasi migrasi GO atau NO GO	Tim migrasi	1	Belum dimulai
23/11/2023	Pascamigrasi	Memvalidasi pemantauan	Mengonfigurasi pemantauan	Tim infrastruktur	2	Belum dimulai
25/11/2023	Pascamigrasi	Keamanan	Hapus akun pengguna DMS	Tim keamanan	4	Belum dimulai

Beberapa migrasi database

Jika Anda memiliki beberapa database untuk dimigrasikan, rencana migrasi Anda harus berisi tugas untuk semua migrasi.

Sebaiknya mulai prosesnya dengan memigrasikan data yang lebih kecil, idealnya {i>non-mission-critical database<i}. Pendekatan ini dapat membantu membangun pengetahuan dan keyakinan terkait proses dan alat migrasi. Anda juga dapat mendeteksi segala kekurangan dalam proses pada tahap awal keseluruhan migrasi jadwal proyek.

Jika Anda memiliki beberapa database untuk dimigrasikan, linimasa dapat diparalelkan. Misalnya, untuk mempercepat proses migrasi, Anda dapat memilih untuk memigrasikan sekelompok {i>database<i} kecil, statis, atau kurang penting secara bersamaan, yang ditampilkan dalam diagram berikut.

Pada contoh yang ditunjukkan pada diagram, {i>database<i} 1-4 adalah sekelompok kecil {i>database<i} yang dipindahkan pada waktu bersamaan.

Menentukan tugas persiapan

Tugas persiapan adalah semua kegiatan yang perlu Anda selesaikan untuk memenuhi prasyarat migrasi. Tanpa tugas persiapan, migrasi tidak dapat dilakukan atau hasil migrasi di database yang dimigrasikan dalam kondisi tidak dapat digunakan.

Tugas persiapan dapat dikategorikan sebagai berikut:

• Persiapan dan prasyarat instance Amazon RDS atau Amazon Aurora
• Persiapan dan prasyarat database sumber
• Penyiapan Cloud SQL
• Penyiapan khusus migrasi

Persiapan dan prasyarat instance Amazon RDS atau Amazon Aurora

Pertimbangkan penyiapan umum dan tugas prasyarat berikut:

• Bergantung pada jalur migrasi, Anda mungkin perlu mengizinkan koneksi jarak jauh koneksi jarak jauh pada instance RDS Anda. Jika {i>instance<i} RDS Anda dikonfigurasi agar pribadi di VPC Anda, pribadi RFC 1918 harus ada konektivitas antara Amazon dan Google Cloud.

• Anda mungkin perlu mengonfigurasi grup keamanan baru untuk mengizinkan remote koneksi pada porta yang diperlukan.

  • Secara default, akses jaringan diaktifkan di AWS untuk instance database.
  • Anda dapat menentukan aturan di grup keamanan yang mengizinkan akses dari rentang alamat IP, porta, atau grup keamanan. Aturan yang sama berlaku untuk semua instance database yang terkait dengan grup keamanan tersebut.

• Pastikan Anda memiliki kapasitas disk kosong yang cukup untuk melakukan buffering log WAL selama durasinya dari operasi pemuatan penuh di instance Amazon RDS Anda.

• Untuk hasil migrasi yang optimal, pertimbangkan untuk bermigrasi dari replika baca, kecuali Anda bermigrasi dari Amazon Aurora. Selain itu, kami sebaiknya Anda memulai proses migrasi selama periode aktivitas database.

• MySQL membatasi nama host hingga 60 karakter. Database Amazon RDS nama {i>host<i} biasanya lebih dari 60 karakter. Jika kasusnya seperti ini {i>database<i} yang Anda migrasikan, lalu konfigurasikan pengalihan DNS untuk membuat Data CNAME yang mengaitkan nama domain Anda dengan nama domain instance database RDS.

• Jika menggunakan replikasi bawaan, Anda perlu menyiapkan Amazon instance RDS atau Amazon Aurora untuk replikasi. Replikasi bawaan, atau yang menggunakannya, memerlukan logging biner untuk MySQL yang disetel ke ROW.

• Jika Anda menggunakan alat pihak ketiga, setelan dan konfigurasi di awal biasanya diperlukan sebelum menggunakan alat ini. Periksa dokumentasi dari alat pihak ketiga.

Untuk mengetahui informasi selengkapnya tentang persiapan dan prasyarat instance, lihat Menyiapkan server eksternal untuk replikasi MySQL.

Persiapan dan prasyarat database sumber

• Jika memilih untuk menggunakan Database Migration Service, Anda harus mengonfigurasi sumber {i>database<i} sebelum terhubung ke sana. Tinjau tugas migrasi sebelum mengimplementasikan pekerjaan tersebut. Untuk informasi selengkapnya, lihat Konfigurasi sumber untuk MySQL.
• Tergantung pada mesin database Anda, mengubah fitur tertentu. Misalnya, Cloud SQL untuk MySQL mendukung hanya mesin database InnoDB. Anda perlu mengubah tabel MyISAM menjadi InnoDB.
• Beberapa alat migrasi pihak ketiga mengharuskan semua kolom LOB nullable. Kolom LOB mana pun yang berupa NOT NULL harus memiliki batasan tersebut dihapus selama migrasi.

• Melakukan pengukuran dasar pengukuran di lingkungan sumber Anda dalam penggunaan produksi. Pertimbangkan hal berikut:

  • Ukur ukuran data dan beban kerja Anda tingkat tinggi. Berapa lama waktu yang dibutuhkan kueri atau transaksi penting, rata-rata? Berapa lama durasi waktu sibuk?
  • Dokumentasikan pengukuran dasar untuk perbandingan di lain waktu, untuk membantu Anda memutuskan jika fidelitas migrasi database Anda memuaskan. Tentukan apakah Anda dapat mengalihkan beban kerja produksi dan menonaktifkan sumber tambahan, atau jika Anda masih memerlukannya untuk tujuan penggantian.

Penyiapan Cloud SQL

Pilih dengan cermat ukuran dan spesifikasi Cloud SQL untuk MySQL target Anda agar sesuai dengan sumber untuk kebutuhan performa yang serupa. Bayar khusus ukuran dan throughput disk, IOPS, dan jumlah vCPU. Salah ukuran dapat menyebabkan waktu migrasi yang lama, masalah performa database, error, dan masalah performa aplikasi.

Anda harus mengonfirmasi properti dan persyaratan berikut sebelum membuat Instance Cloud SQL, karena nantinya tidak dapat diubah membuatnya kembali.

• Pilih project dan region target Anda instance Cloud SQL dengan hati-hati. Instance Cloud SQL tidak dapat dimigrasikan di antara project dan region Google Cloud tanpa transfer data.
• Lakukan migrasi ke versi utama yang cocok di Cloud SQL. Misalnya, jika sumber Anda menggunakan MySQL 8.0.34 di Amazon RDS atau Amazon Aurora, Anda harus bermigrasi ke Cloud SQL untuk MySQL versi 8.0.34.
• Replikasikan informasi pengguna secara terpisah, jika Anda menggunakan mesin database bawaan cadangan atau Database Migration Service. Cloud SQL mengelola pengguna yang menggunakan Google IAM. Untuk mengetahui detailnya, tinjau batasan di Pencadangan mesin database bawaan bagian.
• Tinjau flag konfigurasi database engine dan bandingkan nilai instance sumber dan targetnya. Pastikan Anda memahami dampak dan apakah mereka harus sama atau tidak. Misalnya, sebaiknya menjalankan perintah SHOW VARIABLES di database sumber sebelum migrasi, lalu jalankan lagi pada di database Cloud SQL. Perbarui setelan tanda sesuai kebutuhan di Database Cloud SQL untuk mereplikasi setelan sumber. Perhatikan bahwa bukan semua tanda MySQL diizinkan di instance Cloud SQL.

Untuk mengetahui informasi selengkapnya tentang penyiapan Cloud SQL, lihat referensi berikut:

• Praktik terbaik umum untuk MySQL
• Opsi konfigurasi instance untuk MySQL
• Pertimbangan penting sebelum bermigrasi dari Aurora ke Cloud SQL untuk MySQL

Penyiapan khusus migrasi

Jika mengimpor file dump SQL ke Cloud SQL, Anda mungkin perlu membuat bucket Cloud Storage. Bucket menyimpan dump database.

Jika menggunakan replikasi, Anda harus memastikan bahwa replika Cloud SQL memiliki akses ke {i>database<i} utama. Akses ini dapat dilakukan melalui dokumentasi opsi konektivitas.

Tergantung skenario dan kekritisannya, Anda mungkin perlu menerapkan skenario penggantian, yang biasanya mencakup membalikkan arah replikasi. Dalam hal ini, Anda mungkin membutuhkan mekanisme replikasi tambahan dari Cloud SQL kembali ke instance Amazon sumber Anda.

Untuk sebagian besar alat pihak ketiga, Anda perlu menyediakan resource khusus migrasi. Misalnya, untuk Striim, Anda perlu menggunakan Google Cloud Marketplace untuk memulai. Kemudian, untuk menyiapkan lingkungan migrasi di Striim, Anda dapat menggunakan Flow Desainer untuk membuat dan mengubah aplikasi, atau Anda dapat memilih aplikasi yang sudah ada {i>template<i}. Aplikasi juga dapat dikodekan menggunakan Tungsten Query Language (TQL) yang berpusat pada data (data-centric). Dengan menggunakan dasbor validasi data, Anda bisa mendapatkan data yang ditangani oleh aplikasi Striim Anda.

Anda dapat menonaktifkan sumber daya yang menghubungkan Amazon dan lingkungan Google Cloud setelah migrasi selesai dan divalidasi.

Untuk informasi selengkapnya, lihat referensi berikut:

• Mengelola tugas migrasi di Database Migration Service
• Praktik terbaik untuk mengimpor dan mengekspor data
• Konektivitas untuk MySQL

Menentukan tugas eksekusi

Tugas eksekusi mengimplementasikan tugas migrasi itu sendiri. Tugas-tugas tergantung pada memilih alat migrasi, seperti yang dijelaskan di subbagian berikut.

Cadangan mesin database bawaan

Untuk melakukan migrasi satu kali, gunakan utilitas mysqldump untuk membuat cadangan, yang menyalin data dari Amazon RDS ke komputer klien lokal Anda. Untuk mengetahui petunjuknya, lihat Impor file dump SQL ke Cloud SQL untuk MySQL.

Anda dapat memeriksa status operasi impor dan ekspor untuk instance Cloud SQL Anda.

Tugas migrasi Database Migration Service

Tentukan dan konfigurasi tugas migrasi di Database Migration Service untuk memigrasikan data dari ke database tujuan. Tugas migrasi terhubung ke instance database sumber melalui profil koneksi yang ditentukan pengguna.

Uji semua prasyarat untuk memastikan tugas dapat dijalankan dengan sukses. Pilih ketika workload Anda dapat memberikan periode nonaktif kecil untuk migrasi dan batas waktu produksi.

Di {i>Database Migration Service<i}, migrasi dimulai dengan pencadangan dan pemuatan penuh awal, diikuti oleh aliran perubahan berkelanjutan dari sumber ke tujuan di instance database.

Database Migration Service memerlukan waktu beberapa detik untuk mendapatkan kunci baca pada semua tabel di ke instance Amazon RDS atau Amazon Aurora yang diperlukan untuk melakukan {i>full dump<i} dengan cara yang konsisten. Untuk mencapai kunci baca, Anda mungkin perlu menulis periode nonaktif selama antara 1 dan 49 detik. Periode nonaktif ini bergantung pada jumlah tabel dalam {i>database<i} Anda, dengan waktu 1 detik berarti 100 tabel dan 9 detik sesuai dengan 10000 tabel.

Proses migrasi dengan Database Migration Service berakhir dengan operasi promosi. Mempromosikan instance database akan memutuskan koneksi database tujuan dari flow perubahan yang berasal dari {i>database<i} sumber, kemudian akan instance tujuan dipromosikan menjadi instance utama. Pendekatan ini juga terkadang disebut {i>switch<i} produksi.

Untuk informasi selengkapnya tentang tugas migrasi di Database Migration Service, lihat artikel berikut:

• Meninjau tugas migrasi
• Mengelola tugas migrasi
• Mempromosikan migrasi

Untuk proses penyiapan migrasi yang mendetail, lihat Migrasikan database ke Cloud SQL untuk MySQL menggunakan Database Migration Service. Di Database Migration Service, migrasi dilakukan dengan memulai dan menjalankan migrasi pekerjaan.

Replikasi bawaan mesin database

Anda dapat menggunakan replikasi bawaan dari Amazon RDS ke database instance Cloud SQL untuk MySQL.

Untuk MySQL, pertama-tama Anda harus memulai dengan dump awal yang dapat disimpan di bucket Cloud Storage, lalu mengimpor data ke Cloud SQL untuk MySQL. Kemudian, Anda dapat memulai proses replikasi.

Pantau replikasi, dan hentikan penulisan di instance sumber pada waktu yang tepat. Periksa kembali status replikasi untuk memastikan bahwa semua perubahan direplikasi, lalu mempromosikan replika Cloud SQL untuk MySQL ke instance mandiri untuk menyelesaikan migrasi Anda.

Untuk petunjuk mendetail tentang cara menyiapkan replikasi bawaan dari server eksternal seperti Amazon RDS atau Amazon Aurora untuk MySQL, lihat Tentang mereplikasi dari server eksternal dan Konfigurasikan Cloud SQL dan server eksternal untuk replikasi.

Untuk mendapatkan informasi dan panduan selengkapnya, lihat referensi berikut:

• Mengekspor database ke bucket Cloud Storage
• Menggunakan impor terkelola untuk menyiapkan replikasi dari database eksternal
• Memulai replikasi di server eksternal

Alat pihak ketiga

Tentukan tugas eksekusi untuk alat pihak ketiga yang telah Anda pilih.

Bagian ini berfokus pada Striim sebagai contoh. Striim menggunakan aplikasi yang memperoleh data dari berbagai sumber, memproses data itu, dan kemudian mengirimkan data itu ke aplikasi lain atau target.

Aplikasi dapat dibuat secara grafis menggunakan klien web dan berisi sumber, target, dan komponen logis lainnya yang diatur ke dalam satu atau beberapa alur.

Untuk menyiapkan lingkungan migrasi di Striim, Anda dapat menggunakan Desainer Alur untuk membuat dan mengubah aplikasi, atau Anda dapat memilih dari sejumlah template yang sudah ada sebelumnya. Aplikasi juga dapat dikodekan dengan menggunakan TQL yang berpusat pada data (data-centric).

Anda bisa mendapatkan representasi visual data yang ditangani oleh aplikasi Striim Anda dengan menggunakan dasbor validasi data.

Untuk mulai menggunakan Striim di Google Cloud dengan cepat, lihat Menjalankan Striim di Google Cloud. Untuk mempelajari lebih lanjut tentang konsep dasar Striim, lihat Konsep Striim. Pastikan Anda juga membaca panduan praktik terbaik untuk Beralih dari pemuatan awal ke replikasi berkelanjutan.

Pertimbangkan praktik terbaik berikut untuk migrasi data Anda:

• Memberi tahu tim yang terlibat setiap kali setiap langkah rencana dimulai dan hingga akhir.
• Jika salah satu langkah memakan waktu lebih lama dari yang diperkirakan, bandingkan waktu yang berlalu dengan jumlah waktu maksimal yang dialokasikan untuk setiap langkah. Masalah reguler {i>update<i} perantara kepada tim yang terlibat ketika ini terjadi.
• Jika rentang waktu lebih besar dari jumlah maksimal waktu yang dicadangkan untuk setiap langkah dalam rencana, pertimbangkan untuk melakukan roll back.
• Mulai atau tidak. untuk setiap langkah migrasi dan rencana {i>cut-over<i}.
• Pertimbangkan tindakan rollback atau skenario alternatif untuk setiap langkah.

Menentukan skenario penggantian

Tentukan item tindakan penggantian untuk setiap tugas eksekusi migrasi guna mengamankan untuk mengatasi masalah tak terduga yang mungkin terjadi selama proses migrasi. Tujuan tugas penggantian biasanya bergantung pada strategi migrasi dan alat yang digunakan.

Penggantian mungkin memerlukan upaya yang signifikan. Sebagai praktik terbaik, jangan melakukan batas waktu produksi hingga hasil pengujian Anda memuaskan. Kedua database migrasi dan skenario penggantian harus diuji dengan benar untuk menghindari pemadaman layanan.

Tentukan kriteria keberhasilan dan tentukan waktu untuk semua tugas eksekusi migrasi Anda. Melakukan uji coba migrasi membantu mengumpulkan informasi tentang waktu yang diharapkan untuk setiap tugas Anda. Misalnya, untuk migrasi pemeliharaan terjadwal, Anda dapat membayar periode nonaktif yang ditunjukkan sebagai periode cut-over. Namun, penting untuk merencanakan tindakan Anda berikutnya jika tugas migrasi satu kali atau pemulihan cadangan gagal di tengah jalan. Tergantung pada berapa banyak waktu periode nonaktif yang direncanakan telah berlalu, Anda mungkin harus menunda migrasi jika tugas migrasi tidak selesai jumlah waktu yang diharapkan.

Rencana penggantian biasanya mengacu pada roll back migrasi setelah Anda cut-over produksi, jika masalah pada instance target muncul. Jika Anda mengimplementasikan rencana fallback, ingat bahwa rencana tersebut harus diperlakukan sebagai database lengkap migrasi, termasuk perencanaan dan pengujian.

Jika Anda memilih untuk tidak memiliki rencana penggantian, pastikan Anda memahami konsekuensi yang mungkin terjadi. Tidak ada rencana penggantian dapat menambah upaya yang tidak terduga dan menyebabkan gangguan yang dapat dihindari dalam proses migrasi Anda.

Meskipun fallback adalah upaya terakhir, dan sebagian besar migrasi {i>database<i} tidak menggunakannya, sebaiknya Anda selalu memiliki strategi penggantian.

Penggantian sederhana

Dalam strategi penggantian ini, Anda akan mengalihkan aplikasi kembali ke versi aslinya instance database sumber. Terapkan strategi ini jika Anda mampu memberikan waktu henti saat Anda mundur atau jika Anda tidak perlu transaksi yang dilakukan pada target baru sistem file.

Jika Anda membutuhkan semua data tertulis pada {i>database<i} target, dan Anda mampu selama periode nonaktif, Anda dapat mempertimbangkan untuk menghentikan operasi tulis ke database target. Anda, mengambil cadangan bawaan dan memulihkannya pada {i>instance<i} sumber Anda, kemudian menghubungkan kembali aplikasi Anda ke database sumber awal di instance Compute Engine. Tergantung pada sifat beban kerja Anda dan jumlah data yang ditulis instance database target, Anda dapat memasukkannya ke dalam sistem database di lain waktu, terutama jika beban kerja Anda tergantung pada waktu pembuatan {i>record<i} tertentu atau batasan waktu pengurutan.

Replikasi terbalik

Dalam strategi ini, Anda akan mereplikasi penulisan yang terjadi pada target baru di database setelah cut-over produksi kembali ke database sumber awal Anda. Di sini sumber asli tetap sinkron dengan database target baru dan penulisan yang terjadi pada instance database target baru. Kekurangan utamanya adalah Anda tidak dapat menguji aliran replikasi sampai setelah Anda berpindah ke menargetkan instance database, oleh karena itu tidak memungkinkan pengujian end-to-end dan memiliki periode singkat tanpa penggantian.

Pilih pendekatan ini saat Anda masih dapat menyimpan instance sumber untuk beberapa waktu dan Anda bermigrasi menggunakan migrasi replikasi berkelanjutan.

Meneruskan replikasi

Strategi ini adalah variasi replikasi terbalik. Anda mereplikasi menulis di database target baru ke instance database ketiga pilihan Anda. Anda dapat mengarahkan aplikasi Anda ke database ketiga ini, yang terhubung ke server dan menjalankan kueri hanya-baca saat server tidak tersedia. Anda dapat menggunakan mekanisme replikasi, tergantung pada kebutuhan Anda. Keuntungan dari pendekatan yang berbeda, yaitu pengujian dapat diuji sepenuhnya secara menyeluruh.

Ambil pendekatan ini ketika Anda ingin selalu tercakup oleh penggantian atau jika Anda harus menghapus database sumber awal segera setelah proses produksi {i>cut-over<i}.

Penulisan duplikat

Jika Anda memilih Y (menulis dan membaca) atau migrasi microservice akses data , rencana penggantian ini sudah ditetapkan. Strategi ini lebih rumit, karena Anda perlu memfaktorkan ulang aplikasi atau mengembangkan alat yang terhubung ke instance database.

Aplikasi Anda menulis ke instance database sumber maupun target awal, yang memungkinkan Anda melakukan produksi secara bertahap hingga Anda hanya menggunakan instance database target Anda. Jika terjadi masalah, Anda dapat menghubungkan aplikasi kembali ke sumber awal tanpa periode nonaktif. Anda dapat menghapus sumber awal dan mekanisme penulisan duplikasi ketika Anda mempertimbangkan migrasi dilakukan tanpa terdeteksi masalah.

Kami merekomendasikan pendekatan ini saat sangat penting untuk tidak memiliki periode nonaktif migrasi, memiliki pengganti yang dapat diandalkan, dan ketika Anda memiliki waktu dan sumber daya untuk melakukan pemfaktoran ulang aplikasi.

Melakukan pengujian dan validasi

Tujuan dari langkah ini adalah untuk menguji dan memvalidasi hal berikut:

• Migrasi data yang berhasil dalam database.
• Integrasi dengan aplikasi yang sudah ada setelah dialihkan untuk digunakan instance target baru.

Tentukan faktor keberhasilan utama, yang subjektif untuk migrasi Anda. Tujuan berikut adalah contoh faktor subjektif:

• Data yang akan dimigrasikan. Untuk beberapa beban kerja, Anda mungkin tidak perlu memigrasikan semua layanan otomatis dan data skalabel. Anda mungkin tidak ingin memigrasikan data yang sudah digabungkan, redundan, diarsipkan, atau lama. Anda dapat mengarsipkan data tersebut dalam Bucket Cloud Storage, sebagai cadangan.
• Persentase kehilangan data yang dapat diterima. Hal ini terutama berlaku untuk data digunakan untuk beban kerja analisis, di mana kehilangan sebagian data tidak memengaruhi tren atau performa workload secara umum.
• Kriteria kualitas dan kuantitas data, yang dapat diterapkan pada sumber data Anda dan membandingkannya dengan lingkungan target setelah migrasi.
• Kriteria kinerja. Beberapa transaksi bisnis mungkin lebih lambat dalam lingkungan target, tetapi waktu pemrosesan masih dalam batas waktu ekspektasi perusahaan.

Konfigurasi penyimpanan di lingkungan sumber Anda mungkin tidak dipetakan langsung ke target lingkungan Google Cloud. Misalnya, konfigurasi dari Volume SSD (gp2 dan gp3) Tujuan Umum dengan performa burst IOPS atau SSD IOPS yang disediakan. Untuk membandingkan dan mengukur instance target dengan benar, tolok ukur sumber Anda instance, baik di fase penilaian maupun validasi.

Dalam proses tolok ukur, Anda menerapkan urutan operasi seperti produksi ke instance database. Selama waktu ini, Anda akan mengambil dan memproses metrik untuk mengukur dan membandingkan performa relatif sumber dan target yang berbeda.

Untuk konfigurasi berbasis server konvensional, gunakan pengukuran yang relevan yang diamati selama beban puncak. Untuk model kapasitas resource fleksibel seperti Aurora Serverless, pertimbangkan data metrik historis untuk mengamati penskalaan mereka.

Alat berikut dapat digunakan untuk pengujian, validasi, dan database {i>benchmarks <i}(tolok ukur):

• HammerDB: sebuah alat tolok ukur dan pengujian beban pada {i>database<i} {i>open source<i}. Mendukung transaksi dan analitik yang kompleks, berdasarkan standar industri, di beberapa mesin database (TPROC-C dan TPROC-H). HammerDB memiliki dokumentasi yang rinci dan komunitas pengguna yang luas. Anda dapat berbagi dan membandingkan hasil di beberapa mesin database dan konfigurasi penyimpanan. Untuk informasi selengkapnya, lihat Pengujian beban SQL Server menggunakan HammerDB dan Menjalankan benchmark performa Amazon RDS SQL Server menggunakan HammerDB.
• Alat Tolok Ukur DBT2: {i>benchmark <i}khusus untuk MySQL. Sekumpulan kit workload database yang meniru aplikasi untuk perusahaan yang memiliki gudang dan melibatkan campuran transaksi baca dan tulis. Gunakan alat ini jika Anda ingin menggunakan uji beban pemrosesan transaksi online (OLTP).
• DbUnit: alat pengujian unit {i>open source<i} yang digunakan untuk menguji {i>database<i} relasional di Java. Penyiapan dan penggunaannya mudah, dan juga mendukung beberapa mesin database (MySQL, PostgreSQL, SQL Server, dan lainnya). Namun, eksekusi uji terkadang dapat lambat, bergantung pada ukurannya dan kompleksitas {i>database<i}. Kami merekomendasikan alat ini ketika kesederhanaan sangatlah penting.
• DbFit: framework pengujian database open source yang mendukung kode berbasis pengujian pengembangan aplikasi dan pengujian otomatis. Pengujian ini menggunakan sintaksis dasar untuk membuat pengujian kasus dan fitur pengujian berbasis data, kontrol versi, dan hasil pengujian pelaporan. Namun, dukungan untuk kueri dan transaksi yang kompleks sangat terbatas dan tidak memiliki dukungan komunitas atau dokumentasi yang ekstensif, dibandingkan dengan {i>tool<i} lainnya. Kami merekomendasikan alat ini jika kueri Anda tidak rumit dan ingin melakukan pengujian otomatis dan mengintegrasikannya dengan proses continuous integration dan continuous delivery Anda.

Untuk menjalankan pengujian menyeluruh, termasuk pengujian rencana migrasi, selalu melakukan uji coba migrasi. Uji coba menjalankan {i>database<i} cakupan penuh migrasi tanpa mengalihkan beban kerja produksi, dan menawarkan keuntungan berikut:

• Memungkinkan Anda memastikan bahwa semua objek dan konfigurasi dimigrasikan dengan benar.
• Membantu Anda menentukan dan menjalankan kasus pengujian migrasi.
• Menawarkan insight tentang waktu yang dibutuhkan untuk migrasi yang sebenarnya, sehingga Anda dapat melakukan kalibrasi {i>timeline<i}.
• Mewakili kesempatan untuk menguji, memvalidasi, dan menyesuaikan rencana migrasi. Terkadang Anda tidak dapat merencanakan semuanya sebelumnya, jadi ini membantu Anda untuk menemukan celah.

Pengujian data dapat dilakukan pada sekumpulan kecil {i>database<i} yang akan dimigrasikan atau seluruh {i>dataset<i}. Tergantung pada jumlah total {i> database<i} dan alat yang digunakan untuk mengimplementasikan migrasinya, Anda dapat memutuskan untuk mengadopsi pendekatan berbasis risiko. Dengan pendekatan ini, Anda melakukan validasi data pada {i>subset<i} {i>database<i} dimigrasikan melalui alat yang sama, khususnya jika alat ini adalah migrasi terkelola layanan.

Untuk pengujian, Anda harus memiliki akses ke {i>database<i} sumber dan target, dan melakukan tugas berikut:

• Membandingkan skema sumber dan target. Memeriksa apakah semua tabel dan file yang dapat dieksekusi ada. Memeriksa jumlah baris dan membandingkan data di tingkat database.
• Menjalankan skrip validasi data kustom.
• Uji apakah data yang dimigrasikan juga terlihat di aplikasi yang dialihkan untuk menggunakan database target (data yang dimigrasikan dibaca melalui aplikasi).
• Lakukan pengujian integrasi antara aplikasi yang dialihkan dan menargetkan database dengan menguji berbagai kasus penggunaan. Pengujian ini mencakup kemampuan membaca dan menulis data ke {i>database<i} target melalui aplikasi sehingga workload sepenuhnya mendukung data yang dimigrasikan beserta data yang baru dibuat.
• Uji kinerja kueri {i>database<i} yang paling sering digunakan untuk mengamati apakah ada penurunan karena kesalahan konfigurasi atau ukuran yang salah.

Idealnya, semua skenario pengujian migrasi ini bersifat otomatis dan dapat diulang di semua sistem sumber. Suite kasus pengujian otomatis diadaptasi untuk menjalankan terhadap aplikasi yang dialihkan.

Jika Anda menggunakan Database Migration Service sebagai alat migrasi, lihat Verifikasi migrasi.

Alat Validasi Data

Untuk melakukan validasi data, kami sarankan Anda menggunakan Alat Validasi Data (DVT). DVT adalah alat Python CLI open source, yang didukung oleh Google, yang menyediakan solusi otomatis dan dapat diulang untuk validasi di berbagai lingkungan fleksibel App Engine.

DVT dapat membantu merampingkan proses validasi data dengan menawarkan fungsi validasi multi-level untuk membandingkan tabel sumber dan target pada tingkat tabel, kolom, dan baris. Anda juga dapat menambahkan aturan validasi.

DVT mencakup banyak sumber data Google Cloud, termasuk AlloyDB untuk PostgreSQL, File BigQuery, Cloud SQL, Spanner, JSON, dan CSV di yang sesuai di Cloud Storage. Alat ini juga dapat diintegrasikan dengan fungsi Cloud Run dan Cloud Run untuk pemicuan dan orkestrasi berbasis peristiwa.

DVT mendukung jenis validasi berikut:

• Perbandingan tingkat skema
• Kolom (termasuk 'AVG', 'COUNT', 'SUM', 'MIN', 'MAX', 'GROUP BY', dan 'STRING_AGG')
• Baris (termasuk hash dan pencocokan persis dalam perbandingan kolom)
• Perbandingan hasil kueri kustom

Untuk informasi selengkapnya tentang DVT, lihat Repositori Git dan Validasi data menjadi mudah dengan Alat Validasi Data Google Cloud.

Melakukan migrasi

Tugas migrasi mencakup aktivitas untuk mendukung transfer dari satu sistem ke sistem lain.

Pertimbangkan praktik terbaik berikut untuk migrasi data Anda:

• Memberi tahu tim yang terlibat setiap kali langkah rencana dimulai dan selesai.
• Jika salah satu langkah memakan waktu lebih lama dari yang diperkirakan, bandingkan waktu yang berlalu dengan jumlah waktu maksimum yang dialokasikan untuk langkah tersebut. Masalah reguler {i>update<i} perantara kepada tim yang terlibat ketika ini terjadi.
• Jika rentang waktu lebih besar dari jumlah maksimal waktu yang dicadangkan untuk setiap langkah dalam rencana, pertimbangkan untuk melakukan roll back.
• Mulai atau tidak. untuk setiap langkah migrasi dan rencana {i>cut-over<i}.
• Pertimbangkan tindakan rollback atau skenario alternatif untuk setiap langkah.

Lakukan migrasi dengan mengikuti tugas eksekusi yang ditentukan, dan membaca dokumentasi untuk alat migrasi yang Anda pilih.

Melakukan cut-over produksi

Proses cut-over produksi tingkat tinggi dapat berbeda-beda bergantung pada pilihan Anda. strategi migrasi. Jika Anda memiliki periode nonaktif pada workload, cut-over migrasi dimulai dengan menghentikan penulisan ke database sumber.

Untuk migrasi replikasi berkelanjutan, Anda biasanya melakukan langkah-langkah langkah-langkah dalam proses {i>cut-over<i}:

• Berhenti menulis ke database sumber.
• Kosongkan sumber.
• Hentikan proses replikasi.
• Deploy aplikasi yang mengarah ke database target baru.

Setelah data dimigrasikan dengan menggunakan alat migrasi yang dipilih, Anda memvalidasi data dalam database target. Anda mengonfirmasi bahwa database sumber dan database target sinkron dan data dalam instance target mematuhi dengan standar keberhasilan migrasi pilihan Anda.

Setelah validasi data melewati kriteria, Anda dapat melakukan penerapan {i>cut-over <i}tingkat tinggi. Deploy beban kerja yang telah difaktorkan ulang untuk menggunakan versi baru target instance Anda. Anda men-deploy versi aplikasi yang mengarah ke instance database target baru. Implementasi dapat dilakukan melalui update berkelanjutan, rilis bertahap, atau menggunakan pola blue-green deployment. Beberapa periode nonaktif aplikasi mungkin terjadi.

Ikuti praktik terbaik untuk cut-over produksi Anda:

• Memantau aplikasi Anda yang bekerja dengan database target setelah {i>cut-over<i}.
• Tentukan jangka waktu pemantauan untuk mempertimbangkan apakah Anda memerlukan untuk menerapkan rencana penggantian Anda.
• Perhatikan bahwa instance Cloud SQL atau AlloyDB untuk PostgreSQL mungkin perlu dimulai ulang jika Anda mengubah beberapa penanda {i>database<i}.
• Pertimbangkan bahwa upaya untuk melakukan roll back migrasi mungkin lebih besar daripada memperbaiki masalah yang muncul di lingkungan target.

Membersihkan lingkungan sumber dan mengonfigurasi instance Cloud SQL atau AlloyDB untuk PostgreSQL

Setelah cut-over selesai, Anda dapat menghapus database sumber. Rab sarankan untuk melakukan tindakan penting berikut sebelum pembersihan instance sumber:

• Buat cadangan akhir untuk setiap database sumber. Cadangan ini memberi Anda status akhir {i>database<i} sumber. Cadangan mungkin juga diperlukan di untuk mematuhi beberapa peraturan data.

• Kumpulkan setelan parameter database dari instance sumber Anda. Atau, periksa apakah nilai tersebut cocok dengan yang telah Anda kumpulkan di fase pembuatan inventaris. Sesuaikan parameter instance target agar cocok data dari instance sumber.

• Mengumpulkan statistik database dari instance sumber dan membandingkannya dengan yang ada dalam instance target. Jika statistiknya berbeda, maka sulit untuk membandingkan performa instance sumber dan instance target.

Dalam skenario penggantian, Anda mungkin ingin mengimplementasikan replikasi server menulis kembali instance Cloud SQL ke database sumber asli. Konfigurasinya mirip dengan proses migrasi, tetapi akan berjalan secara terbalik: konfigurasi awal database sumber akan menjadi target baru.

Sebagai praktik terbaik agar instance sumber selalu terbaru setelah cut-over, mereplikasi kembali penulisan yang dilakukan pada instance Cloud SQL target kembali ke database sumber. Jika Anda perlu melakukan roll back, Anda dapat kembali ke instance sumber lama Anda dengan kehilangan data minimal.

Selain pembersihan lingkungan sumber, Anda harus membuat konfigurasi penting berikut untuk instance Cloud SQL Anda:

• Mengonfigurasi masa pemeliharaan untuk mengontrol instance utama Anda saat update yang mengganggu dapat terjadi.
• Konfigurasikan penyimpanan pada instance sehingga Anda memiliki sisa kuota 20% ruang yang tersedia untuk mengakomodasi operasi pemeliharaan {i>database<i} yang penting yang dapat dilakukan Cloud SQL. Untuk menerima pemberitahuan jika disk tersedia kurang dari 20%, buat kebijakan pemberitahuan berbasis metrik untuk dan metrik pemakaian disk.

Jangan memulai operasi administratif sebelum operasi sebelumnya selesai.

Untuk informasi selengkapnya tentang pemeliharaan dan praktik terbaik, lihat Tentang pemeliharaan pada instance Cloud SQL.

Mengoptimalkan lingkungan Anda setelah migrasi

Pengoptimalan adalah fase terakhir dari migrasi Anda. Pada fase ini, Anda melakukan iterasi tugas pengoptimalan hingga lingkungan target memenuhi pengoptimalan Anda lainnya. Langkah-langkah dari setiap iterasi adalah sebagai berikut:

1. Menilai lingkungan, tim, dan loop pengoptimalan Anda saat ini.
2. Tetapkan persyaratan dan sasaran pengoptimalan Anda.
3. Optimalkan lingkungan dan tim Anda.
4. Sesuaikan loop pengoptimalan.

Anda mengulangi urutan ini sampai Anda mencapai sasaran pengoptimalan.

Untuk informasi selengkapnya tentang cara mengoptimalkan lingkungan Google Cloud, lihat Bermigrasi ke Google Cloud: Mengoptimalkan lingkungan Anda dan Proses pengoptimalan performa.

Menetapkan persyaratan pengoptimalan

Tinjau persyaratan pengoptimalan berikut untuk solusi Google Cloud Anda dan pilih salah satu yang paling sesuai dengan workload Anda:

Meningkatkan keandalan dan ketersediaan database Anda

Dengan Cloud SQL, Anda dapat menerapkan ketersediaan tinggi dan bencana yang selaras dengan batas waktu pemulihan (RTO) Anda dan toleransi jumlah data yang hilang (RPO). Untuk meningkatkan keandalan dan ketersediaan, pertimbangkan hal berikut:

• Pada kasus beban kerja baca yang berat, tambahkan replika baca untuk mengurangi beban traffic dari instance utama.
• Untuk beban kerja yang sangat penting, gunakan konfigurasi ketersediaan tinggi, untuk failover regional, dan konfigurasi pemulihan dari bencana yang kuat.
• Untuk beban kerja yang tidak terlalu penting, pencadangan otomatis dan on-demand dapat memadai.
• Untuk mencegah penghapusan instance secara tidak sengaja, gunakan penghapusan instance perlindungan data.
• Pertimbangkan untuk menggunakan edisi Cloud SQL Enterprise Plus untuk mendapatkan manfaat dari peningkatan ketersediaan, retensi log, dan periode nonaktif yang nyaris nol dan pemeliharaan mesin. Untuk informasi selengkapnya tentang Cloud SQL Enterprise Plus, lihat Pengantar edisi Cloud SQL dan Periode nonaktif terencana untuk pemeliharaan yang hampir nol.

Untuk informasi selengkapnya tentang cara meningkatkan keandalan dan ketersediaan lihat database, lihat berikut ini:

• Mempromosikan replika untuk migrasi regional atau pemulihan dari bencana (disaster recovery)
• Pemulihan dari bencana database Cloud SQL
• Tentang pencadangan Cloud SQL
• Mencegah penghapusan dokumentasi instance

Meningkatkan efektivitas biaya infrastruktur database Anda

Agar memberikan dampak ekonomi yang positif, workload Anda harus menggunakan resource yang tersedia resource dan layanan secara efisien. Pertimbangkan opsi berikut:

• Menyediakan database dengan kapasitas penyimpanan minimum yang diperlukan dengan melakukan berikut ini:

  • Untuk menskalakan kapasitas penyimpanan secara otomatis seiring pertumbuhan data Anda, mengaktifkan peningkatan penyimpanan otomatis. Namun, pastikan Anda mengonfigurasi instance Anda untuk memiliki beberapa buffer beban kerja puncak. Ingat {i>database<i} itu beban kerja cenderung meningkat dari waktu ke waktu.

• Identifikasi kemungkinan resource yang diperkirakan terlalu tinggi:

  • Penyesuaian ukuran instance Cloud SQL dapat mengurangi biaya infrastruktur tanpa menambah risiko tambahan pada kapasitas strategi manajemen proyek.
  • Cloud Monitoring menyediakan dasbor bawaan yang membantu mengidentifikasi kondisi dan pemanfaatan kapasitas di berbagai layanan Google Cloud komponen, termasuk Cloud SQL. Untuk mengetahui detailnya, lihat Buat dan kelola dasbor kustom.

• Mengidentifikasi instance yang tidak memerlukan ketersediaan tinggi atau bencana konfigurasi pemulihan aplikasi, dan menghapusnya dari infrastruktur Anda.

• Hapus tabel dan objek yang tidak lagi diperlukan. Anda dapat menyimpannya dalam bucket Cloud Storage arsip atau pencadangan penuh.

• Mengevaluasi jenis penyimpanan yang paling hemat biaya (SSD atau HDD) untuk Anda gunakan ini masalahnya atau bukan.

  • Untuk sebagian besar kasus penggunaan, SSD adalah cara yang paling efisien dan pilihan hemat biaya.
  • Jika set data Anda besar (10 TB atau lebih), tidak peka terhadap latensi, atau jarang diakses, menggunakan HDD.
  • Untuk mengetahui detailnya, lihat Pilih antara penyimpanan SSD atau HDD.

• Beli diskon abonemen untuk workload dengan kebutuhan resource yang dapat diprediksi.

• Gunakan Active Assist untuk memperoleh analisis biaya dan rekomendasi.

Untuk opsi dan informasi selengkapnya, lihat Lakukan banyak hal dengan lebih sedikit biaya: Memperkenalkan rekomendasi pengoptimalan biaya Cloud SQL dengan Active Assist.

Meningkatkan performa infrastruktur database Anda

Masalah performa kecil terkait database sering kali berpotensi memengaruhi untuk seluruh operasi. Untuk mengelola dan meningkatkan instance Cloud SQL Anda performa kampanye, pertimbangkan panduan berikut:

• Jika Anda memiliki banyak tabel database, tabel tersebut dapat memengaruhi instance performa dan ketersediaan, serta menyebabkan instance kehilangan cakupan SLA-nya.

• Pastikan instance Anda tidak dibatasi oleh memori atau CPU.

  • Untuk beban kerja yang membutuhkan performa tinggi, pastikan instance Anda memiliki memori minimal 60 GB.
  • Untuk penyisipan, pembaruan, atau penghapusan database yang lambat, periksa lokasi penulis dan {i>database<i}; mengirim data jarak jauh menimbulkan latensi.

• Tingkatkan performa kueri dengan menggunakan Query Insights yang telah ditetapkan dasbor di Cloud Monitoring (atau mesin database serupa bawaan baru). Identifikasi perintah yang paling mahal dan cobalah untuk mengoptimalkannya.

• Cegah file database menjadi terlalu besar. Setel autogrow dalam MB, bukan persentase, menggunakan penambahan yang sesuai dengan persyaratan.

• Periksa lokasi pembaca dan database. Latensi memengaruhi performa pembacaan lebih dari sekadar performa tulis.

• Pertimbangkan untuk menggunakan edisi Cloud SQL Enterprise Plus untuk mendapatkan manfaat dari peningkatan batas konfigurasi mesin dan cache data. Untuk selengkapnya informasi, lihat Pengantar edisi Cloud SQL.

Untuk mengetahui informasi selengkapnya tentang meningkatkan performa, lihat Performa dalam "Mendiagnosis masalah".

Meningkatkan kemampuan observasi database

Mendiagnosis dan memecahkan masalah dalam aplikasi yang terhubung ke {i>database<i} bisa jadi sulit dan memakan waktu. Karena alasan ini, semua anggota tim dapat melihat apa yang terjadi di database dan instance itu penting. Anda dapat memantau instance Cloud SQL di cara berikut:

• Cloud SQL menggunakan agen kustom memori bawaan untuk mengumpulkan kueri telemetri.

  • Gunakan Cloud Monitoring untuk mengumpulkan pengukuran layanan Anda dan data resource yang Anda gunakan.
    • Cloud Monitoring mencakup dasbor standar untuk beberapa produk Google Cloud, termasuk dasbor pemantauan Cloud SQL.
  • Anda dapat membuat dasbor kustom yang membantu memantau metrik dan menyiapkan kebijakan pemberitahuan agar Anda dapat menerima notifikasi tepat waktu.
  • Atau, Anda dapat mempertimbangkan untuk menggunakan solusi pemantauan pihak ketiga yang terintegrasi dengan Google Cloud, seperti Datadog dan Splunk.

• Cloud Logging mengumpulkan data logging dari komponen aplikasi umum.

• Cloud Trace mengumpulkan data latensi dan menjalankan rencana kueri dari aplikasi untuk membantu melacak bagaimana permintaan ditransmisikan di seluruh aplikasi Anda.

• Pusat Database memberikan ringkasan perangkat database terpusat yang didukung AI. Anda dapat memantau kondisi database Anda, konfigurasi ketersediaan, perlindungan data, keamanan, dan kepatuhan industri.

Praktik terbaik dan panduan operasional Cloud SQL umum

Terapkan praktik terbaik untuk Cloud SQL guna mengonfigurasi dan menyesuaikan di skrip untuk menyiapkan database.

Beberapa rekomendasi umum Cloud SQL yang penting adalah sebagai berikut:

• Jika memiliki instance yang besar, sebaiknya Anda membaginya menjadi untuk instance yang lebih kecil, jika memungkinkan.
• Konfigurasikan penyimpanan untuk mengakomodasi pemeliharaan database yang penting. Pastikan Anda memiliki setidaknya 20% ruang yang tersedia untuk mengakomodasi {i>database<i} penting pemeliharaan lain yang mungkin dilakukan Cloud SQL.
• Memiliki terlalu banyak tabel database dapat memengaruhi waktu upgrade database. Idealnya, usahakan memiliki kurang dari 10.000 tabel per instance.
• Pilih ukuran yang sesuai untuk diperhitungkan oleh instance Anda retensi log transaksi (biner), terutama untuk aktivitas tulis yang tinggi instance Compute Engine.

Untuk dapat menangani secara efisien masalah performa {i>database<i} apa pun yang mungkin Anda alami. temui, gunakan pedoman berikut sampai masalah Anda teratasi:

Tingkatkan skala infrastruktur: Tingkatkan resource (seperti throughput disk, vCPU, dan RAM). Tergantung pada urgensi dan ketersediaan dan pengalaman tim Anda, menskalakan instance secara vertikal dapat menyelesaikan sebagian besar masalah performa. Nantinya, Anda dapat menyelidiki lebih lanjut akar masalah di lingkungan pengujian dan pertimbangkan pilihan untuk menghilangkannya.

Melakukan dan menjadwalkan operasi pemeliharaan database: Indeks defragmentasi, pembaruan statistik, analisis vakum, dan pengindeksan ulang sangat diperbarui tabel sementara. Periksa apakah dan kapan operasi pemeliharaan ini terakhir dilakukan, terutama pada objek yang terpengaruh (tabel, indeks). Cari tahu apakah ada berubah dari aktivitas {i>database<i} normal. Misalnya, baru-baru ini menambahkan kolom atau memiliki banyak pembaruan di tabel.

Melakukan penyesuaian dan pengoptimalan database: Apakah tabel tersebut ada dalam database Anda terstruktur dengan benar? Apakah kolom memiliki jenis data yang benar? Apakah data Anda model yang tepat untuk jenis workload? Selidiki kueri lambat dan rencana eksekusinya. Apakah mereka menggunakan indeks yang tersedia? Periksa indeks memindai, mengunci, dan menunggu sumber daya lain. Pertimbangkan menambahkan indeks untuk mendukung kueri kritis Anda. Menghilangkan indeks yang tidak kritis dan kunci asing. Pertimbangkan menulis ulang kueri kompleks dan gabungan. Waktu yang diperlukan untuk menyelesaikan masalah Anda bergantung pada pengalaman dan ketersediaan tim Anda dan dapat berkisar dari jam hingga hari.

Penyebaran skala operasi baca: Pertimbangkan untuk memiliki replika baca. Saat melakukan penskalaan secara vertikal tidak memadai untuk kebutuhan Anda, serta penyesuaian dan pengoptimalan database tidak membantu, pertimbangkan penskalaan secara horizontal. Merutekan kueri baca dari aplikasi Anda ke replika baca meningkatkan keseluruhan performa workload database Anda. Namun, perubahan itu mungkin membutuhkan upaya tambahan aplikasi Anda untuk terhubung ke replika baca.

Arsitektur ulang database: Pertimbangkan untuk membuat partisi dan mengindeks database. Operasi ini membutuhkan upaya yang jauh lebih banyak daripada penyesuaian database dan pengoptimalan, dan mungkin melibatkan migrasi data, tetapi bisa menjadi jangka panjang diperbaiki. Terkadang, desain model data yang buruk dapat menyebabkan masalah performa, yang dapat mendapat kompensasi sebagian dengan peningkatan skala vertikal. Namun, model data yang tepat perbaikan jangka panjang. Pertimbangkan untuk mempartisi tabel Anda. Mengarsipkan data yang tidak diperlukan lagi, jika memungkinkan. Menormalkan struktur {i>database<i} Anda, tetapi ingat bahwa denormalisasi juga dapat meningkatkan performa.

Sharding database: Anda dapat menyebarkan skala penulisan dengan melakukan sharding database. Sharding adalah operasi yang rumit dan melibatkan perancangan ulang database Anda. dan aplikasi dengan cara tertentu dan melakukan migrasi data. Anda membagi instance database dalam beberapa instance yang lebih kecil dengan menggunakan partisi spesifik kriteria. Kriteria tersebut dapat didasarkan pada pelanggan atau subjek. Opsi ini memungkinkan Anda menskalakan operasi tulis dan baca secara horizontal. Namun, hal ini meningkatkan kompleksitas database dan workload aplikasi Anda. Hal ini juga dapat menimbulkan sharding yang tidak seimbang yang disebut hotspot, yang akan lebih besar daripada manfaat sharding. - Khusus untuk Cloud SQL untuk MySQL, pastikan tabel Anda memiliki {i>primary key<i} atau {i>unique key<i}. Cloud SQL menggunakan data berbasis baris replikasi, yang bekerja paling baik pada tabel dengan kunci utama atau unik.

Untuk detail selengkapnya, lihat Praktik terbaik umum dan Panduan operasional untuk Cloud SQL untuk MySQL.

Langkah selanjutnya

• Baca perjalanan migrasi AWS ke Google Cloud lainnya.
• Pelajari cara membandingkan layanan AWS dan Azure dengan Google Cloud.
• Pelajari kapan harus menemukan bantuan untuk migrasi.
• Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.

Kontributor

Penulis:

• Alex Cârciu | Arsitek Solusi
• Marco Ferrari | Arsitek Solusi Cloud

Kontributor lainnya:

• Derek Downey | Engineer Hubungan Developer
• Pawela Krentowski | Penulis Teknis
• Matius Santoso | Cloud Engineer Strategis
• Somdyuti Paul | Spesialis Pengelolaan Data
• Zach Seils | Spesialis Networking