Bermigrasi dari AWS ke Google Cloud: Bermigrasi dari Amazon RDS untuk SQL Server ke Cloud SQL untuk SQL Server

Last reviewed 2024-06-28 UTC

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

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

Dokumen ini berfokus pada migrasi database homogen, yaitu migrasi di mana {i>database<i} sumber dan tujuan adalah teknologi {i>database<i} yang sama. Tujuan adalah Amazon RDS untuk SQL Server, dan tujuannya adalah Cloud SQL untuk SQL Server.

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
• Bermigrasi dari Amazon RDS untuk SQL Server ke Cloud SQL untuk SQL Server (dokumen ini)

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

Diagram berikut menggambarkan jalur perjalanan migrasi Anda.

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

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

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

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

Menilai lingkungan sumber

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

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

Fase penilaian terdiri dari tugas-tugas berikut:

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

Untuk mengetahui informasi selengkapnya tentang fase penilaian dan tugas ini, lihat Bermigrasi ke Google Cloud: Menilai dan menemukan workload Anda. Bagian di bawah ini didasarkan pada informasi dalam dokumen tersebut.

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

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

Membuat inventaris instance Amazon RDS

Untuk menentukan cakupan migrasi, buat inventaris dan kumpulkan informasi tentang instance Amazon RDS Anda. Idealnya, proses itu harus otomatis, karena pendekatan manual rentan terhadap kesalahan dan dapat menyebabkan asumsi yang salah.

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

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

Alat untuk penilaian

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

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

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

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

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

Output penilaian database migVisor memberikan hal berikut:

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

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

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

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

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

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

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

Mengidentifikasi dan mendokumentasikan cakupan migrasi dan periode nonaktif yang terjangkau

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

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

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

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

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

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

Menilai proses deployment dan administrasi Anda

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

Pertimbangkan cara Anda menyelesaikan tugas-tugas berikut:

• Tentukan dan terapkan kebijakan keamanan untuk instance Anda: Untuk misalnya, Anda mungkin perlu mengganti Amazon Security Groups. Anda dapat menggunakan Peran IAM Google, aturan firewall VPC, dan Kontrol Layanan VPC untuk mengontrol akses ke instance Cloud SQL Anda dan membatasi data dalam VPC. Jika Anda berencana menggunakan otentikasi Windows dengan Cloud SQL untuk SQL Server, Anda perlu men-deploy Microsoft AD Terkelola dan terhubung ke infrastruktur {i> Active Directory<i} yang ada.
• Menambahkan patch dan mengonfigurasi instance Anda: Alat deployment yang ada mungkin perlu diperbarui. Misalnya, Anda mungkin menggunakan di grup parameter Amazon atau grup opsi Amazon. Alat penyediaan Anda mungkin perlu disesuaikan untuk menggunakan Cloud Storage atau Secret Manager untuk membaca daftar konfigurasi Anda.
• Mengelola infrastruktur pemantauan dan pemberitahuan: Kategori metrik untuk instance database sumber Amazon Anda memberikan kemampuan observasi selama proses migrasi. Kategori metrik mungkin mencakup Amazon CloudWatch, Insight Performa, Pemantauan yang Ditingkatkan, dan daftar proses OS.

Menyelesaikan penilaian

Setelah Anda membuat inventaris dari lingkungan Amazon RDS, selesaikan kegiatan lainnya pada fase penilaian sebagaimana dijelaskan dalam Bermigrasi ke Google Cloud: Menilai dan menemukan workload Anda.

Merencanakan dan membangun fondasi Anda

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

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

Fase perencanaan dan build terdiri dari tugas-tugas berikut:

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

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

Pemantauan dan pemberitahuan

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

Memigrasikan instance Amazon RDS untuk SQL Server ke Cloud SQL untuk SQL Server

Untuk memigrasikan instance, Anda melakukan langkah-langkah berikut:

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

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

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

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

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

6. Tentukan skenario penggantian untuk setiap tugas eksekusi.

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

8. Lakukan migrasi.

9. Melakukan migrasi sistem produksi.

10. Bersihkan lingkungan sumber dan konfigurasikan instance target.

