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

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, menerapkan, dan memvalidasi project migrasi database. Panduan ini juga ditujukan untuk para pengambil keputusan yang sedang mengevaluasi peluang untuk melakukan migrasi dan menginginkan contoh seperti apa migrasi tersebut.

Dokumen ini berfokus pada migrasi database homogen, yaitu migrasi dengan database sumber dan tujuan menggunakan teknologi database yang sama. Dalam 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
• Bermigrasi dari Amazon RDS dan Amazon Aurora untuk MySQL ke Cloud SQL untuk MySQL (dokumen ini)
• Bermigrasi dari Amazon RDS dan Amazon Aurora untuk PostgreSQL ke Cloud SQL untuk PostgreSQL dan AlloyDB untuk PostgreSQL
• Bermigrasi dari Amazon RDS untuk SQL Server ke Cloud SQL untuk SQL Server
• Bermigrasi dari AWS Lambda ke Cloud Run

Untuk migrasi ini ke Google Cloud, sebaiknya ikuti framework migrasi yang dijelaskan dalam Migrasi ke Google Cloud: Memulai.

Diagram berikut menggambarkan jalur perjalanan migrasi Anda.

Anda dapat bermigrasi dari lingkungan sumber ke Google Cloud dalam serangkaian iterasi—misalnya, Anda dapat memigrasikan beberapa workload terlebih dahulu dan workload lainnya nanti. Untuk setiap iterasi migrasi terpisah, Anda harus mengikuti fase framework migrasi umum:

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

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

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

Menilai lingkungan sumber

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

Fase penilaian sangat penting untuk keberhasilan migrasi Anda. Anda perlu mendapatkan pengetahuan mendalam tentang workload yang ingin dimigrasikan, persyaratannya, dependensinya, 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 tentang 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 rencana dan jadwal migrasi.
9. Validasi rencana migrasi Anda.

Fase penilaian database membantu Anda memilih ukuran dan spesifikasi instance database Cloud SQL target yang cocok dengan sumber untuk kebutuhan performa yang serupa. Perhatikan dengan cermat ukuran dan throughput disk, IOPS, dan jumlah vCPU. Migrasi mungkin mengalami masalah atau gagal karena ukuran instance database target yang salah. Penentuan ukuran yang salah dapat menyebabkan waktu migrasi yang lama, masalah performa database, error database, dan masalah performa aplikasi. Saat memutuskan instance Cloud SQL, perlu diingat bahwa performa disk didasarkan pada ukuran disk dan jumlah vCPU.

Bagian berikut mengandalkan 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 menggunakan alat khusus, karena pendekatan manual rentan terhadap error dan dapat menyebabkan asumsi yang salah.

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

Tolok ukur dapat membantu Anda lebih memahami workload yang akan dimigrasikan dan berkontribusi dalam menentukan arsitektur yang tepat untuk lingkungan target migrasi. Mengumpulkan informasi tentang performa penting untuk membantu memperkirakan kebutuhan performa lingkungan target. Google Cloud Konsep dan alat benchmarking dijelaskan secara mendetail dalam tahap Lakukan pengujian dan validasi proses migrasi, tetapi juga berlaku untuk tahap pembuatan inventaris.

Alat untuk penilaian

Untuk penilaian ringkasan awal infrastruktur Anda saat ini, sebaiknya Anda menggunakan Pusat Migrasi Google Cloud bersama dengan alat penilaian database khusus lainnya seperti migVisor dan Database Migration Assessment Tool (DMA).

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

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

Selain Pusat Migrasi, Anda dapat menggunakan alat khusus migVisor. migVisor mendukung berbagai mesin database dan sangat cocok untuk migrasi heterogen. Untuk pengantar tentang migVisor, lihat ringkasan migVisor.

migVisor dapat mengidentifikasi artefak dan fitur database eksklusif yang tidak kompatibel yang dapat menyebabkan migrasi gagal, dan dapat menunjukkan solusinya. migVisor juga dapat merekomendasikan solusi target, termasuk ukuran dan arsitektur awal. Google Cloud

Output penilaian database migVisor memberikan informasi berikut:

• Penemuan dan analisis komprehensif pada deployment database saat ini.
• Laporan mendetail tentang kompleksitas migrasi, berdasarkan fitur eksklusif yang digunakan oleh database Anda.
• Laporan keuangan dengan detail tentang penghematan biaya setelah migrasi, biaya migrasi, dan anggaran operasional baru.
• Rencana migrasi bertahap untuk memindahkan database dan aplikasi terkait dengan gangguan minimal pada bisnis.

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

Perhatikan bahwa migVisor akan meningkatkan pemanfaatan server database untuk sementara. Biasanya, beban tambahan ini kurang dari 3%, dan dapat dijalankan selama jam non-puncak.

Output penilaian migVisor membantu Anda membuat inventaris lengkap instance RDS. Laporan ini mencakup properti umum (versi dan edisi mesin database, CPU, dan ukuran memori), serta detail tentang topologi database, kebijakan pencadangan, setelan parameter, dan penyesuaian khusus yang digunakan.

Jika lebih suka menggunakan alat open source, Anda dapat menggunakan skrip pengumpul data dengan (atau sebagai pengganti) alat yang disebutkan. Skrip ini dapat membantu Anda mengumpulkan informasi mendetail (tentang beban kerja, fitur, objek database, dan kode database) serta membuat inventaris database Anda. Selain itu, skrip biasanya memberikan penilaian migrasi database yang mendetail, termasuk estimasi upaya migrasi.

Sebaiknya gunakan alat open source DMA, yang dibuat oleh engineer Google. Layanan ini menawarkan penilaian database yang lengkap dan akurat, termasuk fitur yang digunakan, logika database, dan objek database (termasuk skema, tabel, tampilan, fungsi, pemicu, dan prosedur tersimpan).

Untuk menggunakan DMA, download skrip pengumpulan untuk mesin database Anda dari repositori Git, lalu ikuti petunjuknya. Kirim file output ke Google Cloud untuk dianalisis. Google Cloud membuat dan memberikan hasil 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 Anda. Sekarang, Anda dapat menjawab pertanyaan berikut:

• Apakah database Anda lebih besar dari 5 TB?
• Apakah ada tabel besar dalam database Anda? Apakah ukurannya lebih besar dari 16 TB?
• Di mana lokasi database (region dan zona), dan seberapa dekat database tersebut dengan aplikasi?
• Seberapa sering data berubah?
• Apa model konsistensi data Anda?
• Apa saja opsi untuk database tujuan?
• Seberapa kompatibel database sumber dan tujuan?
• Apakah data perlu berada di beberapa lokasi fisik?
• Apakah ada data yang dapat dikompresi dan diarsipkan, atau apakah ada data yang tidak perlu dimigrasikan sama sekali?

Untuk menentukan cakupan migrasi, putuskan data mana yang akan disimpan dan data mana yang akan dimigrasikan. Memigrasikan semua database Anda mungkin memerlukan waktu dan upaya yang cukup besar. Beberapa data mungkin tetap ada di cadangan database sumber Anda. Misalnya, tabel logging lama atau data arsip mungkin tidak diperlukan. Atau, Anda dapat memutuskan untuk memindahkan data setelah proses migrasi, bergantung pada strategi dan alat Anda.

Tetapkan dasar migrasi data yang membantu Anda membandingkan dan mengevaluasi hasil dan dampak. Dasar ini adalah titik referensi yang merepresentasikan status data Anda sebelum dan setelah migrasi serta membantu Anda mengambil keputusan. Penting untuk melakukan pengukuran di lingkungan sumber yang dapat membantu Anda mengevaluasi keberhasilan migrasi data. Pengukuran tersebut mencakup hal berikut:

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

Tentukan berapa lama waktu nonaktif yang dapat Anda toleransi. Apa dampak bisnis dari periode nonaktif? Apakah ada periode aktivitas database rendah, yang selama periode tersebut lebih sedikit pengguna yang terpengaruh oleh periode nonaktif? Jika ya, berapa lama periode tersebut dan kapan terjadinya? Pertimbangkan untuk hanya menghentikan penulisan sebagian, sementara permintaan hanya baca tetap dilayani.

Menilai proses deployment dan administrasi Anda

Setelah membangun inventaris, nilai proses operasional dan deployment untuk database Anda guna menentukan cara Anda perlu menyesuaikannya untuk memfasilitasi migrasi Anda. Proses ini sangat penting untuk cara Anda menyiapkan dan memelihara lingkungan produksi Anda.

Pertimbangkan cara Anda menyelesaikan tugas-tugas berikut:

• Tentukan dan terapkan kebijakan keamanan untuk instance Anda: 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 dan membatasi data dalam VPC.

