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

Last reviewed 2024-09-12 UTC

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

Dokumen ini ditujukan untuk administrator cloud dan database yang ingin merencanakan, menerapkan, dan memvalidasi project migrasi database. Fitur ini juga ditujukan untuk para pengambil keputusan yang sedang mengevaluasi peluang untuk melakukan migrasi dan yang ingin mengetahui seperti apa migrasi tersebut.

Dokumen ini berfokus pada migrasi database homogen, yaitu migrasi dengan database sumber dan target menggunakan teknologi database yang sama. Dalam panduan migrasi ini, sumbernya adalah Amazon RDS atau Amazon Aurora untuk PostgreSQL, dan tujuannya adalah Cloud SQL untuk PostgreSQL atau AlloyDB untuk PostgreSQL.

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

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

Diagram berikut menggambarkan jalur perjalanan migrasi Anda.

Jalur migrasi dengan empat fase.

Anda dapat bermigrasi dari lingkungan sumber ke Google Cloud dalam serangkaian iterasi—misalnya, Anda dapat memigrasikan beberapa workload terlebih dahulu dan yang 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. 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 mendesain 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 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 rencana dan linimasa 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 kesulitan atau gagal karena ukuran instance database target yang salah. 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 Migrasi 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 dan Amazon Aurora. Idealnya, proses ini harus otomatis karena pendekatan manual rentan terhadap error dan dapat menyebabkan asumsi yang salah.

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

Benchmarking dapat membantu Anda lebih memahami beban kerja 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 benchmark dijelaskan dalam Melakukan 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, 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 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 migVisor, lihat ringkasan migVisor.

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

Output penilaian database migVisor memberikan hal berikut:

  • Penemuan dan analisis komprehensif 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 operasi 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 akan meningkatkan penggunaan 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 pengumpulan 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. 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. Alat 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, dan ikuti petunjuknya. Kirim file output ke Google Cloud untuk analisis. Google Cloud membuat dan mengirimkan laporan penilaian database, dan memberikan langkah-langkah berikutnya dalam perjalanan migrasi.

Mengidentifikasi dan mendokumentasikan cakupan migrasi dan periode nonaktif yang dapat diterima

Pada tahap ini, Anda mendokumentasikan informasi penting yang memengaruhi strategi dan alat migrasi. 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 database berada (region dan zona), dan bagaimana jaraknya 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 harus berada di beberapa lokasi fisik?
  • Apakah ada data yang dapat dikompresi dan diarsipkan, atau ada data yang tidak memerlukan migrasi sama sekali?

Untuk menentukan cakupan migrasi, tentukan data yang akan disimpan dan 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 pengukuran migrasi data yang membantu Anda membandingkan dan mengevaluasi hasil dan dampak. Dasar pengukuran ini adalah titik referensi yang mewakili status data Anda sebelum dan sesudah migrasi serta membantu Anda membuat keputusan. Penting untuk melakukan pengukuran pada 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 periode nonaktif yang dapat Anda toleransi. Apa dampak bisnis dari downtime? Apakah ada periode aktivitas database yang rendah, yang selama periode tersebut ada lebih sedikit pengguna yang terpengaruh oleh periode nonaktif? Jika ya, berapa lama periode tersebut dan kapan periode tersebut terjadi? Pertimbangkan untuk memiliki periode nonaktif hanya tulis sebagian, sementara permintaan hanya baca masih ditayangkan.

Menilai proses deployment dan administrasi Anda

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

Pertimbangkan cara Anda menyelesaikan tugas-tugas berikut:

  • Menentukan dan menerapkan kebijakan keamanan untuk instance Anda. Misalnya, Anda mungkin perlu mengganti Amazon Security Groups. Anda dapat menggunakan peran Google IAM, aturan firewall VPC, dan Kontrol Layanan VPC untuk mengontrol akses ke instance Cloud SQL untuk PostgreSQL dan membatasi data dalam VPC.

  • Menerapkan patch dan mengonfigurasi 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 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 visibilitas selama proses migrasi. Kategori metrik dapat mencakup Amazon CloudWatch, Performance Insights, Enhanced Monitoring, 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 artikel 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.
  • Hubungkan lingkungan sumber dan lingkungan Google Cloud Anda untuk 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 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 Cloud SQL untuk PostgreSQL untuk memahami konfigurasi jaringan yang tersedia untuk skenario migrasi.

Pemantauan dan pemberitahuan

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

Memigrasikan instance Amazon RDS dan Amazon Aurora for PostgreSQL ke Cloud SQL for PostgreSQL dan AlloyDB for PostgreSQL

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 linimasa 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 staging terpisah.

  8. Lakukan migrasi.

  9. Lakukan cut-over 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 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): Pendekatan ini sangat ideal jika Anda dapat menyediakan periode nonaktif. Opsi ini relatif lebih rendah biaya dan kompleksitasnya, karena beban kerja dan layanan Anda tidak akan memerlukan banyak pemfaktoran ulang. Namun, jika migrasi gagal sebelum selesai, Anda harus memulai ulang proses, yang akan memperpanjang periode nonaktif.

  • Replikasi berkelanjutan (juga disebut migrasi trickle): Untuk database yang sangat 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 memerlukan waktu lebih sedikit. Namun, penyiapannya lebih kompleks 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 informasi selengkapnya tentang strategi migrasi data, lihat Mengevaluasi pendekatan migrasi data.

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

Diagram alir untuk membantu Anda memilih strategi migrasi.

Diagram alur sebelumnya menunjukkan titik keputusan berikut:

  • Dapatkah Anda menanggung 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? Periode peralihan menunjukkan jumlah waktu yang diperlukan untuk membuat cadangan 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 berada di instance yang sama. Kombinasi strategi dapat menghasilkan hasil yang optimal. Misalnya, migrasikan database kecil dan jarang digunakan menggunakan pendekatan pemeliharaan terjadwal, tetapi gunakan replikasi berkelanjutan untuk database penting yang memiliki periode nonaktif yang mahal.

Biasanya, migrasi dianggap selesai saat pengalihan antara instance sumber awal dan instance target terjadi. Semua replikasi (jika digunakan) akan dihentikan dan semua operasi baca dan tulis dilakukan di instance target. Beralih saat kedua instance disinkronkan berarti tidak ada kehilangan data dan waktu henti layanan minimal.

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

Konfigurasi migrasi yang tidak memberikan periode nonaktif aplikasi memerlukan penyiapan yang lebih rumit. Temukan keseimbangan yang tepat antara kompleksitas penyiapan dan periode nonaktif yang dijadwalkan selama jam operasional dengan traffic rendah.