11. Melakukan penyesuaian dan pengoptimalan.

Setiap fase dijelaskan di bagian berikut.

Memilih strategi migrasi

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

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

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

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

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

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

Diagram alir sebelumnya menunjukkan poin keputusan berikut:

• Apakah Anda mampu memberikan waktu nonaktif?

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

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

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

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

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

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

Meminimalkan periode nonaktif dan dampak terkait migrasi

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

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

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

Praktik umum berikut dapat membantu meminimalkan periode nonaktif dan dampaknya:

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

Pilih alat migrasi Anda

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

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

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

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

Layanan migrasi terkelola memberikan keuntungan berikut:

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

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

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

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

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

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

Alat untuk migrasi pemeliharaan terjadwal

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

Cadangan mesin database bawaan

Jika periode nonaktif yang signifikan dapat diterima, dan database sumber Anda dapat relatif statis, Anda dapat menggunakan fitur pencadangan dan pemulihan bawaan mesin {i>database<i} kemampuan IT.

Beberapa upaya diperlukan untuk pengaturan dan sinkronisasi, terutama untuk jumlah database, tetapi cadangan mesin {i>database<i} biasanya sudah tersedia dan mudah digunakan. Pendekatan ini cocok untuk semua ukuran {i>database<i}, dan ini biasanya lebih efektif dibandingkan alat lain untuk {i>instance<i} besar.

Cadangan mesin database memiliki batasan umum berikut:

• Pencadangan dapat rentan error, terutama jika dilakukan secara manual.
• Data tidak aman jika cadangan tidak dikelola dengan benar.
• Cadangan tidak memiliki kemampuan pemantauan yang tepat.

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

• Untuk cadangan {i>database<i} yang berukuran lebih besar dari 5 TB, gunakan cadangan beberapa file).
• Saat menggunakan cadangan bergaris, Anda tidak dapat mencadangkan atau memulihkan lebih dari 10 file cadangan sekaligus.
• Anda harus mencadangkan ke bucket Amazon S3 di region Amazon yang sama instance database sumber.
• Cadangan tidak mencakup login, izin, dan server SQL Server peran, karena ditetapkan di tingkat instance. Untuk mentransfer jenis ini data dari instance sumber ke instance target, gunakan PowerShell skrip atau {i>tool<i} seperti DBAtools baru.

Untuk mengetahui detail tentang batasan dan praktik terbaik, lihat Praktik terbaik untuk mengimpor dan mengekspor data dengan Cloud SQL untuk SQL Server dan Masalah Umum Cloud SQL untuk SQL Server.

Pendekatan lain untuk migrasi pemeliharaan terjadwal

Menggunakan pendekatan lain dapat memberikan lebih banyak kontrol dan fleksibilitas dalam proses migrasi pemeliharaan terjadwal.

Misalnya, dengan menggunakan file datar untuk mengekspor dan mengimpor data Anda (atau dengan menggunakan skrip), Anda dapat melakukan hal berikut:

• Melakukan transformasi, pemeriksaan, atau operasi lain pada data Anda selama migrasi. Misalnya, validasi, agregasi, atau normalisasi dan denormalisasi pada data sumber.
• Pilih struktur yang ingin Anda migrasikan dan struktur yang akan ditinggalkan. Anda mungkin memutuskan untuk mengekstrak hanya {i>subset<i} dari tabel Anda dalam {i>file<i} datar untuk impor.
• Pilih untuk mengecualikan data berdasarkan domain, sumber, usia, atau setelan kustom lainnya kriteria. Misalnya, Anda dapat mengecualikan data yang menjangkau dan menyimpannya di dalam file atau cadangan akhir sumber database, sebelum migrasi.
• Faktorkan ulang struktur database Anda, dan sinkronkan data yang muncul periode nonaktif migrasi.
• Mengonsolidasikan beberapa instance atau database ke dalam satu instance atau database, untuk memitigasi biaya operasional dan memudahkan masalah skalabilitas. Misalnya, Anda mungkin ingin mengubah pendekatan dari memiliki instance, database, atau skema per pelanggan ke satu multi-tenancy struktur database yang optimal.