• Patch dan konfigurasi instance Anda: Alat deployment yang ada mungkin perlu diupdate. Misalnya, Anda mungkin menggunakan setelan konfigurasi kustom di grup parameter Amazon atau grup opsi Amazon. Alat penyediaan Anda mungkin perlu disesuaikan untuk menggunakan Google Cloud Storage atau Secret Manager guna membaca daftar konfigurasi kustom tersebut.

• Mengelola infrastruktur pemantauan dan pemberitahuan: Kategori metrik untuk instance database sumber Amazon Anda memberikan kemampuan pengamatan selama proses migrasi. Kategori metrik dapat mencakup Amazon CloudWatch, Performance Insights, Pemantauan yang Ditingkatkan, dan daftar proses OS.

Menyelesaikan penilaian

Setelah Anda mem-build inventaris dari lingkungan Amazon RDS atau Amazon Aurora, selesaikan aktivitas fase penilaian lainnya seperti yang dijelaskan dalam Bermigrasi ke Google Cloud: Menilai dan menemukan beban kerja Anda.

Merencanakan dan membangun fondasi Anda

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

• Mendukung workload Anda di lingkungan Google Cloud .
• Hubungkan lingkungan sumber dan lingkungan Google Cloud Anda untuk menyelesaikan migrasi.

Fase perencanaan dan build terdiri dari tugas-tugas berikut:

1. Mem-build 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 mengetahui informasi selengkapnya tentang setiap tugas ini, lihat Bermigrasi ke Google Cloud: Merencanakan dan membangun fondasi 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 Cloud Monitoring Google, yang mencakup dasbor yang telah ditetapkan untuk beberapa produk, termasuk dasbor pemantauan Cloud SQL. Google Cloud Atau, Anda dapat mempertimbangkan penggunaan solusi pemantauan pihak ketiga yang terintegrasi denganGoogle Cloud, seperti Datadog dan Splunk. Untuk mengetahui 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 dapat melakukan hal berikut:

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

2. Pilih alat migrasi, bergantung pada strategi dan persyaratan yang Anda pilih.

3. Tentukan rencana dan jadwal migrasi untuk setiap migrasi database, termasuk tugas persiapan dan eksekusi.

4. Tentukan tugas persiapan yang harus dilakukan untuk memastikan alat migrasi dapat berfungsi dengan baik.

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

6. Tentukan skenario penggantian untuk setiap tugas eksekusi.

7. Lakukan pengujian dan validasi, yang dapat dilakukan di lingkungan penyiapan terpisah.

8. Lakukan migrasi.

9. Lakukan peralihan produksi.

10. Kosongkan lingkungan sumber dan konfigurasi instance target.

11. Lakukan penyesuaian dan pengoptimalan.

Setiap fase dijelaskan di bagian berikut.

Memilih strategi migrasi Anda

Pada langkah ini, Anda memiliki cukup informasi untuk mengevaluasi dan memilih salah satu strategi migrasi berikut yang paling sesuai dengan kasus penggunaan Anda untuk setiap database:

• Pemeliharaan terjadwal (juga disebut migrasi satu kali atau migrasi besar-besaran): Pendekatan ini ideal jika Anda dapat mentoleransi periode nonaktif. Opsi ini relatif lebih rendah biaya 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 nonaktif.

• Replikasi berkelanjutan (juga disebut migrasi online atau migrasi bertahap): Untuk database penting, opsi ini menawarkan risiko kehilangan data yang lebih rendah dan periode nonaktif yang hampir nol. Upaya ini dibagi menjadi beberapa bagian, sehingga jika terjadi kegagalan, rollback dan pengulangan akan membutuhkan waktu lebih sedikit. Namun, penyiapannya lebih rumit dan memerlukan lebih banyak perencanaan dan waktu. Upaya tambahan juga diperlukan untuk memfaktorkan ulang aplikasi yang terhubung ke instance database Anda. Pertimbangkan salah satu variasi berikut:

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

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

Diagram berikut menunjukkan diagram alur berdasarkan contoh pertanyaan yang mungkin Anda miliki saat memutuskan strategi migrasi untuk satu database:

Diagram alur sebelumnya menunjukkan poin-poin keputusan berikut:

• Dapatkah Anda mentoleransi periode nonaktif?

  • Jika tidak, terapkan strategi migrasi replikasi berkelanjutan.
  • Jika ya, lanjutkan ke titik keputusan berikutnya.

• Dapatkah Anda membayar periode nonaktif yang diwakili oleh periode migrasi sistem saat memigrasikan data? Jendela peralihan menunjukkan jumlah waktu yang diperlukan untuk mencadangkan database, mentransfernya ke Cloud SQL, memulihkannya, lalu mengalihkan aplikasi Anda.

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

Strategi dapat bervariasi untuk database yang berbeda, meskipun database tersebut berada di instance yang sama. Kombinasi strategi dapat menghasilkan hasil yang optimal. Misalnya, migrasikan database kecil dan yang jarang digunakan dengan menggunakan pendekatan pemeliharaan terjadwal, tetapi gunakan replikasi berkelanjutan untuk database penting yang tidak boleh mengalami periode nonaktif.

Biasanya, migrasi dianggap selesai saat peralihan antara instance sumber awal dan instance target terjadi. Replikasi apa pun (jika digunakan) dihentikan dan semua operasi baca dan tulis dilakukan pada instance target. Melakukan peralihan saat kedua instance disinkronkan berarti tidak ada kehilangan data dan waktu henti minimal.

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

Meminimalkan waktu non-operasional dan dampak terkait migrasi

Konfigurasi migrasi yang tidak menyebabkan aplikasi tidak tersedia memerlukan penyiapan yang lebih rumit. Temukan keseimbangan yang tepat antara kompleksitas penyiapan dan waktu henti yang dijadwalkan selama jam operasional bisnis dengan traffic rendah.

Setiap strategi migrasi memiliki kelebihan dan kekurangan serta beberapa dampak yang terkait dengan proses migrasi. Misalnya, proses replikasi melibatkan beberapa beban tambahan pada instance sumber dan aplikasi Anda mungkin terpengaruh oleh jeda replikasi. Aplikasi (dan pelanggan) mungkin harus menunggu selama waktu nonaktif aplikasi, setidaknya selama jeda replikasi berlangsung sebelum menggunakan database baru. Dalam praktiknya, faktor-faktor berikut dapat meningkatkan waktu nonaktif:

• Kueri database dapat memerlukan waktu beberapa detik hingga selesai. Pada saat migrasi, kueri yang sedang berlangsung mungkin dibatalkan.
• Cache mungkin memerlukan waktu beberapa saat untuk terisi jika database berukuran besar atau memiliki memori buffer yang besar.
• Aplikasi yang dihentikan di sumber dan dimulai ulang di Google Cloud mungkin mengalami sedikit jeda hingga koneksi ke instance database Google Cloud dibuat.
• Rute jaringan ke aplikasi harus dialihkan. Bergantung pada cara penyiapan entri DNS, proses ini dapat memerlukan waktu beberapa saat. Saat Anda memperbarui data DNS, kurangi TTL sebelum migrasi.

Praktik umum berikut dapat membantu meminimalkan periode nonaktif dan dampak:

• Temukan jangka waktu saat periode nonaktif akan memberikan dampak minimal pada workload Anda. Misalnya, di luar jam kerja normal, selama akhir pekan, atau selama masa pemeliharaan terjadwal lainnya.
• Identifikasi bagian workload yang dapat dimigrasikan dan dialihkan ke produksi pada tahap yang berbeda. Aplikasi Anda mungkin memiliki komponen berbeda yang dapat diisolasi, disesuaikan, dan dimigrasikan tanpa dampak. Misalnya, frontend, modul CRM, layanan backend, dan platform pelaporan. Modul tersebut dapat memiliki database sendiri yang dapat dijadwalkan untuk migrasi lebih awal atau lebih lambat dalam prosesnya.
• Jika Anda dapat mentoleransi beberapa latensi pada database target, pertimbangkan untuk menerapkan migrasi bertahap. Gunakan transfer data inkremental dan batch, serta sesuaikan sebagian beban kerja Anda agar berfungsi dengan data yang tidak berlaku lagi di instance target.
• Pertimbangkan untuk memfaktorkan ulang aplikasi Anda guna mendukung dampak migrasi yang minimal. Misalnya, sesuaikan aplikasi Anda untuk menulis ke database sumber dan target, sehingga menerapkan replikasi tingkat aplikasi.

Pilih alat migrasi Anda