Setiap strategi migrasi memiliki kompromi dan 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 downtime aplikasi, setidaknya selama jeda replikasi berlangsung sebelum menggunakan database baru. Dalam praktiknya, 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 buffering yang substansial.
  • 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 entri DNS disiapkan, 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 dampaknya:

  • Temukan jangka waktu saat periode nonaktif akan memiliki dampak minimal pada beban kerja Anda. Misalnya, di luar jam kerja normal, selama akhir pekan, atau periode pemeliharaan terjadwal lainnya.
  • Identifikasi bagian workload Anda yang dapat menjalani migrasi dan peralihan produksi pada berbagai tahap. Aplikasi Anda mungkin memiliki komponen yang berbeda yang dapat diisolasi, diadaptasi, dan dimigrasikan tanpa dampak. Misalnya, frontend, modul CRM, layanan backend, dan platform pelaporan. Modul tersebut dapat memiliki database sendiri yang dapat dijadwalkan untuk dimigrasikan lebih awal atau lebih lambat dalam prosesnya.
  • Jika Anda dapat menerima beberapa latensi di database target, pertimbangkan untuk menerapkan migrasi bertahap. Gunakan transfer data bertahap dan berkelompok, dan sesuaikan sebagian beban kerja Anda agar berfungsi dengan data yang sudah tidak berlaku di instance target.
  • Pertimbangkan untuk memfaktorkan ulang aplikasi Anda guna mendukung dampak migrasi minimum. 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 tentukan 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. 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 peralihan 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. Alat ini menjalankan ekstraksi data dari database sumber, memindahkan data ke database target dengan aman, dan secara opsional dapat mengubah data selama pengiriman. Dengan kemampuan ini, keduanya mengenkapsulasi logika migrasi yang kompleks dan menawarkan kemampuan pemantauan migrasi.

Layanan migrasi terkelola memberikan keuntungan berikut:

  • Minimalkan periode nonaktif: Layanan menggunakan kemampuan replika 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 migrasi database, yang dapat Anda kelola dan monitor.

  • Menawarkan model migrasi yang andal dan terbukti: Migrasi database merupakan peristiwa yang jarang terjadi, tetapi penting. Untuk menghindari kesalahan pemula dan masalah pada solusi yang ada, Anda dapat menggunakan alat dari ahli yang berpengalaman, bukan membuat solusi kustom.

  • Mengoptimalkan biaya: Layanan migrasi terkelola dapat 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

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

Untuk migrasi satu kali ke Cloud SQL untuk PostgreSQL atau ke AlloyDB untuk PostgreSQL, sebaiknya gunakan pencadangan mesin database untuk mengekspor data dari instance sumber dan mengimpor data tersebut ke dalam instance target. Tugas migrasi satu kali tidak didukung di Database Migration Service.

Pencadangan mesin database bawaan

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

Beberapa upaya diperlukan untuk penyiapan dan sinkronisasi, terutama untuk database dalam jumlah besar, tetapi pencadangan mesin database biasanya sudah tersedia dan mudah digunakan. Pendekatan ini cocok untuk semua ukuran database, dan biasanya lebih efektif daripada alat lain untuk instance besar.

Pencadangan mesin database memiliki batasan umum berikut:

  • Pencadangan dapat rentan terhadap error, terutama jika dilakukan secara manual.
  • Data dapat tidak aman jika snapshot tidak dikelola dengan benar.
  • Cadangan tidak memiliki kemampuan pemantauan yang tepat.
  • Pencadangan memerlukan upaya untuk diskalakan saat memigrasikan banyak database.

Anda dapat menggunakan utilitas pencadangan bawaan PostgreSQL, pg_dump dan pg_dumpall, untuk memigrasikan Cloud SQL untuk PostgreSQL dan AlloyDB untuk PostgreSQL. Namun, utilitas pg_dump dan pg_dumapall memiliki batasan umum berikut:

  • Utilitas pencadangan bawaan harus digunakan untuk memigrasikan database yang berukuran 500 GB atau kurang. Men-dump dan memulihkan database besar dapat memakan waktu lama dan mungkin memerlukan ruang disk dan memori yang cukup besar.
  • Utilitas pg_dump tidak menyertakan pengguna dan peran. Untuk memigrasikan akun dan peran pengguna ini, Anda dapat menggunakan utilitas pg_dumpall.
  • Cloud Storage mendukung ukuran maksimum objek tunggal hingga 5 terabyte (TB). Jika Anda memiliki database yang lebih besar dari 5 TB, operasi ekspor ke Cloud Storage akan gagal. Dalam hal ini, Anda perlu memecah file ekspor menjadi segmen yang lebih kecil.

Jika Anda memilih untuk menggunakan utilitas ini, pertimbangkan batasan dan praktik terbaik berikut:

  • Kompresi data untuk mengurangi biaya dan durasi transfer. Gunakan opsi --jobs dengan perintah pg_dump untuk menjalankan sejumlah tugas dump secara bersamaan.
  • Gunakan opsi -z dengan perintah pg_dump untuk menentukan tingkat kompresi yang akan digunakan. Nilai yang dapat diterima untuk opsi ini berkisar dari 0 hingga 9. Nilai defaultnya adalah mengompresi pada level 6. Nilai yang lebih tinggi akan mengurangi ukuran file dump, tetapi dapat menyebabkan konsumsi resource yang tinggi di host klien. Jika host klien memiliki resource yang cukup, tingkat kompresi yang lebih tinggi dapat lebih menurunkan ukuran file dump.
  • Gunakan flag yang benar saat Anda membuat file dump SQL.
  • Verifikasi database yang diimpor. Pantau output utilitas pg_restore untuk melihat pesan error selama proses pemulihan. Tinjau log PostgreSQL untuk mengetahui peringatan atau error selama proses pemulihan. Jalankan kueri dasar dan jumlah tabel untuk memverifikasi integritas database Anda.

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

Pendekatan lain untuk migrasi pemeliharaan terjadwal

Menggunakan pendekatan selain utilitas pencadangan bawaan dapat memberikan lebih banyak kontrol dan fleksibilitas dalam migrasi pemeliharaan terjadwal Anda. Jenis pendekatan lain ini memungkinkan Anda melakukan transformasi, pemeriksaan, atau operasi lainnya pada data saat melakukan migrasi. Anda dapat menggabungkan beberapa instance atau database menjadi satu instance atau database. Menggabungkan instance dapat membantu memitigasi biaya operasional dan meringankan masalah skalabilitas Anda.

Salah satu alternatif untuk utilitas pencadangan adalah menggunakan file datar untuk mengekspor dan mengimpor data Anda. Untuk informasi selengkapnya tentang impor file datar, lihat Mengekspor dan mengimpor menggunakan file CSV untuk Cloud SQL untuk PostgreSQL.