Pendekatan lainnya termasuk yang berikut:

• Gunakan file CSV atau JSON: Dengan pendekatan ini, Anda mengekstrak file database data ke dalam file, lalu impor file tersebut ke instance target.

  • Meski umumnya lebih lambat, metode ini membantu Anda memigrasikan subset tabel (atau data dalam tabel tertentu).
  • Format CSV dan JSON dipahami oleh banyak alat.
  • Jika Anda mengotomatiskan proses, Anda memiliki opsi untuk ke migrasi replikasi berkelanjutan secara batch.

• Gunakan tag Wizard Impor dan Ekspor SQL Server dari Microsoft: Alat ini menggunakan Integrasi SQL Server Layanan (SSIS), dan memungkinkan Anda mengimpor data dari berbagai sumber, seperti mesin {i>database<i} atau {i>file<i} datar.

• Gunakan tag Wizard Membuat dan Memublikasikan Skrip di SQL Server dan utilitas bcp: Alat ini adalah bagian dari Microsoft SQL Server Management Studio.

  • Pendekatan ini memungkinkan Anda membuat skrip untuk seluruh skema database atau hanya sebagian.
  • Utilitas {i>bcp<i} memungkinkan Anda menulis {i>script<i} pada data dan mengekspornya menjadi file.

• Gunakan replikasi snapshot, jika sumber Anda menggunakan Amazon RDS Standard:

  • Dengan pendekatan ini, Anda akan memulihkan cadangan SQL Server dari instance RDS ke instance mandiri SQL Server di Compute Engine. Kemudian, gunakan replikasi snapshot untuk bermigrasi ke Cloud SQL untuk SQL Server.
  • Pembuatan snapshot akan menyimpan kunci pada tabel sumber, sehingga mungkin memengaruhi workload Anda.
  • Replikasi snapshot mungkin memberikan beban tambahan pada server Amazon RDS Anda.
  • Namun, Anda dapat memilih objek mana yang dimigrasikan atau direplikasi, yang memberikan fleksibilitas.
  • Untuk mengetahui detailnya, lihat Memigrasikan data dari SQL Server 2017 ke Cloud SQL untuk SQL Server menggunakan replikasi snapshot.

Alat untuk migrasi replikasi berkelanjutan

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

Diagram alir sebelumnya menunjukkan poin keputusan berikut:

• Apakah Anda lebih suka menggunakan layanan migrasi terkelola?

  • Jika ya, lanjutkan ke keputusan berikutnya. Jika Anda mampu membeli beberapa periode nonaktif minimal dan tidak memerlukan transformasi data atau real-time sinkronisasi, sebaiknya gunakan Database Migration Service. Jika tidak, pelajari ketiga opsi pihak ketiga.
  • Jika tidak, lanjutkan ke keputusan berikutnya. Jika mesin database mendukung replikasi bawaan, sebaiknya gunakan replikasi. Jika belum, sebaiknya pelajari opsi migrasi lainnya.

• Mampu memberikan periode nonaktif minimal, dan bermigrasi tanpa data transformasi atau sinkronisasi real-time?

  • Jika ya, sebaiknya gunakan Database Migration Service.
  • Jika tidak, pelajari opsi pihak ketiga.

• Apakah replikasi bawaan khusus mesin database didukung?

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

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

Database Migration Service untuk migrasi replikasi berkelanjutan

Database Migration Service mendukung migrasi homogen ke Cloud SQL untuk SQL Server, saat sumbernya adalah Amazon RDS.

Database Migration Service adalah alat yang mudah dan hemat biaya. Saran dari kami Database Migration Service untuk situasi dengan keadaan berikut:

• Anda dapat memberikan periode nonaktif yang minimal.
• Anda tidak memerlukan sinkronisasi real-time.
• Anda tidak perlu melakukan transformasi data selama migrasi.

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

• Jumlah periode nonaktif bergantung pada frekuensi log transaksi Anda cadangan.
• Cadangan tidak mencakup login, izin, atau server SQL Server peran, karena berada di tingkat instance. Buat skrip dari instance sumber, lalu mentransfernya ke instance target dengan Skrip atau alat PowerShell seperti DBAtools baru.