Faktor terpenting untuk keberhasilan migrasi adalah memilih alat migrasi yang tepat. Setelah strategi migrasi diputuskan, tinjau dan putuskan alat migrasi yang akan digunakan.

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. Makin besar database, makin lama waktu yang diperlukan untuk memigrasikan cadangan awal.
• Frekuensi perubahan database.
• Ketersediaan untuk menggunakan layanan terkelola untuk migrasi.

Untuk memastikan migrasi dan pengalihan yang lancar, Anda dapat menggunakan pola deployment aplikasi, 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 ke lingkungan lain. Mereka menjalankan ekstraksi data dari database sumber, memindahkan data ke database target dengan aman, dan dapat mengubah data selama pengiriman secara opsional. Dengan kemampuan ini, mereka merangkum logika migrasi yang kompleks dan menawarkan kemampuan pemantauan migrasi.

Layanan migrasi terkelola memberikan keuntungan berikut:

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

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

• Memberikan pengalaman migrasi yang konsisten: Berbagai teknik dan pola migrasi dapat digabungkan ke dalam antarmuka umum yang konsisten menggunakan file yang dapat dieksekusi untuk migrasi database, yang dapat Anda kelola dan pantau.

• Menawarkan model migrasi yang tangguh dan terbukti: Migrasi database adalah peristiwa yang jarang terjadi, tetapi penting. Untuk menghindari kesalahan pemula dan masalah dengan solusi yang ada, Anda dapat menggunakan alat dari pakar berpengalaman, daripada membuat solusi kustom.

• Mengoptimalkan biaya: Layanan migrasi terkelola bisa lebih hemat biaya daripada menyediakan server dan resource tambahan untuk solusi migrasi kustom.

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

Alat untuk migrasi pemeliharaan terjadwal

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

Diagram alur sebelumnya menunjukkan poin-poin keputusan berikut:

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

Menggunakan layanan migrasi terkelola memberikan beberapa keuntungan, yang dibahas di bagian Pilih alat migrasi Anda dalam dokumen ini.

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

Database Migration Service untuk migrasi pemeliharaan terjadwal

Database Migration Service mengelola sinkronisasi awal dan replikasi pengambilan data perubahan (CDC) yang sedang berlangsung, serta memberikan status operasi migrasi.

Dengan menggunakan Database Migration Service, Anda dapat membuat tugas migrasi yang dapat dikelola dan diverifikasi. Sebaiknya Anda menggunakan Database Migration Service, karena layanan ini mendukung migrasi ke Cloud SQL for MySQL melalui tugas migrasi satu kali. Untuk database besar, Anda dapat menggunakan paralelisme dump data di Database Migration Service.

Untuk mengetahui 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 mengetahui informasi selengkapnya tentang batasan dan prasyarat Database Migration Service, lihat hal berikut:

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

Pencadangan mesin database bawaan

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

Beberapa upaya diperlukan untuk penyiapan dan sinkronisasi, terutama untuk sejumlah besar database, tetapi pencadangan mesin database biasanya tersedia dan mudah digunakan.

Pencadangan mesin database memiliki batasan umum berikut:

• Pencadangan dapat rentan terhadap error, terutama jika dilakukan secara manual.
• Data tidak aman jika cadangan tidak dikelola dengan benar.
• Cadangan tidak memiliki kemampuan pemantauan yang tepat.
• Diperlukan upaya untuk melakukan penskalaan, jika banyak database dimigrasikan menggunakan alat ini.

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

• 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 mengimpor database yang lebih besar dari 10 GB, Anda mungkin memerlukan beberapa strategi lain untuk meminimalkan waktu nonaktif database. Beberapa strategi tersebut adalah sebagai berikut:

  • Mengekspor skema dan data dalam subbagian, tanpa kunci sekunder.
  • Manfaatkan stempel waktu. Jika ada tabel yang menggunakan kolom stempel waktu, Anda dapat menggunakan fitur perintah mysqldump yang memungkinkan Anda menentukan klausa WHERE untuk memfilter menurut kolom stempel waktu.
  • Pertimbangkan pendekatan lain seperti menggunakan alat mydumper dan myloader.

Dump dan cadangan database biasanya tidak menyertakan akun pengguna MySQL. Saat bersiap melakukan migrasi, tinjau semua akun pengguna di instance sumber. Misalnya, Anda dapat menjalankan perintah SHOW GRANTS untuk setiap pengguna guna meninjau kumpulan hak istimewa saat ini dan melihat apakah ada yang dibatasi di Cloud SQL. Demikian pula, alat pt-show-grants dari Percona juga dapat mencantumkan pemberian.

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

Untuk membaca lebih lanjut tentang batasan dan praktik terbaik, lihat artikel berikut:

• 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 database MySQL eksternal, ada pemuatan awal data dari database eksternal ke instance Cloud SQL. Pendekatan ini menggunakan layanan yang mengekstrak data dari server eksternal - instance RDS dalam kasus ini - dan mengimpornya secara langsung ke instance Cloud SQL.

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

Anda dapat mempertimbangkan untuk mengekspor tabel dari database MySQL 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 mengetahui informasi dan langkah-langkah selengkapnya, lihat Menggunakan impor terkelola untuk menyiapkan replikasi dari database eksternal.

Alat untuk migrasi replikasi berkelanjutan

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

Diagram alur sebelumnya menunjukkan poin-poin keputusan berikut:

• Apakah Anda lebih memilih menggunakan layanan migrasi terkelola?

  • Jika ya, dapatkah Anda mentoleransi waktu nonaktif penulisan selama beberapa detik, bergantung pada jumlah tabel dalam database 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 pelajari opsi migrasi lainnya.

Bagian berikut menjelaskan alat yang dapat digunakan untuk migrasi berkelanjutan, beserta batasan 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 harus dihentikan.

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

• Hindari transaksi yang berjalan lama selama migrasi. Dalam kasus tersebut, sebaiknya lakukan migrasi dari replika baca jika Anda tidak melakukan migrasi 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 database merepresentasikan proses penyalinan dan pendistribusian data dari database yang disebut database utama ke database lain yang disebut replika. Fitur ini ditujukan untuk meningkatkan aksesibilitas data serta meningkatkan fault tolerance dan keandalan sistem database. Meskipun migrasi database bukan tujuan utama replikasi database, migrasi database dapat berhasil digunakan sebagai alat untuk mencapai tujuan ini. Replikasi database biasanya merupakan proses berkelanjutan yang terjadi secara real time saat data disisipkan, diperbarui, atau dihapus di database primer. Hal ini dapat dilakukan sebagai operasi satu kali, atau serangkaian operasi batch.

Sebagian besar mesin database modern menerapkan berbagai cara untuk mencapai replikasi database. Salah satu jenis replikasi dapat dicapai dengan menyalin dan mengirimkan log tulis-tulis atau log transaksi dari primer ke replikanya. Pendekatan ini disebut replikasi fisik atau biner. Jenis replikasi lainnya berfungsi dengan mendistribusikan pernyataan SQL mentah yang diterima database 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 instance Amazon RDS atau Amazon Aurora Anda.
• Pastikan log biner diaktifkan.
• Untuk mempercepat fase dump penuh awal, pilih tingkat mesin yang cukup besar dari perspektif ukuran CPU dan memori.
• Jika perlu mempercepat fase CDC, Anda dapat mencoba mengonfigurasi replikasi paralel dan mengaktifkan flushing berperforma tinggi.
• Jika replika Cloud SQL diaktifkan dengan alamat IP internal karena alamat IP keluar tidak statis, konfigurasikan firewall server Amazon RDS atau Amazon Aurora untuk mengizinkan rentang IP internal yang dialokasikan untuk akses layanan pribadi jaringan VPC yang digunakan replika Cloud SQL sebagai jaringan pribadinya. Untuk mengetahui informasi selengkapnya, lihat Tentang mereplikasi dari server eksternal dan Mengonfigurasi akses layanan pribadi.

Batasan:

• Jika Anda memiliki satu tabel besar dan banyak indeks sekunder dalam database, dump lengkap awal mungkin memerlukan waktu lebih lama.
• Jika server eksternal Anda berisi klausa DEFINER (pada tampilan, peristiwa, pemicu, atau prosedur tersimpan), bergantung pada urutan kapan pernyataan ini dijalankan, proses replikasi kemungkinan akan mengalami kegagalan. Pelajari lebih lanjut penggunaan DEFINER dan kemungkinan solusi di Cloud SQL.
• InnoDB adalah satu-satunya mesin database yang didukung di Cloud SQL. Bermigrasi dari MyISAM dapat menyebabkan inkonsistensi data dan validasi data perlu dilakukan. 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 berfokus pada refaktorisasi atau pengembangan alat yang terhubung ke instance database Anda.
  • Aplikasi pembaca kemudian difaktorkan ulang dan di-deploy secara bertahap untuk menggunakan instance target.