Alternatif lainnya adalah menggunakan impor terkelola untuk menyiapkan replikasi dari database PostgreSQL eksternal. Saat Anda menggunakan impor terkelola, ada pemuatan data awal dari database eksternal ke instance Cloud SQL untuk PostgreSQL. Pemuatan awal ini menggunakan layanan yang mengekstrak data dari server eksternal - instance RDS atau Aurora - dan mengimpornya secara langsung ke instance Cloud SQL untuk PostgreSQL. Untuk mengetahui informasi selengkapnya, lihat menggunakan impor terkelola untuk menyiapkan replikasi dari database eksternal.

Cara alternatif untuk melakukan migrasi data satu kali adalah dengan mengekspor tabel dari database PostgreSQL sumber ke file CSV atau SQL. Kemudian, Anda dapat mengimpor file CSV atau SQL ke Cloud SQL untuk PostgreSQL atau AlloyDB untuk PostgreSQL. Untuk mengekspor tanggal instance sumber, Anda dapat menggunakan ekstensi aws_s3 untuk PostgreSQL. Atau, Anda dapat menggunakan Amazon Database Migration Service dan bucket S3 sebagai target. Untuk informasi mendetail tentang pendekatan ini, lihat referensi berikut:

Anda juga dapat mengimpor data secara manual ke instance AlloyDB untuk PostgreSQL. Format yang didukung adalah sebagai berikut:

  • CSV: Dengan format file ini, setiap file dalam format ini berisi konten satu tabel dalam database. Anda dapat memuat data ke dalam file CSV menggunakan program command line psql. Untuk informasi selengkapnya, lihat Mengimpor file CSV.
  • DMP: Format file ini berisi arsip seluruh database PostgreSQL. Anda mengimpor data dari file ini menggunakan utilitas pg_restore. Untuk mengetahui informasi selengkapnya, lihat Mengimpor file DMP.
  • SQL: Format file ini berisi rekonstruksi teks database PostgreSQL. Data dalam file ini diproses menggunakan command line psql. Untuk informasi selengkapnya, lihat Mengimpor file SQL.

Alat untuk migrasi replikasi berkelanjutan

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

Diagram alir untuk membantu Anda memilih alat untuk migrasi replikasi berkelanjutan.

Diagram alur sebelumnya menunjukkan titik keputusan berikut:

  • Apakah Anda lebih memilih untuk menggunakan layanan migrasi terkelola?

    • Jika ya, dapatkah Anda menanggung downtime operasi tulis selama beberapa detik saat langkah replikasi berlangsung?

      • 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 menyediakan jenis tugas tertentu untuk migrasi berkelanjutan. Tugas migrasi berkelanjutan ini mendukung migrasi fidelitas tinggi ke Cloud SQL untuk PostgreSQL dan ke AlloyDB untuk PostgreSQL.

Saat Anda menggunakan Database Migration Service untuk bermigrasi ke Cloud SQL untuk PostgreSQL atau AlloyDB untuk PostgreSQL, ada prasyarat dan batasan yang dikaitkan dengan setiap instance target:

Replikasi bawaan mesin database

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

Replikasi database mewakili proses menyalin dan mendistribusikan data dari database yang disebut database utama ke database lain yang disebut replika. Hal ini dimaksudkan untuk meningkatkan aksesibilitas data dan meningkatkan toleransi error serta keandalan sistem database. Meskipun migrasi database bukan tujuan utama replikasi database, migrasi database dapat berhasil digunakan sebagai alat untuk mencapai sasaran ini. Replikasi database biasanya merupakan proses berkelanjutan yang terjadi secara real time saat data disisipkan, diperbarui, atau dihapus di database utama. Replikasi database dapat dilakukan sebagai operasi satu kali, atau urutan operasi batch.

Sebagian besar mesin database modern menerapkan berbagai cara untuk mencapai replika database. Satu jenis replikasi dapat dicapai dengan menyalin dan mengirim log tulis lebih awal atau log transaksi utama 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. Jenis replikasi ini disebut replikasi logis. Untuk PostgreSQL, ada juga ekstensi pihak ketiga, seperti pglogical, yang mengimplementasikan replikasi logis yang mengandalkan logging write-ahead (WAL).

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

Berikut adalah batasan dan prasyarat untuk Cloud SQL untuk PostgreSQL:

  • Versi Amazon berikut didukung:

    • Amazon RDS 9.6.10 dan yang lebih baru, 10.5 dan yang lebih baru, 11.1 dan yang lebih baru, 12, 13, 14
    • Amazon Aurora 10.11 dan yang lebih baru, 11.6 dan yang lebih baru, 12.4 dan yang lebih baru, dan 13.3 dan yang lebih baru

  • Firewall server eksternal harus dikonfigurasi untuk mengizinkan rentang IP internal yang telah dialokasikan untuk akses layanan pribadi jaringan VPC. Database replika Cloud SQL untuk PostgreSQL menggunakan jaringan VPC sebagai jaringan pribadinya.

  • Firewall database sumber harus dikonfigurasi untuk mengizinkan seluruh rentang IP internal yang telah dialokasikan untuk koneksi layanan pribadi jaringan VPC. Instance tujuan Cloud SQL untuk PostgreSQL menggunakan jaringan VPC ini di kolom privateNetwork dari setelan IpConfiguration-nya.

  • Saat menginstal ekstensi pglogical pada instance Cloud SQL untuk PostgreSQL, pastikan Anda telah menetapkan tanda enable_pglogical ke on (misalnya, cloudsql.enable_pglogical=on).

  • Pastikan parameter shared_preload_libraries menyertakan ekstensi pglogical pada instance sumber Anda (misalnya, shared_preload_libraries=pg_stat_statements,pglogical). Tetapkan parameter rds.logical_replication ke 1. Setelan ini mengaktifkan log write-ahead di tingkat logis.

    Perubahan ini memerlukan mulai ulang instance utama.

Untuk informasi selengkapnya tentang cara menggunakan Cloud SQL untuk PostgreSQL untuk replikasi, lihat checklist server eksternal di bagian replikasi untuk PostgreSQL dan juga Menyiapkan replikasi dan decoding logis untuk PostgreSQL dari dokumentasi resmi Cloud SQL.

AlloyDB untuk PostgreSQL mendukung replikasi melalui ekstensi pglogical. Untuk mengaktifkan ekstensi pglogical untuk replikasi, Anda dapat menggunakan perintah CREATE EXTENSION. Sebelum menggunakan perintah tersebut, Anda harus menetapkan flag database alloydb.enable_pglogical dan alloydb.logical_decoding ke on terlebih dahulu di instance AlloyDB untuk PostgreSQL tempat Anda ingin menggunakan ekstensi. Menyetel flag ini memerlukan mulai ulang instance.