Untuk daftar lengkap batasan, lihat Batasan umum.

Replikasi bawaan mesin database

Cloud SQL mendukung replikasi untuk SQL Server. Namun, Amazon Standard RDS untuk SQL Server hanya bisa menjadi Pelanggan. Replikasi bawaan dari Amazon RDS Standar tidak tersedia. Hanya Amazon RDS Custom untuk SQL Server yang dapat disiapkan sebagai Penayang bawaan.

Untuk daftar fitur yang didukung dan tidak didukung di Amazon RDS, lihat Amazon RDS untuk Microsoft SQL Server.

Pendekatan lain untuk migrasi replikasi berkelanjutan

Pendekatan migrasi replikasi berkelanjutan lainnya mencakup hal berikut:

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

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

• Terapkan fungsi yang secara berkala mengkueri data pada sumber Anda Anda, filter data baru saja, dan tulis data ke CSV, JSON, atau Parquet .

  • File ini disimpan di bucket Google Cloud Storage.
  • File tersebut dapat langsung ditulis ke instance database target Anda dengan menggunakan fungsi Cloud Run.
  • Pengambilan data perubahan (CDC) dapat membantu Anda melakukan migrasi replikasi hampir secara real-time.
  • Anda dapat men-streaming CDC ke dalam data lake Amazon S3 dalam format Parquet, dengan menggunakan AWS Database Migration Service (AWS DMS).
  • Anda dapat memiliki implementasi kustom untuk membaca file dan menulis konten mereka ke Cloud SQL.

Alat pihak ketiga untuk migrasi replikasi berkelanjutan

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

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

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

• Kelebihan:

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

• Kekurangan:

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

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

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

• Kelebihan:

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

• Kekurangan:

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

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

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

• Kelebihan:

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

• Kekurangan:

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

Menentukan rencana dan jadwal migrasi

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

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

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

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

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

TDD

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

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

Matriks RACI

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

Linimasa

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

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

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

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

Rencana T-Minus mungkin terlihat seperti berikut:

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

Beberapa migrasi database

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

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

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

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

Menentukan tugas persiapan

Tugas persiapan adalah semua kegiatan yang perlu Anda selesaikan untuk memenuhi prasyarat migrasi. Jika Anda tidak menyelesaikan tugas persiapan, migrasi tidak dapat dilakukan atau {i>database<i} yang dimigrasikan mungkin tidak dapat digunakan sebagai suatu hasil.

Tugas persiapan dapat dikategorikan sebagai berikut:

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

Persiapan dan prasyarat instance Amazon RDS

Pertimbangkan penyiapan umum dan tugas prasyarat berikut:

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

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

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

• Untuk replikasi yang sedang berlangsung (perubahan {i>streaming<i} melalui CDC), Anda harus menggunakan {i>instance <i}RDS lengkap dan bukan replika baca, dengan CDC diaktifkan. Untuk mengetahui detailnya, lihat Menggunakan pengambilan data perubahan dengan SQL Server.

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

Persiapan dan prasyarat database sumber

• Memastikan bahwa database sumber memiliki penyimpanan buffer dan memori yang tersedia selama operasi migrasi. Misalnya, jika Anda menggunakan model file cadangan log, pantau penggunaan penyimpanan, dan pastikan untuk memiliki ruang penyimpanan {i>buffer<i}.
• Dokumentasikan pengaturan parameter {i>database<i} Anda, dan terapkan pada instance target Anda sebelum melakukan pengujian dan validasi migrasi.

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

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

Penyiapan Cloud SQL

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

Pastikan tujuan sudah sesuai. Penting untuk diperhatikan bahwa Opsi konfigurasi Amazon RDS mungkin berbeda dari Cloud SQL. Di kolom peristiwa bahwa Cloud SQL tidak memenuhi persyaratan Anda, pertimbangkan opsi yang mencakup database di Compute Engine.

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

• Pilih project dan region target Anda instance Cloud SQL dengan hati-hati. Instance Cloud SQL tidak dapat dimigrasikan di antara project dan region Google Cloud tanpa transfer data.