• Mereplikasi perubahan instance MySQL Anda yang mendekati real-time dengan menggunakan Datastream.

  • 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 ke BigQuery atau Cloud Storage, lalu gunakan Dataflow atau Dataproc untuk memasukkan data ke instance Cloud SQL Anda.

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

• Mengonfigurasi database Amazon RDS for MySQL di Datastream
• Mengonfigurasi database Amazon Aurora MySQL di Datastream
• Melakukan streaming perubahan pada data secara real time dengan Datastream

Alat pihak ketiga untuk migrasi replikasi berkelanjutan

Dalam beberapa kasus, sebaiknya gunakan satu alat pihak ketiga untuk sebagian besar mesin database. Kasus tersebut mungkin terjadi jika Anda lebih memilih menggunakan layanan migrasi terkelola dan Anda perlu memastikan bahwa database target selalu disinkronkan dengan sumber dalam waktu hampir real-time, atau jika Anda memerlukan transformasi yang lebih kompleks seperti pembersihan, penataan ulang, dan adaptasi data selama proses migrasi.

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

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

• Kelebihan:

  • Menangani volume data besar dan migrasi yang kompleks.
  • Pengambilan data perubahan bawaan untuk SQL Server.
  • Template koneksi yang telah dikonfigurasi sebelumnya dan pipeline tanpa kode.
  • Dapat menangani database besar yang sangat penting dan beroperasi di bawah beban transaksional yang berat.
  • Pengiriman tepat satu kali.

• Kekurangan:

  • Bukan open source.
  • Bisa menjadi mahal, terutama untuk migrasi yang lama.
  • Beberapa batasan dalam propagasi operasi bahasa definisi data (DDL). Untuk mengetahui informasi selengkapnya, lihat Operasi DDL yang didukung dan Catatan dan batasan evolusi skema.

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

Debezium adalah platform terdistribusi open source untuk CDC, dan dapat melakukan streaming perubahan data ke pelanggan eksternal:

• Kelebihan:

  • Open source.
  • Dukungan komunitas yang kuat.
  • Hemat biaya.
  • Kontrol terperinci pada baris, tabel, atau database.
  • Khusus untuk pengambilan perubahan secara real time dari log transaksi database.

• Kekurangan:

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

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

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

• Kelebihan:

  • Template koneksi yang telah dikonfigurasi sebelumnya dan pipeline tanpa kode.
  • Menyebarkan perubahan skema dari database sumber ke database target.
  • Pengiriman perubahan data Anda tepat satu kali, yang berarti Anda tidak perlu menangani duplikat.

• Kekurangan:

  • Bukan open source.
  • Dukungan untuk transformasi data yang kompleks terbatas.

Menentukan rencana dan jadwal migrasi

Untuk keberhasilan migrasi database dan peralihan produksi, sebaiknya Anda menyiapkan rencana migrasi yang komprehensif dan terdefinisi dengan baik. Untuk membantu mengurangi dampak pada bisnis Anda, sebaiknya buat daftar semua item pekerjaan yang diperlukan.

Menentukan cakupan migrasi akan mengungkapkan tugas-tugas yang harus Anda lakukan sebelum, selama, dan setelah proses migrasi database. Misalnya, jika Anda memutuskan untuk tidak memigrasikan tabel tertentu dari database, Anda mungkin memerlukan tugas pra-migrasi atau pasca-migrasi untuk menerapkan pemfilteran ini. Anda juga memastikan bahwa migrasi database tidak memengaruhi perjanjian tingkat layanan (SLA) dan rencana kelangsungan bisnis yang ada.

Sebaiknya dokumentasi perencanaan migrasi Anda menyertakan dokumen berikut:

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

Migrasi database adalah proses iteratif, dan migrasi pertama sering kali lebih lambat daripada migrasi berikutnya. Biasanya, migrasi yang direncanakan dengan baik berjalan tanpa masalah, tetapi masalah yang tidak direncanakan masih dapat muncul. Sebaiknya Anda selalu memiliki rencana rollback. Sebagai praktik terbaik, ikuti panduan dari Bermigrasi ke Google Cloud: Praktik terbaik untuk memvalidasi rencana migrasi.

TDD

TDD mendokumentasikan semua keputusan teknis yang harus dibuat untuk project. Sertakan hal berikut dalam TDD:

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

Matriks RACI

Beberapa project migrasi memerlukan matriks RACI, yang merupakan dokumen manajemen project umum yang menentukan individu atau grup mana yang bertanggung jawab atas tugas dan hasil dalam project migrasi.

Linimasa

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

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

Linimasa tidak hanya harus memperhitungkan pelaksanaan tugas persiapan pra-migrasi, tetapi juga tugas validasi, audit, atau pengujian yang terjadi setelah transfer data dilakukan.

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

Rencana T-Minus mungkin terlihat seperti berikut:

Tanggal	Fase	Kategori	Tasks	Peran	T-minus	Status
1/11/2023	Pra-migrasi	Penilaian	Membuat laporan penilaian	Tim penemuan	-21	Selesai
7/11/2023	Pra-migrasi	Persiapan target	Mendesain lingkungan target seperti yang dijelaskan dalam 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	Membangun 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	Migrasi DMS	Mempromosikan 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 performa dan kemampuan	Tim migrasi	0	Belum dimulai
22/11/2023	Migrasi	Tata kelola perusahaan	Validasi migrasi SIAP atau TIDAK SIAP	Tim migrasi	1	Belum dimulai
23/11/2023	Pascamigrasi	Memvalidasi pemantauan	Mengonfigurasi pemantauan	Tim infrastruktur	2	Belum dimulai
25/11/2023	Pascamigrasi	Keamanan	Menghapus akun pengguna DMS	Tim keamanan	4	Belum dimulai

Migrasi beberapa database

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

Sebaiknya Anda memulai proses dengan memigrasikan database yang lebih kecil dan idealnya tidak penting untuk misi. Pendekatan ini dapat membantu Anda membangun pengetahuan dan kepercayaan diri dalam proses dan alat migrasi. Anda juga dapat mendeteksi kekurangan dalam proses pada tahap awal jadwal migrasi keseluruhan.

Jika Anda memiliki beberapa database untuk dimigrasikan, jadwalnya dapat diparalelkan. Misalnya, untuk mempercepat proses migrasi, Anda dapat memilih untuk memigrasikan sekelompok database kecil, statis, atau yang kurang penting secara bersamaan, seperti yang ditunjukkan dalam diagram berikut.

Dalam contoh yang ditunjukkan dalam diagram, database 1-4 adalah sekelompok database kecil yang dimigrasikan secara bersamaan.

Menentukan tugas persiapan

Tugas persiapan adalah semua aktivitas yang perlu Anda selesaikan untuk memenuhi prasyarat migrasi. Tanpa tugas persiapan, migrasi tidak dapat dilakukan atau migrasi akan menyebabkan database yang dimigrasikan menjadi 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 tugas penyiapan dan prasyarat umum berikut:

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

• Anda mungkin perlu mengonfigurasi grup keamanan baru untuk mengizinkan koneksi jarak jauh di port yang diperlukan.

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

• Pastikan Anda memiliki cukup ruang disk kosong untuk menyimpan log WAL selama durasi operasi pemuatan penuh di instance Amazon RDS Anda.

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

• MySQL membatasi hostname hingga 60 karakter. Nama host database Amazon RDS biasanya lebih dari 60 karakter. Jika hal ini terjadi pada database yang Anda migrasikan, konfigurasi pengalihan DNS untuk membuat data CNAME yang mengaitkan nama domain Anda dengan nama domain instance database RDS Anda.

• Jika menggunakan replikasi bawaan, Anda harus menyiapkan instance Amazon RDS atau Amazon Aurora untuk replikasi. Replikasi bawaan, atau alat 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 tersebut. Periksa dokumentasi dari alat pihak ketiga.

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

Persiapan dan prasyarat database sumber

• Jika memilih untuk menggunakan Database Migration Service, Anda harus mengonfigurasi database sumber sebelum terhubung ke database tersebut. Tinjau tugas migrasi sebelum menerapkan tugas. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi sumber untuk MySQL.
• Bergantung pada mesin database, Anda mungkin perlu mengubah fitur tertentu. Misalnya, Cloud SQL untuk MySQL hanya mendukung mesin database InnoDB. Anda harus mengubah tabel MyISAM ke InnoDB.
• Beberapa alat migrasi pihak ketiga mengharuskan semua kolom LOB dapat bernilai null. Kolom LOB yang NOT NULL harus menghapus batasan tersebut selama migrasi.