Pendekatan lain untuk migrasi replikasi berkelanjutan

Anda dapat menggunakan Datastream untuk mereplikasi perubahan instance PostgreSQL sumber Anda mendekati real-time. Datastream menggunakan pengambilan data perubahan (CDC) dan replikasi untuk mereplikasi dan menyinkronkan data. Kemudian, Anda dapat menggunakan Datastream untuk replikasi berkelanjutan dari Amazon RDS dan Amazon Aurora. Anda menggunakan Datastream untuk mereplikasi perubahan dari instance PostgreSQL ke BigQuery atau Cloud Storage. Data replika tersebut kemudian dapat dimasukkan ke instance Cloud SQL untuk PostgreSQL dan AlloyDB untuk PostgreSQL dengan Dataflow menggunakan Template Flex Dataflow, atau dengan Dataproc.

Untuk informasi selengkapnya tentang penggunaan Datastream dan Dataflow, lihat referensi berikut:

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 untuk menggunakan layanan migrasi terkelola dan perlu memastikan bahwa database target selalu disinkronkan secara hampir real-time dengan sumber, atau jika Anda memerlukan transformasi yang lebih kompleks seperti pembersihan, penyusunan 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 in-memory menyeluruh untuk mengumpulkan, memfilter, mengubah, 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.
    • Mampu menangani database besar yang sangat penting dan beroperasi di bawah beban transaksi yang berat.
    • Pengiriman tepat satu kali.

  • Kekurangan:

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.
    • Dikhususkan untuk pengambilan perubahan secara real time dari log transaksi database.

  • Kekurangan:

    • Memerlukan pengalaman khusus dengan Kafka dan ZooKeeper.
    • Pengiriman minimal satu kali perubahan data, yang berarti Anda memerlukan penanganan duplikat.
    • 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 platform data cloud.

  • Kelebihan:

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

  • Kekurangan:

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

Menentukan rencana dan linimasa migrasi

Agar migrasi database dan peralihan produksi berhasil, sebaiknya Anda menyiapkan rencana migrasi yang jelas dan komprehensif. Untuk membantu mengurangi dampak pada bisnis Anda, sebaiknya buat daftar semua item pekerjaan yang diperlukan.

Menentukan cakupan migrasi akan mengungkapkan tugas pekerjaan 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 kontinuitas 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 terencana masih dapat muncul. Sebaiknya Anda selalu memiliki rencana rollback. Sebagai praktik terbaik, ikuti panduan dari Migrasi ke Google Cloud: Praktik terbaik untuk memvalidasi rencana migrasi.