• Lakukan migrasi ke versi utama yang cocok di Cloud SQL. Misalnya, jika sumber Anda menggunakan SQL Server 15.0, migrasikan ke Cloud SQL untuk SQL Server 15.0. Jika versinya berbeda, setelan tingkat kompatibilitas harus untuk memastikan kemampuan mesin yang sama.

• Replikasikan informasi pengguna secara terpisah, jika Anda menggunakan mesin database bawaan cadangan atau Database Migration Service. Untuk mengetahui detailnya, tinjau batasan-batasan dalam Pencadangan khusus mesin database bagian.

• Tinjau flag konfigurasi khusus database engine dan bandingkan nilai instance sumber dan targetnya. Pastikan Anda memahami dampak dan apakah mereka harus sama atau tidak. Misalnya, kami sarankan untuk membandingkan nilai-nilai di {i>sys.configurations<i} tampilan di database sumber dengan nilai di Cloud SQL di instance Compute Engine. Perhatikan bahwa tidak semua tanda harus sama dan tidak semua perubahan tanda yang diizinkan di instance Cloud SQL.

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

• Praktik terbaik umum untuk SQL Server
• Opsi konfigurasi instance untuk SQL Server
• Flag khusus mesin database untuk SQL Server

Penyiapan khusus migrasi

Jika Anda menggunakan ekspor dan impor file untuk melakukan migrasi, atau menggunakan migrasi Database Migration Service , Anda perlu membuat bucket Cloud Storage. Bucket menyimpan file cadangan database dan log transaksi. Untuk informasi selengkapnya tentang cara menggunakan Database Migration Service, lihat Simpan file cadangan di bucket Cloud Storage.

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

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

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

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

Menentukan tugas eksekusi

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

Cadangan mesin database bawaan

Untuk mengetahui informasi dan petunjuk selengkapnya tentang cadangan khusus database, lihat Mengimpor data dari file BAK ke Cloud SQL untuk SQL Server dan Mengekspor data dari RDS untuk SQL Server. Untuk informasi selengkapnya tentang cara mengotomatiskan upload file log transaksi, lihat Jadwalkan upload file log transaksi untuk Amazon RDS.

Tugas migrasi Database Migration Service

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

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

Proses migrasi biasanya mencakup tugas berikut:

• Ekspor cadangan lengkap database sumber, lalu upload ke bucket Cloud Storage.
• Ambil cadangan file log transaksi, lalu unggah ke bucket Cloud Storage yang sama. Untuk informasi selengkapnya tentang cara mengotomatiskan proses ini, lihat Jadwalkan upload file log transaksi untuk Amazon RDS.
• Di Database Migration Service, Anda memantau pemrosesan cadangan log transaksi.
• Berhenti menulis ke database sumber.
• Tunggu hingga sumber dan target disinkronkan, yaitu saat cadangan log transaksi akhir diproses.
• Hentikan replikasi yang sedang berlangsung dan promosikan tugas migrasi.Dengan mempromosikan tugas migrasi, instance Cloud SQL tujuan dari instance database sumber, lalu dipromosikan ke instance utama.
• Deploy aplikasi yang mengarah ke database target baru.

Untuk proses penyiapan migrasi yang mendetail, lihat Memigrasikan database SQL Server Anda ke Cloud SQL untuk SQL Server.

Replikasi bawaan mesin database

Jika Anda menggunakan Amazon RDS Standard, Anda mungkin perlu bermigrasi terlebih dahulu ke Amazon RDS Custom versi, lalu direplikasi ke Cloud SQL.

Cloud SQL mendukung replikasi untuk SQL Server. Untuk informasi selengkapnya tentang replikasi dari server eksternal, lihat Memigrasikan data dari SQL Server 2017 ke Cloud SQL untuk SQL Server menggunakan replikasi snapshot.

Alat pihak ketiga

Tentukan tugas eksekusi untuk alat pihak ketiga yang telah Anda pilih. Misalnya, jika memutuskan untuk menggunakan Striim, Anda perlu membuat aplikasi di namespace, dan mengkonfigurasi pembaca CDC untuk terhubung ke {i>instance<i} Amazon. Untuk mengetahui detailnya, lihat Penyiapan SQL Server dalam dokumentasi Striim.