• Lakukan pengukuran dasar pada lingkungan sumber Anda dalam penggunaan produksi. Pertimbangkan hal berikut:

  • Ukur ukuran data Anda, serta performa workload Anda. Berapa lama waktu yang diperlukan untuk menyelesaikan kueri atau transaksi penting, secara rata-rata? Berapa lama waktu yang dibutuhkan saat jam sibuk?
  • Dokumentasikan pengukuran dasar untuk perbandingan selanjutnya, guna membantu Anda memutuskan apakah fidelitas migrasi database Anda memuaskan. Tentukan apakah Anda dapat mengalihkan workload produksi dan menonaktifkan lingkungan sumber, atau apakah Anda masih memerlukannya untuk tujuan penggantian.

Penyiapan Cloud SQL

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

Anda harus mengonfirmasi properti dan persyaratan berikut sebelum membuat instance Cloud SQL, karena properti dan persyaratan tersebut tidak dapat diubah nanti tanpa membuatnya ulang.

• Pilih project dan region instance Cloud SQL target Anda dengan cermat. Instance Cloud SQL tidak dapat dimigrasikan antar- Google Cloud project dan region tanpa transfer data.
• Migrasikan 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.
• Mereplikasi informasi pengguna secara terpisah, jika Anda menggunakan cadangan mesin database bawaan atau Database Migration Service. Cloud SQL mengelola pengguna menggunakan IAM Google. Untuk mengetahui detailnya, tinjau batasan di bagian Pencadangan mesin database bawaan.
• Tinjau flag konfigurasi mesin database dan bandingkan nilai instance sumber dan targetnya. Pastikan Anda memahami dampaknya dan apakah semuanya harus sama atau tidak. Misalnya, sebaiknya jalankan perintah SHOW VARIABLES di database sumber sebelum migrasi, lalu jalankan lagi di database Cloud SQL. Perbarui setelan flag sesuai kebutuhan di database Cloud SQL untuk mereplikasi setelan sumber. Perhatikan bahwa tidak semua flag MySQL diizinkan pada 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 Anda 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 database utama Anda. Akses ini dapat dilakukan melalui opsi konektivitas yang didokumentasikan.

Bergantung pada skenario dan tingkat keparahan, Anda mungkin perlu menerapkan skenario penggantian, yang biasanya mencakup membalikkan arah replikasi. Dalam hal ini, Anda mungkin memerlukan 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 harus menggunakan Google Cloud Marketplace untuk memulai. Kemudian, untuk menyiapkan lingkungan migrasi di Striim, Anda dapat menggunakan Flow Designer untuk membuat dan mengubah aplikasi, atau memilih template yang sudah ada. Aplikasi juga dapat dikodekan menggunakan bahasa pemrograman Tungsten Query Language (TQL). Dengan menggunakan dasbor validasi data, Anda bisa mendapatkan representasi visual data yang ditangani oleh aplikasi Striim Anda.

Anda dapat menonaktifkan resource yang menghubungkan lingkungan Amazon danGoogle 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 menerapkan pekerjaan migrasi itu sendiri. Tugas ini bergantung pada alat migrasi yang Anda pilih, seperti yang dijelaskan di subbagian berikut.

Pencadangan 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 mendapatkan petunjuk, lihat Mengimpor 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 Layanan Migrasi Database untuk memigrasikan data dari instance sumber ke database tujuan. Tugas migrasi terhubung ke instance database sumber melalui profil koneksi yang ditentukan pengguna.

Uji semua prasyarat untuk memastikan tugas dapat berjalan dengan berhasil. Pilih waktu saat beban kerja Anda dapat mengatasi sedikit periode nonaktif untuk migrasi dan peralihan produksi.

Di Database Migration Service, migrasi dimulai dengan pencadangan dan pemuatan penuh awal, diikuti dengan aliran perubahan berkelanjutan dari sumber ke instance database tujuan.

Database Migration Service memerlukan beberapa detik untuk mendapatkan kunci baca di semua tabel dalam instance Amazon RDS atau Amazon Aurora sumber yang diperlukan untuk melakukan dump lengkap awal secara konsisten. Untuk mencapai kunci baca, mungkin diperlukan waktu nonaktif penulisan antara 1 dan 49 detik. Waktu nonaktif bergantung pada jumlah tabel dalam database Anda, dengan 1 detik sesuai dengan 100 tabel dan 9 detik sesuai dengan 10.000 tabel.

Proses migrasi dengan Database Migration Service diakhiri dengan operasi promosi. Mempromosikan instance database akan memutuskan koneksi database tujuan dari alur perubahan yang berasal dari database sumber, lalu instance tujuan yang kini berdiri sendiri dipromosikan menjadi instance utama. Pendekatan ini juga terkadang disebut pengalihan produksi.

Untuk mengetahui 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 Memigrasikan database ke Cloud SQL untuk MySQL menggunakan Database Migration Service. Di Database Migration Service, migrasi dilakukan dengan memulai dan menjalankan tugas migrasi.

Replikasi bawaan mesin database

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

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

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

Untuk mengetahui 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 Mengonfigurasi Cloud SQL dan server eksternal untuk replikasi.

Untuk informasi dan panduan selengkapnya, lihat:

• Mengekspor database ke bucket Cloud Storage
• Menggunakan impor terkelola untuk menyiapkan replikasi dari database eksternal
• Mulai replikasi pada 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, lalu mengirimkan data ke aplikasi atau target lain.

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

Untuk menyiapkan lingkungan migrasi di Striim, Anda dapat menggunakan fitur Flow Designer untuk membuat dan mengubah aplikasi, atau memilih dari sejumlah template yang sudah ada. Aplikasi juga dapat dikodekan menggunakan bahasa pemrograman TQL.

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

Untuk memulai cepat Striim di Google Cloud, lihat Menjalankan Striim di Google Cloud. Untuk mempelajari lebih lanjut 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:

• Beri tahu tim yang terlibat setiap kali langkah rencana dimulai dan selesai.
• Jika salah satu langkah membutuhkan waktu lebih lama dari yang diharapkan, bandingkan waktu yang telah berlalu dengan jumlah waktu maksimum yang dialokasikan untuk setiap langkah. Berikan info terbaru perantara secara rutin kepada tim yang terlibat saat hal ini terjadi.
• Jika rentang waktu lebih besar daripada jumlah waktu maksimum yang dicadangkan untuk setiap langkah dalam rencana, pertimbangkan untuk membatalkan perubahan.
• Buat keputusan "lanjut atau tidak" untuk setiap langkah migrasi dan rencana peralihan.
• Pertimbangkan tindakan rollback atau skenario alternatif untuk setiap langkah.

Menentukan skenario penggantian

Tentukan item tindakan penggantian untuk setiap tugas eksekusi migrasi, untuk melindungi dari masalah tak terduga yang mungkin terjadi selama proses migrasi. Tugas penggantian biasanya bergantung pada strategi migrasi dan alat yang digunakan.

Penggantian mungkin memerlukan upaya yang signifikan. Sebagai praktik terbaik, jangan lakukan peralihan produksi hingga hasil pengujian Anda memuaskan. Migrasi database dan skenario penggantian harus diuji dengan benar untuk menghindari gangguan parah.

Tentukan kriteria keberhasilan dan batasi waktu semua tugas eksekusi migrasi Anda. Melakukan uji coba migrasi membantu mengumpulkan informasi tentang perkiraan waktu untuk setiap tugas. Misalnya, untuk migrasi pemeliharaan terjadwal, Anda dapat membayar periode nonaktif yang diwakili oleh periode migrasi sistem. Namun, Anda harus merencanakan tindakan selanjutnya jika tugas migrasi satu kali atau pemulihan cadangan gagal di tengah proses. Bergantung pada berapa banyak waktu periode nonaktif yang direncanakan telah berlalu, Anda mungkin harus menunda migrasi jika tugas migrasi tidak selesai dalam jangka waktu yang diharapkan.

Rencana penggantian biasanya mengacu pada mengembalikan migrasi setelah Anda melakukan peralihan produksi, jika masalah pada instance target muncul. Jika Anda menerapkan rencana penggantian, ingatlah bahwa rencana tersebut harus diperlakukan sebagai migrasi database menyeluruh, termasuk perencanaan dan pengujian.

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

Meskipun penggantian adalah upaya terakhir, dan sebagian besar migrasi database tidak menggunakannya, sebaiknya Anda selalu memiliki strategi penggantian.

Penggantian sederhana