TDD

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

  • Persyaratan dan tingkat kepentingan bisnis
  • Batas waktu pemulihan (RTO)
  • Toleransi durasi kehilangan data (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 linimasa 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 estimasi durasi.

Linimasa tidak hanya harus memperhitungkan eksekusi 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 Membuat profil koneksi Cloud migration engineer -3 Selesai
19/11/2023 Migrasi Menyiapkan DMS Mem-build dan memulai tugas migrasi Cloud migration engineer -2 Belum dimulai
19/11/2023 Migrasi Memantau DMS Memantau Tugas DMS dan perubahan DDL di instance sumber Cloud migration engineer -2 Belum dimulai
21/11/2023 Migrasi DMS Migrasi Sistem Mempromosikan replika DMS Cloud migration engineer 0 Belum dimulai
21/11/2023 Migrasi Validasi migrasi Validasi migrasi database Tim migrasi 0 Belum dimulai
21/11/2023 Migrasi Pengujian aplikasi Menjalankan kemampuan dan pengujian performa Tim migrasi 0 Belum dimulai
22/11/2023 Migrasi Tata kelola perusahaan Validasi migrasi BISA atau TIDAK BISA 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

Beberapa migrasi 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, idealnya database yang tidak penting. 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 secara keseluruhan.

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

Tugas migrasi database paralel.

Dalam contoh yang ditampilkan 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 berada dalam status yang tidak dapat digunakan.

Tugas persiapan dapat dikategorikan sebagai berikut:

  • Persiapan dan prasyarat untuk instance Amazon RDS atau Amazon Aurora
  • Persiapan dan prasyarat database sumber
  • Penyiapan instance Cloud SQL untuk PostgreSQL dan AlloyDB untuk PostgreSQL
  • 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 di instance RDS. Jika instance RDS Anda dikonfigurasi agar bersifat 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 dan menerapkan grup keamanan ke instance Amazon RDS atau Amazon Aurora:

    • 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.

  • Jika Anda bermigrasi dari Amazon RDS, pastikan Anda memiliki cukup disk kosong untuk melakukan buffering log write-ahead selama durasi operasi beban penuh di instance Amazon RDS.

  • Untuk replikasi yang sedang berlangsung (perubahan streaming melalui CDC), Anda harus menggunakan instance RDS lengkap, bukan replika baca.

  • Jika menggunakan replikasi bawaan, Anda perlu menyiapkan instance Amazon RDS atau Amazon Aurora untuk replikasi PostgreSQL. Replikasi bawaan atau alat yang menggunakan replikasi bawaan memerlukan replikasi logis untuk PostgreSQL.

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

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

Persiapan dan prasyarat database sumber

  • Jika Anda memilih untuk menggunakan Layanan Migrasi Database, konfigurasikan database sumber sebelum terhubung ke database tersebut. Untuk informasi selengkapnya, lihat Mengonfigurasi sumber untuk PostgreSQL dan Mengonfigurasi sumber untuk PostgreSQL ke AlloyDB untuk PostgreSQL.

  • Untuk tabel yang tidak memiliki kunci utama, setelah Database Migration Service memigrasikan cadangan awal, hanya pernyataan INSERT yang akan dimigrasikan ke database target selama fase CDC. Pernyataan DELETE dan UPDATE tidak dimigrasikan untuk tabel tersebut.

  • Perhatikan bahwa objek besar tidak dapat direplikasi oleh Database Migration Service, karena fasilitas decoding logis di PostgreSQL tidak mendukung perubahan decoding pada objek besar.

  • Jika Anda memilih untuk menggunakan replikasi bawaan, pertimbangkan bahwa replikasi logis memiliki batasan tertentu sehubungan dengan perintah, urutan, dan objek besar bahasa definisi data (DDL). Kunci utama harus ada atau ditambahkan pada tabel yang akan diaktifkan untuk CDC dan yang mengalami banyak pembaruan.

  • Beberapa alat migrasi pihak ketiga mewajibkan semua kolom objek besar memiliki nullable. Setiap kolom objek besar yang NOT NULL harus menghapus batasan tersebut selama migrasi.

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

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

Penyiapan instance Cloud SQL untuk PostgreSQL dan AlloyDB untuk PostgreSQL

Agar instance target Anda mencapai tingkat performa yang serupa dengan instance sumber, pilih ukuran dan spesifikasi instance database PostgreSQL target agar cocok dengan instance sumber. Perhatikan dengan cermat ukuran dan throughput disk, operasi input/output per detik (IOPS), dan jumlah CPU virtual (vCPU). Ukuran yang salah dapat menyebabkan waktu migrasi yang lama, masalah performa database, error database, dan masalah performa aplikasi. Saat menentukan instance Cloud SQL untuk PostgreSQL atau AlloyDB untuk PostgreSQL, perlu diingat bahwa performa disk didasarkan pada ukuran disk dan jumlah vCPU.

Anda harus mengonfirmasi properti dan persyaratan berikut sebelum membuat instance Cloud SQL untuk PostgreSQL dan AlloyDB untuk PostgreSQL. Jika ingin mengubah properti dan persyaratan ini nanti, Anda harus membuat ulang instance.

  • Pilih project dan region instance Cloud SQL untuk PostgreSQL dan AlloyDB untuk PostgreSQL target Anda dengan cermat. Instance tidak dapat dimigrasikan antar-project dan region Google Cloud tanpa transfer data.

  • Migrasikan ke versi utama yang cocok di Cloud SQL untuk PostgreSQL dan AlloyDB untuk PostgreSQL. Misalnya, jika Anda menggunakan PostgreSQL 14.x di Amazon RDS atau Amazon Aurora, Anda harus bermigrasi ke Cloud SQL atau AlloyDB untuk PostgreSQL untuk PostgreSQL versi 14.x.

  • Replikasi informasi pengguna secara terpisah jika Anda menggunakan cadangan mesin database bawaan atau Layanan Migrasi Database. Untuk mengetahui detailnya, tinjau batasan di bagian Pencadangan khusus mesin database.

  • Tinjau flag konfigurasi khusus mesin database dan bandingkan nilai instance sumber dan targetnya. Pastikan Anda memahami dampaknya dan apakah keduanya harus sama atau tidak. Misalnya, saat menggunakan PostgreSQL, sebaiknya bandingkan nilai dari tabel pg_settings di database sumber Anda dengan nilai di instance Cloud SQL dan AlloyDB untuk PostgreSQL. Perbarui setelan flag sesuai kebutuhan pada instance database target untuk mereplikasi setelan sumber.

  • Bergantung pada sifat beban kerja, Anda mungkin perlu mengaktifkan ekstensi tertentu untuk mendukung database. Jika beban kerja Anda memerlukan ekstensi ini, tinjau ekstensi PostgreSQL yang didukung dan cara mengaktifkannya di Cloud SQL dan AlloyDB untuk PostgreSQL.

Untuk informasi selengkapnya tentang penyiapan Cloud SQL untuk PostgreSQL, lihat Opsi konfigurasi instance, Flag khusus mesin database, dan ekstensi yang didukung.

Untuk mengetahui informasi selengkapnya tentang penyiapan AlloyDB untuk PostgreSQL, lihat Flag database yang didukung dan ekstensi yang didukung.

Penyiapan khusus migrasi

Jika Anda dapat menanggung periode nonaktif, Anda dapat mengimpor file dump SQL ke Cloud SQL dan AlloyDB untuk PostgreSQL. Dalam kasus tersebut, Anda mungkin perlu membuat bucket Cloud Storage untuk menyimpan dump database.

Jika menggunakan replikasi, Anda harus memastikan bahwa replika Cloud SQL dan AlloyDB untuk PostgreSQL memiliki akses ke database utama (sumber) Anda. Akses ini dapat diperoleh dengan menggunakan opsi konektivitas yang didokumentasikan.

Bergantung pada kasus penggunaan dan tingkat kepentingan, Anda mungkin perlu menerapkan skenario penggantian, yang biasanya mencakup pembalikan arah replika. Dalam hal ini, Anda mungkin memerlukan mekanisme replikasi tambahan dari Cloud SQL dan AlloyDB untuk PostgreSQL target kembali ke instance Amazon sumber.

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

Jika Anda bermigrasi ke AlloyDB untuk PostgreSQL, pertimbangkan untuk menggunakan instance Cloud SQL untuk PostgreSQL sebagai tujuan potensial untuk skenario penggantian Anda. Gunakan ekstensi pglogical untuk menyiapkan replikasi logis ke instance Cloud SQL tersebut.

Untuk informasi selengkapnya, lihat referensi berikut:

Menentukan tugas eksekusi

Tugas eksekusi menerapkan pekerjaan migrasi itu sendiri. Tugas ini bergantung pada alat migrasi yang Anda pilih, seperti yang dijelaskan dalam subbagian berikut.

Pencadangan mesin database bawaan

Gunakan utilitas pg_dump untuk membuat cadangan. Untuk mengetahui informasi selengkapnya tentang cara menggunakan utilitas ini untuk mengimpor dan mengekspor data, lihat referensi berikut:

Tugas migrasi Database Migration Service

Tentukan dan konfigurasikan 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 sukses. Pilih waktu saat beban kerja Anda dapat mengatasi periode nonaktif kecil untuk migrasi dan peralihan produksi.

Di Database Migration Service, migrasi dimulai dengan dump dan pemulihan skema awal tanpa indeks dan batasan, diikuti dengan operasi penyalinan data. Setelah penyalinan data selesai, indeks dan batasan akan dipulihkan. Terakhir, replikasi perubahan berkelanjutan dari instance database sumber ke tujuan dimulai.

Database Migration Service menggunakan ekstensi pglogical untuk replikasi dari sumber ke instance database target. Pada awal migrasi, ekstensi ini menyiapkan replikasi dengan mewajibkan kunci jangka pendek eksklusif pada semua tabel di instance Amazon RDS atau Amazon Aurora sumber Anda. Oleh karena itu, sebaiknya mulai migrasi saat database paling sepi, dan hindari pernyataan pada sumber selama fase dump dan replikasi, karena pernyataan DDL tidak direplikasi. Jika Anda harus melakukan operasi DDL, gunakan fungsi 'pglogical' untuk menjalankan pernyataan DDL di instance sumber atau jalankan pernyataan DDL yang sama secara manual di instance target migrasi, tetapi hanya setelah tahap dump awal selesai.

Proses migrasi dengan Database Migration Service berakhir dengan operasi promosi. Mempromosikan instance database akan memutuskan koneksi database tujuan dari alur perubahan yang berasal dari database sumber, lalu instance tujuan yang sekarang berdiri sendiri akan dipromosikan ke instance utama. Pendekatan ini juga disebut tombol produksi.

Untuk proses penyiapan migrasi yang sepenuhnya mendetail, lihat panduan memulai cepat untuk PostgreSQL dan PostgreSQL ke AlloyDB untuk PostgreSQL.

Replikasi bawaan mesin database

Cloud SQL mendukung dua jenis replikasi logis: replikasi logis bawaan PostgreSQL dan replikasi logis melalui ekstensi pglogical. Untuk AlloyDB untuk PostgreSQL, sebaiknya gunakan ekstensi pglogical untuk replikasi. Setiap jenis replika logika memiliki fitur dan batasan tersendiri.

Replikasi logis bawaan memiliki fitur dan batasan berikut:

  • Fungsi ini tersedia di PostgreSQL 10 dan yang lebih baru.
  • Semua perubahan dan kolom direplikasi. Publikasi ditentukan di tingkat tabel.
  • Data hanya direplikasi dari tabel dasar ke tabel dasar.
  • Konektor ini tidak melakukan replikasi urutan.
  • Ini adalah jenis replikasi yang direkomendasikan jika ada banyak tabel yang tidak memiliki kunci utama. Menyiapkan replikasi logis PostgreSQL bawaan. Untuk tabel tanpa kunci utama, terapkan formulir REPLICA IDENTITY FULL sehingga replikasi bawaan menggunakan seluruh baris sebagai ID unik, bukan kunci utama.

Replikasi logis pglogical memiliki fitur dan batasan berikut:

  • Fungsi ini tersedia di semua versi PostgreSQL dan menawarkan dukungan lintas versi.
  • Pemfilteran baris tersedia di sumber.
  • Tindakan ini tidak mereplikasi tabel UNLOGGED dan TEMPORARY.
  • Kunci utama atau kunci unik diperlukan pada tabel untuk merekam perubahan UPDATE dan DELETE.
  • Replikasi urutan tersedia.
  • Replikasi yang tertunda dapat terjadi.
  • Fitur ini menyediakan deteksi konflik dan resolusi yang dapat dikonfigurasi jika ada beberapa penayang atau konflik antara data yang direplikasi dan perubahan lokal.

Untuk mengetahui petunjuk cara menyiapkan replikasi logis PostgreSQL bawaan dari server eksternal seperti Amazon RDS atau Amazon Aurora untuk PostgreSQL, lihat referensi berikut:

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 mendapatkan data dari berbagai sumber, memproses data, lalu mengirimkan data ke aplikasi atau target lain.

Anda menggunakan satu atau beberapa alur untuk mengatur proses migrasi ini dalam aplikasi kustom. Untuk membuat kode aplikasi kustom, Anda memiliki pilihan menggunakan alat pemrograman grafis atau bahasa pemrograman Tungsten Query Language (TQL).

Untuk informasi selengkapnya tentang cara menggunakan Striim, lihat referensi berikut:

Jika Anda memutuskan untuk menggunakan Striim untuk memigrasikan data, lihat panduan berikut tentang cara menggunakan Striim untuk memigrasikan data ke Google Cloud:

Menentukan skenario penggantian

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

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

Tentukan kriteria keberhasilan dan tentukan waktu untuk 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 berikutnya jika tugas migrasi satu kali atau pemulihan cadangan gagal di tengah jalan. Bergantung pada berapa lama 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 rollback migrasi setelah Anda melakukan penghentian produksi, jika masalah pada instance target muncul. Jika Anda menerapkan rencana penggantian, ingatlah bahwa rencana tersebut harus diperlakukan sebagai migrasi database lengkap, 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 akan menggunakannya, sebaiknya Anda selalu memiliki strategi penggantian.

Penggantian sederhana

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

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

Replikasi terbalik

Dalam strategi ini, Anda mereplikasi operasi tulis yang terjadi di database target baru setelah peralihan produksi kembali ke database sumber awal. Dengan cara ini, Anda akan menjaga sumber asli tetap sinkron dengan database target baru dan membuat penulisan terjadi di instance database target baru. Kelemahan utamanya adalah Anda tidak dapat menguji aliran replikasi hingga setelah beralih ke instance database target, sehingga tidak memungkinkan pengujian menyeluruh dan memiliki periode kecil tanpa penggantian.

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

Replikasi maju

Strategi ini adalah variasi dari replikasi balik. 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 saat Anda harus menghapus database sumber awal segera setelah penghentian 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 secara bertahap hingga Anda hanya menggunakan instance database target. Jika ada masalah, Anda dapat menghubungkan aplikasi kembali ke sumber awal tanpa periode nonaktif. Anda dapat menghapus sumber awal dan mekanisme penulisan duplikat saat mempertimbangkan migrasi yang dilakukan tanpa masalah yang diamati.

Sebaiknya gunakan pendekatan ini jika Anda tidak boleh mengalami periode nonaktif migrasi, memiliki penggantian yang andal, dan memiliki waktu serta resource untuk melakukan pemfaktoran ulang aplikasi.

Melakukan pengujian dan validasi

Tujuan langkah ini adalah untuk menguji dan memvalidasi hal berikut:

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

Tentukan faktor penentu 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 digabungkan, redundan, 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 workload analisis, dengan kehilangan sebagian data tidak memengaruhi tren umum atau performa workload Anda.
  • Kriteria kualitas dan kuantitas data, yang dapat Anda terapkan ke lingkungan sumber dan bandingkan dengan lingkungan target setelah migrasi.
  • Kriteria performa. Beberapa transaksi bisnis mungkin lebih lambat di lingkungan target, tetapi waktu pemrosesannya masih dalam ekspektasi yang ditentukan.

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

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

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

Alat berikut dapat digunakan untuk pengujian, validasi, dan benchmark database:

  • HammerDB: alat pengujian beban dan benchmark database open source. Platform ini mendukung beban kerja transaksional dan analitis 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 informasi selengkapnya, lihat Pengujian beban SQL Server menggunakan HammerDB dan Benchmark performa Amazon RDS SQL Server menggunakan HammerDB.
  • Alat Benchmark DBT2: benchmark khusus untuk MySQL. Kumpulan kit workload database meniru aplikasi untuk perusahaan yang memiliki warehouse dan melibatkan campuran transaksi baca dan tulis. Gunakan alat ini jika Anda ingin menggunakan pengujian beban pemrosesan transaksi online (OLTP) yang sudah jadi.
  • 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 dapat lambat, bergantung pada ukuran dan kompleksitas database. Sebaiknya gunakan alat ini jika kesederhanaan penting.
  • DbFit: framework pengujian database open source yang mendukung pengembangan kode yang berbasis pengujian dan pengujian otomatis. Library 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 luas, dibandingkan dengan alat lain. Sebaiknya gunakan alat ini jika kueri Anda tidak kompleks dan Anda ingin melakukan pengujian otomatis serta mengintegrasikannya dengan proses continuous integration dan deployment.

Untuk menjalankan pengujian menyeluruh, termasuk pengujian rencana migrasi, selalu lakukan latihan uji coba migrasi. Uji coba melakukan migrasi database cakupan penuh tanpa mengalihkan workload produksi apa pun, dan menawarkan kelebihan 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 diperlukan untuk migrasi yang sebenarnya, sehingga Anda dapat mengkalibrasi linimasa.
  • Merepresentasikan kesempatan untuk menguji, memvalidasi, dan menyesuaikan rencana migrasi. Terkadang Anda tidak dapat merencanakan semuanya terlebih dahulu, sehingga hal ini membantu Anda menemukan kesenjangan.

Pengujian data dapat dilakukan pada sekumpulan kecil database yang akan dimigrasikan atau seluruh set. Bergantung pada jumlah total database dan alat yang digunakan untuk menerapkan migrasinya, Anda dapat memutuskan untuk menggunakan 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 dijalankan 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 untuk 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 otomatis dan dapat diulang di sistem sumber mana pun. Rangkaian kasus pengujian otomatis disesuaikan untuk dijalankan terhadap aplikasi yang dialihkan.

Jika Anda menggunakan Database Migration Service sebagai alat migrasi, lihat versi "Memverifikasi migrasi" untuk PostgreSQL atau PostgreSQL ke AlloyDB untuk PostgreSQL.

Alat Validasi Data

Untuk melakukan validasi data, sebaiknya gunakan Alat Validasi Data (DVT). DVT adalah alat Python CLI 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 Google Cloud, termasuk AlloyDB untuk PostgreSQL, BigQuery, Cloud SQL, Spanner, JSON, dan file CSV di Cloud Storage. Eventarc 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 lainnya.

Pertimbangkan praktik terbaik berikut untuk migrasi data Anda:

  • Beri tahu tim yang terlibat setiap kali langkah rencana dimulai dan selesai.
  • Jika ada langkah yang memerlukan waktu lebih lama dari yang diperkirakan, bandingkan waktu yang berlalu dengan jumlah waktu maksimum yang dialokasikan untuk langkah tersebut. Berikan update perantara reguler kepada tim yang terlibat saat hal ini terjadi.
  • Jika rentang waktu lebih besar dari jumlah waktu maksimum yang dicadangkan untuk setiap langkah dalam rencana, pertimbangkan untuk melakukan rollback.
  • Buat keputusan "go or no-go" untuk setiap langkah rencana migrasi dan cut-over.
  • 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 cut-over produksi

Proses peralihan produksi tingkat tinggi dapat berbeda-beda, bergantung pada strategi migrasi yang Anda pilih. Jika Anda dapat mengalami periode nonaktif pada beban kerja, peralihan migrasi akan dimulai dengan menghentikan operasi tulis ke database sumber.

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

  • 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 harus memvalidasi data di database target. Anda mengonfirmasi bahwa database sumber dan database target sudah sinkron dan data dalam instance target mematuhi standar keberhasilan migrasi yang Anda pilih.

Setelah validasi data lulus kriteria Anda, Anda dapat melakukan transisi 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 dengan menggunakan pola deployment blue-green. Beberapa periode nonaktif aplikasi mungkin terjadi.

Ikuti praktik terbaik untuk peralihan produksi:

  • Pantau aplikasi Anda yang berfungsi dengan database target setelah pengalihan.
  • Tentukan jangka 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 untuk melakukan rollback 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 migrasi sistem selesai, Anda dapat menghapus database sumber. Sebaiknya lakukan tindakan penting berikut sebelum pembersihan instance sumber Anda:

  • Buat cadangan akhir dari setiap database sumber. Cadangan 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, pastikan data tersebut cocok dengan data yang telah Anda kumpulkan dalam fase pembuatan inventaris. Sesuaikan parameter instance target agar cocok dengan parameter dari instance sumber.

  • Kumpulkan statistik database dari instance sumber dan bandingkan dengan yang ada 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. Penyiapannya menyerupai proses migrasi, tetapi akan berjalan secara terbalik: database sumber awal akan menjadi target baru.

Sebagai praktik terbaik untuk terus memperbarui instance sumber setelah peralihan, replikasikan operasi tulis yang dilakukan pada instance Cloud SQL target kembali ke database sumber. Jika perlu melakukan rollback, Anda dapat kembali ke instance sumber lama dengan kehilangan data minimal.

Atau, Anda dapat menggunakan instance lain dan mereplikasi perubahan ke instance tersebut. Misalnya, jika AlloyDB untuk PostgreSQL adalah tujuan migrasi, pertimbangkan untuk menyiapkan replikasi ke instance Cloud SQL untuk PostgreSQL untuk skenario penggantian.

Selain pembersihan lingkungan sumber, konfigurasi kritis berikut untuk instance Cloud SQL untuk PostgreSQL harus dilakukan:

  • Konfigurasikan periode pemeliharaan untuk instance utama Anda guna mengontrol waktu saat update yang mengganggu dapat terjadi.
  • Konfigurasikan penyimpanan di instance sehingga Anda memiliki minimal 20% kapasitas yang tersedia untuk mengakomodasi operasi pemeliharaan database penting apa pun yang dapat dijalankan Cloud SQL. Untuk menerima pemberitahuan jika kapasitas disk yang tersedia menjadi lebih rendah dari 20%, buat kebijakan pemberitahuan berbasis metrik untuk metrik penggunaan disk.

Jangan memulai operasi administratif sebelum operasi sebelumnya selesai.

Untuk mengetahui informasi selengkapnya tentang pemeliharaan dan praktik terbaik di instance Cloud SQL untuk PostgreSQL dan AlloyDB untuk PostgreSQL, lihat referensi berikut:

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 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 Anda, lihat Bermigrasi ke Google Cloud: Mengoptimalkan lingkungan Anda dan Proses pengoptimalan performa.

Menetapkan persyaratan pengoptimalan

Tinjau persyaratan pengoptimalan berikut untuk lingkungan Google Cloud Anda dan pilih persyaratan yang paling sesuai dengan workload 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:

Meningkatkan efisiensi biaya infrastruktur database Anda

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

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 instance Anda tidak dibatasi pada memori atau CPU.

    • Untuk workload yang membutuhkan performa tinggi, pastikan instance Anda memiliki memori minimal 60 GB.
    • Untuk penyisipan, pembaruan, 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 yang serupa). Identifikasi perintah yang paling mahal dan coba optimalkan.

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

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