Menentukan skenario penggantian

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

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

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

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

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

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

Penggantian sederhana

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

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

Replikasi terbalik

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

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

Meneruskan replikasi

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

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

Penulisan duplikat

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

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

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

Melakukan pengujian dan validasi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Alat Validasi Data

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

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

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

DVT mendukung jenis validasi berikut:

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

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

Melakukan migrasi

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

Pertimbangkan praktik terbaik berikut untuk migrasi data Anda:

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

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

Melakukan cut-over produksi

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

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

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

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

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

Ikuti praktik terbaik untuk cut-over produksi Anda:

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

Membersihkan lingkungan sumber dan mengonfigurasi instance Cloud SQL

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

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

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

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

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

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

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

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

Jangan memulai operasi administratif sebelum operasi sebelumnya selesai.

Untuk informasi selengkapnya, lihat referensi berikut:

• Tentang pemeliharaan pada instance Cloud SQL.
• Setelan khusus mesin SQL Server

Mengoptimalkan lingkungan Anda setelah migrasi

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

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

Anda mengulangi urutan ini sampai Anda mencapai sasaran pengoptimalan.

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

Menetapkan persyaratan pengoptimalan

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

Meningkatkan keandalan dan ketersediaan database Anda

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

• Pada kasus beban kerja baca yang berat, tambahkan replika baca untuk mengurangi beban traffic dari instance utama.
• Untuk beban kerja yang sangat penting, gunakan konfigurasi ketersediaan tinggi, untuk failover regional, dan konfigurasi pemulihan dari bencana yang kuat.
• Untuk beban kerja yang tidak terlalu penting, pencadangan otomatis dan on-demand dapat memadai.
• Untuk mencegah penghapusan instance secara tidak sengaja, gunakan penghapusan instance perlindungan data.
• Aktifkan pemulihan point-in-time (PITR) untuk instance Cloud SQL untuk SQL Server Anda.
• Mengotomatiskan pencadangan database SQL dengan menggunakan rencana pemeliharaan.

Meningkatkan efektivitas biaya infrastruktur database Anda

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

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

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

• Identifikasi kemungkinan resource yang diperkirakan terlalu tinggi:

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

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

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

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

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

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

• Gunakan Active Assist untuk memperoleh analisis biaya dan rekomendasi.

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

Guna mengurangi biaya lisensi, khususnya untuk Cloud SQL untuk SQL Server, pertimbangkan hal berikut:

• Bermigrasi ke SQL Server Standard Edition, jika SLA memenuhi kebutuhan Anda.
• Nonaktifkan multithreading simultan (SMT) dan 25% core lebih banyak. Core tambahan dapat mengimbangi dampak performa dari menonaktifkan SMT. Strategi ini dapat membantu mengurangi biaya lisensi, tetapi dapat memengaruhi performa instance Anda. Rab sebaiknya lakukan pengujian beban pada instance untuk memastikan SLA tidak terpengaruh.
• Pertimbangkan migrasi heterogen dari Cloud SQL untuk SQL Server ke Cloud SQL untuk PostgreSQL atau AlloyDB untuk PostgreSQL, bergantung pada sebagian besar workload standar dan berbasis cloud.

Meningkatkan performa infrastruktur database Anda

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

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

• Pastikan instance Anda tidak dibatasi oleh memori atau CPU.

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

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

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

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

• Mencegah fragmentasi data dan indeks. Tetapkan jadwal untuk membuat ulang di SQL Server, tergantung pada seberapa sering data Anda berubah.

• Ubah Setelan khusus mesin SQL Server agar bekerja secara optimal untuk Cloud SQL.

• Untuk pemeliharaan indeks dan statistik, lihat Solusi Pemeliharaan SQL Server.

• Memperbarui statistik secara rutin di Cloud SQL untuk SQL Server.

• Pertimbangkan untuk melakukan operasi ETL pada replika baca, karena operasi itu mungkin akan memengaruhi cache instance.