Dalam strategi penggantian ini, Anda mengalihkan aplikasi kembali ke instance database sumber asli. Gunakan strategi ini jika Anda dapat mentoleransi periode nonaktif saat Anda melakukan penggantian atau jika Anda tidak memerlukan transaksi yang dilakukan pada sistem target baru.

Jika Anda memerlukan semua data yang ditulis di database target, dan Anda dapat membiarkan beberapa periode nonaktif, Anda dapat mempertimbangkan untuk menghentikan penulisan ke instance database target, membuat cadangan bawaan dan memulihkannya di instance sumber, lalu menghubungkan kembali aplikasi ke instance database sumber awal. Bergantung pada sifat workload dan jumlah data yang ditulis pada instance database target, Anda dapat memasukkannya ke sistem database sumber awal di lain waktu, terutama jika workload Anda tidak bergantung pada waktu pembuatan catatan tertentu atau batasan pengurutan waktu.

Replikasi terbalik

Dalam strategi ini, Anda mereplikasi penulisan yang terjadi di database target baru setelah pengalihan produksi kembali ke database sumber awal. Dengan cara ini, Anda menjaga sumber asli tetap sinkron dengan database target baru dan menulis ke instance database target baru. Kekurangan utamanya adalah Anda tidak dapat menguji aliran replikasi hingga setelah Anda beralih ke instance database target, sehingga tidak memungkinkan pengujian end-to-end dan memiliki periode kecil tanpa penggantian.

Pilih pendekatan ini jika Anda masih dapat mempertahankan instance sumber untuk beberapa waktu dan Anda melakukan migrasi menggunakan migrasi replikasi berkelanjutan.

Replikasi maju

Strategi ini adalah variasi replikasi terbalik. Anda mereplikasi penulisan di database target baru ke instance database ketiga pilihan Anda. Anda dapat mengarahkan aplikasi ke database ketiga ini, yang terhubung ke server dan menjalankan kueri hanya baca saat server tidak tersedia. Anda dapat menggunakan mekanisme replikasi apa pun, bergantung pada kebutuhan Anda. Keuntungan dari pendekatan ini adalah dapat diuji secara menyeluruh.

Gunakan pendekatan ini jika Anda ingin selalu tercakup oleh penggantian atau jika Anda harus menghapus database sumber awal segera setelah peralihan produksi.

Operasi tulis duplikat

Jika Anda memilih strategi migrasi Y (menulis dan membaca) atau 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 dan target awal, yang memungkinkan Anda melakukan peralihan produksi bertahap hingga Anda hanya menggunakan instance database target. Jika ada masalah, Anda dapat menghubungkan kembali aplikasi ke sumber awal tanpa periode nonaktif. Anda dapat menghapus sumber awal dan mekanisme penulisan duplikat jika Anda menganggap migrasi telah dilakukan tanpa masalah.

Kami merekomendasikan pendekatan ini jika Anda tidak ingin ada waktu henti migrasi, memiliki penggantian yang andal, serta memiliki waktu dan resource untuk melakukan refaktorisasi aplikasi.

Melakukan pengujian dan validasi

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

• Migrasi data yang berhasil di database.
• Integrasi dengan aplikasi yang ada setelah aplikasi tersebut dialihkan untuk menggunakan instance target baru.

Tentukan faktor keberhasilan utama, yang bersifat subjektif untuk migrasi Anda. Berikut adalah contoh faktor subjektif:

• Data yang akan dimigrasikan. Untuk beberapa workload, Anda mungkin tidak perlu memigrasikan semua data. Anda mungkin tidak ingin memigrasikan data yang sudah diagregasi, berlebihan, diarsipkan, atau lama. Anda dapat mengarsipkan data tersebut di bucket Cloud Storage, sebagai cadangan.
• Persentase kehilangan data yang dapat diterima. Hal ini terutama berlaku untuk data yang digunakan untuk beban kerja analisis, yang kehilangan sebagian datanya tidak memengaruhi tren umum atau performa beban kerja Anda.
• Kriteria kualitas dan kuantitas data, yang dapat Anda terapkan ke lingkungan sumber dan dibandingkan dengan lingkungan target setelah migrasi.
• Kriteria performa. Beberapa transaksi bisnis mungkin lebih lambat di lingkungan target, tetapi waktu pemrosesan masih sesuai dengan ekspektasi yang ditentukan.

Konfigurasi penyimpanan di lingkungan sumber mungkin tidak dipetakan langsung ke target lingkunganGoogle Cloud . Misalnya, konfigurasi dari volume SSD Tujuan Umum (gp2 dan gp3) dengan performa burst IOPS atau SSD IOPS yang Disediakan. Untuk membandingkan dan menentukan ukuran instance target dengan benar, lakukan tolok ukur pada instance sumber Anda, baik dalam fase penilaian maupun validasi.

Dalam proses benchmarking, Anda menerapkan urutan operasi seperti produksi ke instance database. Selama waktu ini, Anda mengambil dan memproses metrik untuk mengukur dan membandingkan performa relatif sistem sumber dan target.

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

Alat berikut dapat digunakan untuk pengujian, validasi, dan tolok ukur database:

• HammerDB: alat pengujian beban dan tolok ukur database open source. Benchmark ini mendukung workload transaksional dan analitik yang kompleks, berdasarkan standar industri, di beberapa mesin database (TPROC-C dan TPROC-H). HammerDB memiliki dokumentasi mendetail dan komunitas pengguna yang luas. Anda dapat membagikan dan membandingkan hasil di beberapa mesin database dan konfigurasi penyimpanan. Untuk mengetahui informasi selengkapnya, lihat Menguji beban SQL Server menggunakan HammerDB dan Mengukur performa Amazon RDS SQL Server menggunakan HammerDB.
• Alat Benchmark DBT2: benchmark khusus untuk MySQL. Serangkaian kit workload database 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) siap pakai.
• DbUnit: alat pengujian unit open source yang digunakan untuk menguji interaksi database relasional di Java. Penyiapan dan penggunaannya mudah, serta mendukung beberapa mesin database (MySQL, PostgreSQL, SQL Server, dan lainnya). Namun, eksekusi pengujian terkadang lambat, bergantung pada ukuran dan kompleksitas database. Sebaiknya gunakan alat ini jika kesederhanaan penting.
• DbFit: framework pengujian database open source yang mendukung pengembangan kode berbasis pengujian dan pengujian otomatis. Framework ini menggunakan sintaksis dasar untuk membuat kasus pengujian dan menampilkan pengujian berbasis data, kontrol versi, dan pelaporan hasil pengujian. Namun, dukungan untuk kueri dan transaksi yang kompleks terbatas dan tidak memiliki dukungan komunitas yang besar atau dokumentasi yang ekstensif, dibandingkan dengan alat lainnya. Kami merekomendasikan alat ini jika kueri Anda tidak rumit dan Anda ingin melakukan pengujian otomatis serta mengintegrasikannya dengan proses continuous integration dan delivery.

Untuk menjalankan pengujian menyeluruh, termasuk pengujian rencana migrasi, selalu lakukan latihan uji coba migrasi. Uji coba melakukan migrasi database dengan cakupan penuh tanpa mengalihkan workload produksi apa pun, dan menawarkan keuntungan berikut:

• Memungkinkan Anda memastikan bahwa semua objek dan konfigurasi dimigrasikan dengan benar.
• Membantu Anda menentukan dan menjalankan kasus pengujian migrasi.
• Memberikan insight tentang waktu yang diperlukan untuk migrasi sebenarnya, sehingga Anda dapat menyesuaikan jadwal.
• Mewakili kesempatan untuk menguji, memvalidasi, dan menyesuaikan rencana migrasi. Terkadang Anda tidak dapat merencanakan semuanya di awal, jadi hal ini membantu Anda melihat adanya kesenjangan.

Pengujian data dapat dilakukan pada sebagian kecil set database yang akan dimigrasikan atau seluruh set. Bergantung pada jumlah total database dan alat yang digunakan untuk menerapkan migrasinya, Anda dapat memutuskan untuk menerapkan pendekatan berbasis risiko. Dengan pendekatan ini, Anda melakukan validasi data pada sebagian database yang dimigrasikan melalui alat yang sama, terutama jika alat ini adalah layanan migrasi terkelola.

Untuk pengujian, Anda harus memiliki akses ke database sumber dan target serta melakukan tugas berikut:

• Bandingkan skema sumber dan target. Periksa apakah semua tabel dan file yang dapat dieksekusi ada. Periksa jumlah baris dan bandingkan data di tingkat database.
• Menjalankan skrip validasi data kustom.
• Uji apakah data yang dimigrasikan juga terlihat di aplikasi yang beralih menggunakan database target (data yang dimigrasikan dibaca melalui aplikasi).
• Lakukan pengujian integrasi antara aplikasi yang dialihkan dan database target dengan menguji berbagai kasus penggunaan. Pengujian ini mencakup pembacaan dan penulisan data ke database target melalui aplikasi sehingga beban kerja sepenuhnya mendukung data yang dimigrasikan bersama dengan data yang baru dibuat.
• Uji performa kueri database yang paling sering digunakan untuk mengamati apakah ada penurunan performa karena kesalahan konfigurasi atau ukuran yang salah.

Idealnya, semua skenario pengujian migrasi ini bersifat otomatis dan dapat diulang di sistem sumber mana pun. Rangkaian kasus pengujian otomatis disesuaikan untuk dilakukan terhadap aplikasi yang diubah.

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

Alat Validasi Data

Untuk melakukan validasi data, sebaiknya gunakan Alat Validasi Data (DVT). DVT adalah alat CLI Python open source, yang didukung oleh Google, yang menyediakan solusi otomatis dan berulang untuk validasi di berbagai lingkungan.

DVT dapat membantu menyederhanakan proses validasi data dengan menawarkan fungsi validasi multilevel yang disesuaikan untuk membandingkan tabel sumber dan target di tingkat tabel, kolom, dan baris. Anda juga dapat menambahkan aturan validasi.

DVT mencakup banyak sumber data, termasuk AlloyDB for PostgreSQL, BigQuery, Cloud SQL, Spanner, JSON, dan file CSV di Cloud Storage. Google Cloud Cloud Tasks 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 mengetahui informasi selengkapnya tentang DVT, lihat repositori Git dan Validasi data jadi mudah dengan Alat Validasi Data Google Cloud.

Melakukan migrasi

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

Pertimbangkan praktik terbaik berikut untuk migrasi data Anda:

• Beri tahu tim yang terlibat setiap kali langkah rencana dimulai dan selesai.
• Jika salah satu langkah memerlukan waktu lebih lama dari yang diperkirakan, bandingkan waktu yang telah berlalu dengan jumlah waktu maksimum yang dialokasikan untuk langkah tersebut. Berikan info terbaru perantara secara rutin kepada tim yang terlibat saat hal ini terjadi.
• Jika rentang waktu lebih besar daripada jumlah waktu maksimum yang dicadangkan untuk setiap langkah dalam rencana, pertimbangkan untuk membatalkan perubahan.
• Buat keputusan "lanjut atau tidak" untuk setiap langkah migrasi dan rencana peralihan.
• Pertimbangkan tindakan rollback atau skenario alternatif untuk setiap langkah.

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

Melakukan peralihan produksi

Proses peralihan produksi tingkat tinggi dapat berbeda-beda bergantung pada strategi migrasi yang Anda pilih. Jika Anda dapat mengalami periode nonaktif pada workload, maka peralihan migrasi Anda dimulai dengan menghentikan penulisan ke database sumber.

Untuk migrasi replikasi berkelanjutan, Anda biasanya melakukan langkah-langkah tingkat tinggi berikut dalam proses pengalihan:

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

Setelah data dimigrasikan menggunakan alat migrasi yang dipilih, Anda memvalidasi data di database target. Anda mengonfirmasi bahwa database sumber dan database target disinkronkan dan data dalam instance target mematuhi standar keberhasilan migrasi yang Anda pilih.

Setelah validasi data memenuhi kriteria Anda, Anda dapat melakukan peralihan tingkat aplikasi. Deploy workload yang telah difaktorkan ulang untuk menggunakan instance target baru. Anda men-deploy versi aplikasi yang mengarah ke instance database target baru. Deployment dapat dilakukan melalui update berkelanjutan, rilis bertahap, atau menggunakan pola blue-green deployment. Beberapa waktu nonaktif aplikasi mungkin terjadi.

Ikuti praktik terbaik untuk peralihan produksi Anda:

• Pantau aplikasi Anda yang menggunakan database target setelah pengalihan.
• Tentukan periode waktu pemantauan untuk mempertimbangkan apakah Anda perlu menerapkan rencana penggantian atau tidak.
• Perhatikan bahwa instance Cloud SQL atau AlloyDB for PostgreSQL Anda mungkin perlu dimulai ulang jika Anda mengubah beberapa flag database.
• Pertimbangkan bahwa upaya 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 peralihan selesai, Anda dapat menghapus database sumber. Sebaiknya lakukan tindakan penting berikut sebelum membersihkan instance sumber Anda:

• Buat cadangan akhir setiap database sumber. Pencadangan ini memberi Anda status akhir database sumber. Cadangan juga mungkin diperlukan dalam beberapa kasus untuk mematuhi beberapa peraturan data.

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

• Kumpulkan statistik database dari instance sumber dan bandingkan dengan statistik di instance target. Jika statistiknya berbeda, akan sulit untuk membandingkan performa instance sumber dan instance target.

Dalam skenario penggantian, Anda mungkin ingin menerapkan replikasi penulisan di instance Cloud SQL kembali ke database sumber asli Anda. Penyiapan ini menyerupai proses migrasi, tetapi akan berjalan secara terbalik: database sumber awal akan menjadi target baru.

Sebagai praktik terbaik untuk menjaga agar instance sumber tetap terupdate setelah pengalihan, replikasi penulisan yang dilakukan pada instance Cloud SQL target kembali ke database sumber. Jika perlu melakukan rollback, Anda dapat beralih ke instance sumber lama dengan kehilangan data minimal.

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

• Konfigurasikan masa pemeliharaan pada instance utama untuk mengontrol waktu saat update yang mengganggu dapat terjadi.
• Konfigurasi penyimpanan di instance sehingga Anda memiliki minimal 20% kapasitas yang tersedia untuk mengakomodasi operasi pemeliharaan database penting apa pun yang mungkin dijalankan Cloud SQL. Untuk menerima pemberitahuan jika ruang disk yang tersedia kurang dari 20%, buat kebijakan pemberitahuan berbasis metrik untuk metrik pemakaian disk.

Jangan memulai operasi administratif sebelum operasi sebelumnya selesai.

Untuk mengetahui 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 sampai lingkungan target Anda memenuhi persyaratan pengoptimalan. Langkah-langkah 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 mengetahui informasi selengkapnya tentang cara mengoptimalkan lingkungan Google Cloud , lihat Bermigrasi ke Google Cloud: Mengoptimalkan lingkungan Anda dan Google Cloud Framework yang Dirancang dengan Baik: Pengoptimalan performa.

Menetapkan persyaratan pengoptimalan

Tinjau persyaratan pengoptimalan berikut untuk lingkungan Google Cloud Anda dan pilih yang paling sesuai dengan beban kerja Anda:

Meningkatkan keandalan dan ketersediaan database Anda

Dengan Cloud SQL, Anda dapat menerapkan strategi ketersediaan tinggi dan pemulihan dari bencana yang selaras dengan tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) Anda. Untuk meningkatkan keandalan dan ketersediaan, pertimbangkan hal berikut:

• Dalam kasus workload read-heavy, tambahkan replika baca untuk memindahkan traffic dari instance utama.
• Untuk workload yang sangat penting, gunakan konfigurasi ketersediaan tinggi, replika untuk failover regional, dan konfigurasi pemulihan dari bencana yang andal.
• Untuk beban kerja yang kurang penting, pencadangan otomatis dan sesuai permintaan dapat mencukupi.
• Untuk mencegah penghapusan instance yang tidak disengaja, gunakan perlindungan penghapusan instance.
• Pertimbangkan untuk menggunakan edisi Cloud SQL Enterprise Plus untuk mendapatkan manfaat dari peningkatan ketersediaan, retensi log, dan pemeliharaan terencana dengan periode nonaktif nyaris nol. Untuk mengetahui informasi selengkapnya tentang Cloud SQL Enterprise Plus, lihat Pengantar edisi Cloud SQL dan Pemeliharaan terencana dengan periode nonaktif nyaris nol.

Untuk mengetahui informasi selengkapnya tentang cara meningkatkan keandalan dan ketersediaan database Anda, lihat artikel berikut:

• Mempromosikan replika untuk migrasi regional atau pemulihan dari bencana
• Pemulihan dari bencana database Cloud SQL
• Tentang pencadangan Cloud SQL
• Dokumentasi Mencegah penghapusan instance

Meningkatkan efektivitas biaya infrastruktur database Anda

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

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

  • Untuk menskalakan kapasitas penyimpanan secara otomatis seiring pertumbuhan data Anda, aktifkan peningkatan penyimpanan otomatis. Namun, pastikan Anda mengonfigurasi instance agar memiliki beberapa buffer dalam beban kerja puncak. Ingatlah bahwa workload database cenderung meningkat seiring waktu.