Saat bermigrasi dari Amazon RDS dan Aurora untuk PostgreSQL ke Cloud SQL untuk PostgreSQL, pertimbangkan panduan berikut:

  • Gunakan penyimpanan dalam cache untuk meningkatkan performa baca. Periksa berbagai statistik dari tampilan pg_stat_database. Misalnya, rasio blks_hit / (blks_hit + blks_read) harus lebih besar dari 99%. Jika rasio ini tidak lebih besar dari 99%, pertimbangkan untuk meningkatkan ukuran RAM instance Anda. Untuk informasi selengkapnya, lihat Kolektor statistik PostgreSQL.
  • Mengambil kembali ruang dan mencegah performa indeks yang buruk. Bergantung pada seberapa sering data Anda berubah, tetapkan jadwal untuk menjalankan perintah VACUUM di Cloud SQL untuk PostgreSQL.
  • Gunakan edisi Cloud SQL Enterprise Plus untuk meningkatkan batas konfigurasi mesin dan cache data. Untuk informasi selengkapnya tentang Cloud SQL Enterprise Plus, lihat Pengantar edisi Cloud SQL.
  • Beralih ke AlloyDB untuk PostgreSQL. Jika beralih, Anda dapat memiliki kompatibilitas PostgreSQL penuh, pemrosesan transaksional yang lebih baik, dan workload analisis transaksional yang cepat yang didukung di database pemrosesan Anda. Anda juga mendapatkan rekomendasi untuk indeks baru melalui penggunaan fitur konsultan indeks.