Untuk informasi selengkapnya tentang cara meningkatkan performa, lihat Performa dalam "Mendiagnosis masalah", dan Cloud SQL - Analisis Performa dan Penyesuaian Kueri SQL Server.

Meningkatkan kemampuan observasi database

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

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

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

• Cloud Logging mengumpulkan data logging dari komponen aplikasi umum.

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

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

• Melihat dan mengajukan kueri log untuk instance Cloud SQL Anda.

• Mengamati status database untuk membantu Anda meningkatkan performa lingkungan dan untuk memecahkan masalah masalah akhir.

Praktik terbaik dan panduan operasional Cloud SQL umum

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

Beberapa rekomendasi umum Cloud SQL yang penting adalah sebagai berikut:

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

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

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

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

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

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

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

Sharding database: Anda dapat menyebarkan skala penulisan dengan melakukan sharding database. Sharding adalah operasi yang rumit dan melibatkan perancangan ulang database Anda. dan aplikasi dengan cara tertentu dan melakukan migrasi data. Anda membagi instance database dalam beberapa instance yang lebih kecil dengan menggunakan partisi spesifik kriteria. Kriteria tersebut dapat didasarkan pada pelanggan atau subjek. Opsi ini memungkinkan Anda menskalakan operasi tulis dan baca secara horizontal. Namun, hal ini meningkatkan kompleksitas database dan workload aplikasi Anda. Hal ini juga dapat menimbulkan sharding yang tidak seimbang yang disebut hotspot, yang akan lebih besar daripada manfaat sharding.

Khusus untuk Cloud SQL untuk SQL Server, pertimbangkan hal-hal berikut praktik:

• Untuk memperbarui pengaturan SQL Server untuk kinerja yang optimal dengan Cloud SQL, lihat Setelan SQL Server.
• Tentukan kapasitas subsistem I/O sebelum men-deploy SQL Server.

• Jika Anda memiliki {i>instance<i} yang besar, bagi menjadi {i>instance<i} yang lebih kecil, dengan mungkin:

  • Ukuran disk 4 TB atau lebih besar memberikan throughput dan IOPS yang lebih besar.
  • vCPU yang lebih tinggi memberikan IOPS dan throughput yang lebih tinggi. Saat menggunakan data yang lebih tinggi vCPU, memantau database menunggu paralelisme, yang mungkin juga meningkat.

• Nonaktifkan SMT jika performa menurun dalam beberapa situasi. Sebagai jika aplikasi menjalankan thread yang menjadi bottleneck dan arsitektur CPU tidak menangani ini secara efektif.

• Tetapkan jadwal untuk mengatur ulang atau membangun ulang indeks Anda, tergantung pada cara sering kali data Anda berubah.

• Tetapkan faktor pengisian yang sesuai untuk mengurangi fragmentasi. Memantau SQL Server untuk indeks yang hilang dan mungkin menawarkan performa yang lebih baik.

• Cegah file database menjadi terlalu besar. Setel autogrow dalam MB, bukan persentase, menggunakan penambahan yang sesuai dengan persyaratan. Selain itu, kelola pertumbuhan database secara proaktif sebelum autogrow batas tercapai.

• Untuk menskalakan kapasitas penyimpanan secara otomatis, mengaktifkan peningkatan penyimpanan otomatis. Cloud SQL dapat menambahkan ruang penyimpanan jika database dan instance kehabisan ruang.

• Pastikan Anda memahami persyaratan lokal, tata urutan, dan huruf besar/kecil dan aksen yang sensitif pada data yang Anda kerjakan. Jika Anda pilih kolasi untuk server, {i>database<i}, kolom, atau ekspresi Anda, Anda menetapkan karakteristik tertentu pada data Anda.

• Gabungan {i>hash<i} rekursif atau {i>hash bailout<i} menyebabkan penurunan performa dalam server tertentu. Jika Anda melihat banyak peristiwa peringatan hash dalam rekaman aktivitas, perbarui metode statistik pada kolom yang digabungkan. Untuk informasi selengkapnya, lihat Class Peristiwa Peringatan Hash.

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

Langkah selanjutnya

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

Kontributor

Penulis:

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

Kontributor lainnya:

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