• Identifikasi kemungkinan resource yang diperkirakan terlalu tinggi:

  • Menyesuaikan ukuran instance Cloud SQL dapat mengurangi biaya infrastruktur tanpa menambah risiko pada strategi pengelolaan kapasitas.
  • Cloud Monitoring menyediakan dasbor yang telah ditetapkan yang membantu mengidentifikasi kondisi dan pemanfaatan kapasitas banyak Google Cloud komponen, termasuk Cloud SQL. Untuk mengetahui detailnya, lihat Membuat dan mengelola dasbor kustom.

• Identifikasi instance yang tidak memerlukan konfigurasi ketersediaan tinggi atau pemulihan dari bencana, lalu hapus instance tersebut dari infrastruktur Anda.

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

• Evaluasi jenis penyimpanan (SSD atau HDD) yang paling hemat biaya untuk kasus penggunaan Anda.

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

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

• Gunakan Active Assist untuk mendapatkan insight dan rekomendasi biaya.

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

Meningkatkan performa infrastruktur database Anda

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

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

• Pastikan bahwa instance Anda tidak dibatasi pada memori atau CPU.

  • Untuk workload yang membutuhkan performa tinggi, pastikan instance Anda memiliki setidaknya 60 GB memori.
  • Untuk penyisipan, update, atau penghapusan database yang lambat, periksa lokasi penulis dan database; mengirim data jarak jauh akan menimbulkan latensi.

• Tingkatkan performa kueri menggunakan dasbor Query Insights yang telah ditentukan sebelumnya di Cloud Monitoring (atau fitur bawaan mesin database serupa). Identifikasi perintah yang paling mahal dan coba optimalkan.

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

• Periksa lokasi pembaca dan database. Latensi memengaruhi performa baca lebih daripada performa tulis.

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

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

Meningkatkan kemampuan observasi database

Mendiagnosis dan memecahkan masalah dalam aplikasi yang terhubung ke instance database dapat menjadi sulit dan memakan waktu. Oleh karena itu, tempat terpusat tempat semua anggota tim dapat melihat apa yang terjadi di tingkat database dan instance sangat penting. Anda dapat memantau instance Cloud SQL dengan cara berikut:

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

  • Gunakan Cloud Monitoring untuk mengumpulkan hasil pengukuran terkait layanan Anda dan Google Cloud resource yang Anda gunakan. Cloud Monitoring mencakup dasbor yang telah ditentukan untuk beberapa produk Google Cloud , termasuk dasbor pemantauan Cloud SQL.
  • Anda dapat membuat dasbor kustom yang membantu Anda memantau metrik dan menyiapkan kebijakan pemberitahuan sehingga 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 rencana kueri yang dijalankan dari aplikasi untuk membantu Anda melacak cara permintaan diterapkan di seluruh aplikasi Anda.

• Database Center memberikan ringkasan fleet database terpusat yang dibantu AI. Anda dapat memantau kondisi database, konfigurasi ketersediaan, perlindungan data, keamanan, dan kepatuhan terhadap standar industri.

Praktik terbaik dan panduan operasional Cloud SQL umum

Terapkan praktik terbaik untuk Cloud SQL guna mengonfigurasi dan menyetel database.

Beberapa rekomendasi umum Cloud SQL yang penting adalah sebagai berikut:

• Jika Anda memiliki instance besar, sebaiknya bagi instance tersebut menjadi instance yang lebih kecil jika memungkinkan.
• Konfigurasikan penyimpanan untuk mengakomodasi pemeliharaan database yang penting. Pastikan Anda memiliki minimal 20% ruang yang tersedia untuk mengakomodasi operasi pemeliharaan database penting apa pun yang mungkin dilakukan Cloud SQL.
• Memiliki terlalu banyak tabel database dapat memengaruhi waktu upgrade database. Idealnya, usahakan agar jumlah tabel per instance kurang dari 10.000.
• Pilih ukuran yang sesuai untuk instance Anda guna memperhitungkan retensi log transaksi (biner), terutama untuk instance dengan aktivitas penulisan tinggi.

Untuk dapat menangani masalah performa database secara efisien yang mungkin Anda alami, gunakan panduan berikut hingga masalah Anda teratasi:

Menskalakan infrastruktur: Tingkatkan resource (seperti throughput disk, vCPU, dan RAM). Bergantung pada urgensi serta ketersediaan dan pengalaman tim Anda, menskalakan instance secara vertikal dapat menyelesaikan sebagian besar masalah performa. Selanjutnya, Anda dapat menyelidiki lebih lanjut penyebab utama masalah di lingkungan pengujian dan mempertimbangkan opsi untuk menghilangkannya.

Melakukan dan menjadwalkan operasi pemeliharaan database: Defragmentasi indeks, update statistik, analisis vacuum, dan pengindeksan ulang tabel yang sering diupdate. Periksa apakah dan kapan operasi pemeliharaan ini terakhir kali dilakukan, terutama pada objek yang terpengaruh (tabel, indeks). Cari tahu apakah ada perubahan dari aktivitas database normal. Misalnya, baru-baru ini menambahkan kolom baru atau memiliki banyak pembaruan pada tabel.

Lakukan penyesuaian dan pengoptimalan database: Apakah tabel di database Anda disusun dengan benar? Apakah kolom memiliki jenis data yang benar? Apakah model data Anda sudah tepat untuk jenis workload? Selidiki kueri lambat dan paket eksekusinya. Apakah kueri tersebut menggunakan indeks yang tersedia? Periksa pemindaian indeks, kunci, dan penantian pada resource lain. Pertimbangkan untuk menambahkan indeks guna mendukung kueri penting Anda. Hapus indeks dan kunci asing yang tidak penting. Pertimbangkan untuk menulis ulang kueri dan gabungan yang kompleks. Waktu yang diperlukan untuk menyelesaikan masalah Anda bergantung pada pengalaman dan ketersediaan tim Anda, dan dapat berkisar dari beberapa jam hingga beberapa hari.

Menskalakan operasi baca: Pertimbangkan untuk memiliki replika baca. Jika penskalaan vertikal tidak cukup untuk memenuhi kebutuhan Anda, dan langkah-langkah penyesuaian serta pengoptimalan database tidak membantu, pertimbangkan untuk melakukan penskalaan horizontal. Merutekan kueri baca dari aplikasi Anda ke replika baca akan meningkatkan performa keseluruhan beban kerja database Anda. Namun, mungkin diperlukan upaya tambahan untuk mengubah aplikasi Anda agar terhubung ke replika baca.

Arsitektur ulang database: Pertimbangkan untuk mempartisi dan mengindeks database. Operasi ini memerlukan upaya yang jauh lebih besar daripada penyesuaian dan pengoptimalan database, dan mungkin melibatkan migrasi data, tetapi dapat menjadi perbaikan jangka panjang. Terkadang, desain model data yang buruk dapat menyebabkan masalah performa, yang dapat dikompensasi sebagian dengan penskalaan vertikal. Namun, model data yang tepat adalah perbaikan jangka panjang. Pertimbangkan untuk mempartisi tabel Anda. Arsipkan data yang tidak diperlukan lagi, jika memungkinkan. Menormalisasi struktur database, tetapi ingatlah bahwa denormalisasi juga dapat meningkatkan performa.

Sharding database: Anda dapat menskalakan operasi tulis dengan melakukan sharding pada database. Sharding adalah operasi yang rumit dan melibatkan pendesainan ulang database dan aplikasi dengan cara tertentu serta melakukan migrasi data. Anda membagi instance database menjadi beberapa instance yang lebih kecil menggunakan kriteria partisi tertentu. Kriteria dapat didasarkan pada pelanggan atau subjek. Opsi ini memungkinkan Anda menskalakan penulisan dan pembacaan secara horizontal. Namun, hal ini meningkatkan kompleksitas beban kerja database dan aplikasi Anda. Hal ini juga dapat menyebabkan shard yang tidak seimbang yang disebut hotspot, yang akan lebih besar daripada manfaat sharding. - Khusus untuk Cloud SQL untuk MySQL, pastikan tabel Anda memiliki kunci utama atau kunci unik. Cloud SQL menggunakan replikasi berbasis baris, yang berfungsi paling baik pada tabel dengan kunci utama atau kunci unik.

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

Langkah berikutnya

• Baca tentang 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 | Solutions Architect
• Marco Ferrari | Cloud Solutions Architect

Kontributor lainnya:

• Derek Downey | Developer Relations Engineer
• Paweł Krentowski | Technical Writer
• Matthew Smith | Strategic Cloud Engineer
• Somdyuti Paul | Data Management Specialist
• Zach Seils | Networking Specialist