Untuk informasi selengkapnya tentang cara meningkatkan performa infrastruktur database Cloud SQL untuk PostgreSQL, lihat dokumentasi peningkatan performa Cloud SQL untuk PostgreSQL.

Saat bermigrasi dari Amazon RDS dan Aurora for PostgreSQL ke AlloyDB for PostgreSQL, pertimbangkan panduan berikut untuk meningkatkan performa instance database AlloyDB for PostgreSQL:

Meningkatkan kemampuan observasi database

Mendiagnosis dan memecahkan masalah dalam aplikasi yang terhubung ke instance database dapat menjadi tantangan dan memakan waktu. Oleh karena itu, tempat terpusat tempat semua anggota tim dapat melihat apa yang terjadi di tingkat database dan instance sangatlah 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 pengukuran layanan Anda dan resource Google Cloud yang Anda gunakan. Cloud Monitoring mencakup dasbor yang ditetapkan 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 menjalankan rencana kueri dari aplikasi untuk membantu Anda melacak cara permintaan diterapkan di seluruh aplikasi Anda.

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

Untuk informasi selengkapnya tentang cara meningkatkan kemampuan observasi infrastruktur database Anda, lihat bagian dokumentasi berikut:

Praktik terbaik dan panduan operasional Cloud SQL dan AlloyDB untuk PostgreSQL secara umum

Terapkan praktik terbaik untuk Cloud SQL guna mengonfigurasi dan menyesuaikan 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 yang mungkin dilakukan Cloud SQL.
  • Memiliki terlalu banyak tabel database dapat memengaruhi waktu upgrade database. Idealnya, usahakan untuk memiliki kurang dari 10.000 tabel per instance.
  • Pilih ukuran yang sesuai untuk instance Anda guna memperhitungkan retensi log transaksi (biner), terutama untuk instance aktivitas tulis yang tinggi.

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

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

Melakukan dan menjadwalkan operasi pemeliharaan database: Defragmentasi indeks, update statistik, analisis vakum, dan pengindeksan ulang tabel yang sering diperbarui. 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.

Melakukan penyesuaian dan pengoptimalan database: Apakah tabel dalam database Anda terstruktur dengan benar? Apakah kolom memiliki jenis data yang benar? Apakah model data Anda cocok untuk jenis beban kerja? Selidiki kueri lambat dan rencana eksekusinya. Apakah kueri tersebut menggunakan indeks yang tersedia? Periksa pemindaian, kunci, dan tunggu indeks pada resource lainnya. Pertimbangkan untuk menambahkan indeks guna mendukung kueri penting Anda. Hapus indeks dan kunci asing yang tidak penting. Pertimbangkan untuk menulis ulang kueri dan join 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 memadai untuk kebutuhan Anda, dan penyesuaian serta pengoptimalan database tidak membantu, pertimbangkan untuk menskalakan secara horizontal. Merutekan kueri baca dari aplikasi 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. Sebaiknya partisi tabel Anda. Arsipkan data yang tidak diperlukan lagi, jika memungkinkan. Normalisasi struktur database Anda, tetapi ingat 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 pembuatan ulang arsitektur 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 operasi tulis dan baca secara horizontal. Namun, hal ini meningkatkan kompleksitas database dan beban kerja aplikasi Anda. Hal ini juga dapat menyebabkan shard yang tidak seimbang yang disebut hotspot, yang akan lebih besar daripada manfaat sharding.

Untuk Cloud SQL untuk PostgreSQL dan AlloyDB untuk PostgreSQL, pertimbangkan praktek terbaik berikut:

  • Untuk memindahkan traffic dari instance utama, tambahkan replika baca. Anda juga dapat menggunakan load balancer seperti HAProxy untuk mengelola traffic ke replika. Namun, hindari terlalu banyak replika karena hal ini akan menghambat operasi VACUUM. Untuk informasi selengkapnya tentang cara menggunakan HAProxy, lihat situs resmi HAProxy.
  • Optimalkan operasi VACUUM dengan meningkatkan memori sistem dan parameter maintenance_work_mem. Meningkatkan memori sistem berarti lebih banyak tuple dapat dikelompokkan dalam setiap iterasi.
  • Karena indeks yang lebih besar menghabiskan banyak waktu untuk pemindaian indeks, tetapkan parameter INDEX_CLEANUP ke OFF untuk membersihkan dan membekukan data tabel dengan cepat.
  • Saat menggunakan AlloyDB untuk PostgreSQL, gunakan dasbor Insight Sistem dan log audit AlloyDB untuk PostgreSQL. Dasbor Insight Sistem AlloyDB untuk PostgreSQL menampilkan metrik resource yang Anda gunakan, dan memungkinkan Anda memantaunya. Untuk mengetahui detail selengkapnya, lihat panduan dari topik Memantau instance dalam dokumentasi AlloyDB untuk PostgreSQL.

Untuk mengetahui detail selengkapnya, lihat referensi berikut:

Langkah selanjutnya

Kontributor

Penulis:

Kontributor lainnya: Somdyuti Paul | Spesialis Pengelolaan Data