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

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

Untuk migrasi ke Google Cloudini, sebaiknya ikuti framework migrasi yang dijelaskan dalam Migrate to Google Cloud: Get started.

Diagram berikut menggambarkan jalur perjalanan migrasi Anda.

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

1. Lakukan penilaian dan temukan workload dan data Anda.
2. Merencanakan dan membangun fondasi di Google Cloud.
3. Memigrasikan workload dan data Anda ke Google Cloud.
4. Optimalkan 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 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. Melatih dan mengajari tim Anda tentang Google Cloud.
4. Membuat eksperimen dan bukti konsep di Google Cloud.
5. Menghitung total biaya kepemilikan (TCO) lingkungan target.
6. Memilih strategi migrasi untuk workload Anda.
7. Memilih alat migrasi Anda.
8. Menentukan rencana dan jadwal migrasi.
9. Memvalidasi 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 database membantu Anda memilih ukuran dan spesifikasi instance database Cloud SQL target yang sesuai dengan sumber untuk kebutuhan performa yang serupa. Perhatikan dengan cermat ukuran dan throughput disk, IOPS, serta jumlah vCPU. Migrasi mungkin mengalami kesulitan atau kegagalan karena ukuran instance database target yang salah. Penentuan ukuran yang salah dapat menyebabkan waktu migrasi yang lama, masalah performa database, error database, dan masalah performa aplikasi. Saat menentukan instance Cloud SQL, perlu diingat bahwa performa disk didasarkan pada ukuran disk dan jumlah vCPU.

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

Membuat inventaris instance Amazon RDS

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

Amazon RDS dan Cloud SQL mungkin tidak memiliki fitur, spesifikasi instance, atau operasi yang serupa. Beberapa fungsi mungkin diimplementasikan 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.

Tolok ukur dapat membantu Anda lebih memahami workload yang akan dimigrasikan dan membantu Anda 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 tolok ukur dijelaskan secara mendetail dalam fase Melakukan pengujian dan validasi dari proses migrasi, tetapi juga berlaku untuk tahap pembuatan inventaris.

Alat untuk penilaian

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

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

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

Selain Migration Center, 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 kegagalan migrasi, dan dapat menunjukkan solusi. migVisor juga dapat merekomendasikan solusi target Google Cloud , termasuk ukuran dan arsitektur awal.

Output penilaian database migVisor memberikan hal berikut:

• Penemuan dan analisis komprehensif terhadap deployment database saat ini.
• Laporan mendetail tentang kompleksitas migrasi, berdasarkan fitur eksklusif yang digunakan oleh database Anda.
• Laporan keuangan dengan detail tentang penghematan biaya pascamigrasi, biaya migrasi, dan anggaran operasional 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 pemakaian server database untuk sementara. Biasanya, beban tambahan ini kurang dari 3%, dan dapat dijalankan di luar jam sibuk.

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 Anda lebih suka menggunakan alat open source, Anda dapat menggunakan skrip pengumpul data dengan (atau sebagai pengganti) alat yang disebutkan. Skrip ini dapat membantu Anda mengumpulkan informasi mendetail (tentang workload, fitur, objek database, dan kode database) serta membangun inventaris database Anda. Selain itu, skrip biasanya memberikan penilaian migrasi database yang mendetail, termasuk estimasi upaya migrasi.

Sebaiknya gunakan alat open source DMA, yang dibuat oleh engineer Google. 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 pembacaan penilaian database, serta memberikan langkah berikutnya dalam perjalanan migrasi.

Mengidentifikasi dan mendokumentasikan cakupan migrasi dan periode nonaktif yang dapat ditoleransi

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

• Apakah database Anda lebih besar dari 5 TB?
• Apakah ada tabel besar di database Anda? Apakah ukurannya lebih besar dari 16 TB?
• Di mana lokasi database (region dan zona), dan seberapa dekat 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 apakah ada data yang sama sekali tidak memerlukan migrasi?

Untuk menentukan cakupan migrasi, tentukan data yang akan disimpan dan yang akan dimigrasikan. Memigrasikan semua database Anda mungkin memerlukan banyak waktu dan upaya. 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. Baseline ini adalah titik referensi yang merepresentasikan status data Anda sebelum dan setelah migrasi serta membantu Anda mengambil 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 periode nonaktif terhadap bisnis? Apakah ada periode aktivitas database yang rendah, yang menyebabkan lebih sedikit pengguna yang terpengaruh oleh periode nonaktif? Jika demikian, berapa lama periode tersebut dan kapan terjadinya? Pertimbangkan untuk hanya memiliki periode nonaktif tulis parsial, sementara permintaan hanya baca masih disajikan.

Menilai proses deployment dan administrasi Anda

Setelah Anda membangun 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 dan membatasi data dalam VPC. Jika Anda berencana menggunakan Autentikasi Windows dengan Cloud SQL untuk SQL Server, Anda harus men-deploy Microsoft AD Terkelola dan terhubung ke infrastruktur Active Directory yang ada.
• Patch dan konfigurasi instance Anda: Alat deployment yang ada mungkin perlu diupdate. Misalnya, Anda mungkin menggunakan setelan konfigurasi kustom di grup parameter Amazon atau grup opsi Amazon. Alat penyediaan Anda mungkin perlu disesuaikan untuk menggunakan Google Cloud Storage atau Secret Manager guna membaca daftar konfigurasi kustom tersebut.
• Mengelola infrastruktur pemantauan dan pemberitahuan: Kategori metrik untuk instance database sumber Amazon Anda memberikan visibilitas selama proses migrasi. Kategori metrik dapat mencakup Amazon CloudWatch, Insight Performa, Enhanced Monitoring, dan daftar proses OS.

Menyelesaikan penilaian

Setelah Anda mem-build inventaris dari lingkungan Amazon RDS, selesaikan aktivitas fase penilaian lainnya seperti yang 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 .
• Hubungkan lingkungan sumber dan lingkungan Google Cloud Anda untuk menyelesaikan migrasi.

Fase perencanaan dan build terdiri dari tugas-tugas berikut:

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

Untuk mengetahui informasi selengkapnya tentang setiap tugas ini, lihat Bermigrasi ke Google Cloud: Merencanakan dan membangun fondasi Anda.

Pemantauan dan pemberitahuan

Gunakan Cloud Monitoring Google Cloud, 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 for SQL Server ke Cloud SQL untuk SQL Server

Untuk memigrasikan instance, lakukan hal berikut:

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

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

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

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

5. Tentukan tugas eksekusi, yang mencakup aktivitas kerja yang mengimplementasikan 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 pengalihan produksi.

10. Membersihkan lingkungan sumber dan mengonfigurasi 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 mengevaluasi dan memilih salah satu strategi migrasi berikut yang paling sesuai dengan kasus penggunaan Anda untuk setiap database:

• Pemeliharaan terjadwal (juga disebut migrasi satu kali atau migrasi big bang): Pendekatan ini ideal jika Anda dapat menanggung periode nonaktif. Opsi ini relatif lebih rendah dalam hal biaya dan kompleksitas, karena beban kerja dan layanan Anda tidak memerlukan banyak refaktorisasi. Namun, jika migrasi gagal sebelum selesai, Anda harus memulai ulang prosesnya, yang akan memperpanjang periode nonaktif.

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

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

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

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

Diagram alur sebelumnya menunjukkan poin-poin keputusan berikut:

• Apakah Anda dapat menoleransi periode nonaktif?

  • Jika tidak, adopsi 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 mencadangkan database, mentransfernya ke Cloud SQL, memulihkannya, lalu mengalihkan aplikasi Anda.

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

Strategi mungkin bervariasi untuk database yang berbeda, meskipun berada di instance yang sama. Kombinasi strategi dapat memberikan hasil yang optimal. Misalnya, migrasikan database kecil dan jarang digunakan menggunakan pendekatan pemeliharaan terjadwal, tetapi gunakan replikasi berkelanjutan untuk database yang sangat penting, yang waktu nonaktifnya mahal.

Biasanya, migrasi dianggap selesai saat peralihan antara instance sumber awal dan instance target terjadi. Setiap replikasi (jika digunakan) dihentikan dan semua pembacaan dan penulisan dilakukan pada instance target. Beralih saat kedua instance sinkron berarti tidak ada kehilangan data dan waktu henti minimal.

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

Meminimalkan periode nonaktif dan dampak terkait migrasi

Konfigurasi migrasi yang tidak menyebabkan periode nonaktif aplikasi memerlukan penyiapan yang lebih rumit. Temukan keseimbangan yang tepat antara kompleksitas penyiapan dan periode nonaktif yang 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 beban tambahan pada instance sumber dan aplikasi Anda mungkin terpengaruh oleh jeda replikasi. Aplikasi (dan pelanggan) mungkin harus menunggu selama periode nonaktif aplikasi, setidaknya selama jeda replikasi berlangsung sebelum menggunakan database baru. Dalam praktiknya, faktor berikut dapat meningkatkan periode nonaktif:

• Kueri database mungkin memerlukan waktu beberapa detik untuk diselesaikan. Pada saat migrasi, kueri yang sedang berlangsung mungkin akan dibatalkan.
• Cache mungkin memerlukan waktu beberapa saat untuk terisi jika database berukuran besar atau memiliki memori buffer yang besar.
• Aplikasi yang dihentikan di sumber dan dimulai ulang di Google Cloud mungkin mengalami sedikit jeda hingga koneksi ke instance database Google Cloud terjalin.
• 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 berdampak minimal pada workload Anda. Misalnya, di luar jam kerja normal, selama akhir pekan, atau masa pemeliharaan terjadwal lainnya.
• Identifikasi bagian workload Anda yang dapat menjalani migrasi dan cut-over produksi pada berbagai tahap. Aplikasi Anda mungkin memiliki komponen berbeda yang dapat diisolasi, disesuaikan, dan dimigrasikan tanpa dampak. Misalnya, frontend, modul CRM, layanan backend, dan platform pelaporan. Modul tersebut dapat memiliki database sendiri yang dapat dijadwalkan untuk migrasi lebih awal atau lebih lambat dalam prosesnya.
• Jika Anda dapat menoleransi beberapa latensi pada database target, pertimbangkan untuk menerapkan migrasi bertahap. Gunakan transfer data inkremental dalam batch, dan sesuaikan sebagian workload Anda agar berfungsi dengan data usang di instance target.
• Pertimbangkan untuk merefaktorisasi aplikasi Anda guna mendukung dampak migrasi yang minimal. Misalnya, sesuaikan aplikasi Anda untuk menulis ke database sumber dan target, sehingga menerapkan replikasi tingkat aplikasi.

Pilih alat migrasi Anda

Faktor terpenting untuk keberhasilan migrasi adalah memilih alat migrasi yang tepat. Setelah strategi migrasi diputuskan, tinjau dan 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 dan versi mesin sumber dan target.
• Lingkungan tempat instance sumber dan instance target berada.
• Ukuran database. Semakin besar database, semakin lama waktu yang diperlukan 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 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. Sistem ini menjalankan ekstraksi data dari database sumber, mentransfer data dengan aman ke database target, dan dapat mengubah data selama pengiriman secara opsional. Dengan kemampuan ini, alat tersebut mengenkapsulasi logika migrasi yang kompleks dan menawarkan kemampuan pemantauan migrasi.

Layanan migrasi terkelola memberikan keuntungan berikut:

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

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

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

• Menawarkan model migrasi yang tangguh dan terbukti: Migrasi database adalah peristiwa yang jarang terjadi, tetapi sangat penting. Untuk menghindari kesalahan pemula dan masalah pada solusi yang ada, Anda dapat menggunakan alat dari pakar berpengalaman, daripada membangun 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 terbaiknya.

Cadangan mesin database bawaan

Jika periode nonaktif yang signifikan dapat diterima, dan database sumber Anda relatif statis, Anda dapat menggunakan kemampuan pencadangan dan pemulihan bawaan mesin database.

Beberapa upaya diperlukan untuk penyiapan dan sinkronisasi, terutama untuk sejumlah besar database, tetapi cadangan mesin database biasanya sudah tersedia dan mudah digunakan. Pendekatan ini cocok untuk ukuran database apa pun, dan biasanya lebih efektif daripada alat lain untuk instance besar.

Cadangan mesin database memiliki batasan umum berikut:

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

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

• Untuk pencadangan database yang lebih besar dari 5 TB, gunakan pencadangan bergaris (pencadangan beberapa file).
• Saat menggunakan pencadangan bergaris, Anda tidak dapat mencadangkan atau memulihkan dari lebih dari 10 file cadangan secara bersamaan.
• Anda harus mencadangkan ke bucket Amazon S3 di region Amazon yang sama dengan instance database sumber Anda.
• Cadangan tidak menyertakan login, izin, dan peran server SQL Server, karena berada di tingkat instance. Untuk mentransfer jenis data ini dari instance sumber ke instance target, gunakan skrip PowerShell atau alat seperti DBAtools.

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 mungkin memberikan lebih banyak kontrol dan fleksibilitas dalam proses migrasi pemeliharaan terjadwal Anda.

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

• Lakukan transformasi, pemeriksaan, atau operasi lain pada data Anda selama migrasi. Misalnya, validasi, agregasi, atau normalisasi dan denormalisasi pada data sumber Anda.
• Pilih struktur yang ingin Anda migrasikan dan yang ingin Anda tinggalkan. Anda dapat memutuskan untuk mengekstrak hanya sebagian tabel dalam file datar untuk diimpor.
• Pilih untuk memfilter data berdasarkan domain, sumber, usia, atau kriteria kustom lainnya. Misalnya, Anda dapat mengecualikan data yang mencapai batas usia, dan menyimpannya dalam file atau cadangan akhir database sumber, sebelum migrasi.
• Lakukan refaktorisasi struktur database Anda, dan sinkronkan periode nonaktif yang terjadi dengan periode nonaktif migrasi.
• Gabungkan beberapa instance atau database menjadi satu instance atau database, untuk mengurangi biaya operasional dan memudahkan masalah skalabilitas Anda. Misalnya, Anda mungkin ingin mengubah pendekatan dari memiliki satu instance, database, atau skema per pelanggan menjadi struktur database tunggal yang dioptimalkan untuk multi-tenancy.

Pendekatan lainnya mencakup hal berikut:

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

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

• Gunakan Wizard Impor dan Ekspor SQL Server dari Microsoft: Alat ini menggunakan SQL Server Integration Services (SSIS), dan memungkinkan Anda mengimpor data dari berbagai sumber, seperti mesin database lain atau file datar.

• Gunakan SQL Server Generate and Publish Scripts Wizard dan utilitas bcp: Alat ini adalah bagian dari Microsoft SQL Server Management Studio.

  • Dengan pendekatan ini, Anda dapat membuat skrip untuk seluruh skema database atau hanya sebagian saja.
  • Utilitas bcp memungkinkan Anda membuat skrip data dan mengekspornya ke dalam file.

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

  • Dengan pendekatan ini, Anda memulihkan cadangan SQL Server dari instance RDS ke instance mandiri SQL Server lainnya di Compute Engine. Kemudian, gunakan replikasi snapshot untuk bermigrasi ke Cloud SQL untuk SQL Server.
  • Pembuatan snapshot mempertahankan kunci pada tabel sumber, yang dapat memengaruhi workload Anda.
  • Replikasi snapshot mungkin menimbulkan beban tambahan pada server Amazon RDS Anda.
  • Namun, Anda dapat memilih objek mana yang akan dimigrasikan atau direplikasi, sehingga 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 alur dengan pertanyaan yang dapat membantu Anda memilih alat migrasi untuk satu database, saat Anda menggunakan strategi migrasi replikasi berkelanjutan:

Diagram alir sebelumnya menunjukkan poin-poin keputusan berikut:

• Apakah Anda lebih memilih menggunakan layanan migrasi terkelola?

  • Jika ya, lanjutkan ke keputusan berikutnya. Jika Anda dapat menoleransi waktu nonaktif minimal dan tidak memerlukan transformasi data atau sinkronisasi real-time, sebaiknya gunakan Database Migration Service. Jika tidak, pelajari opsi pihak ketiga.
  • Jika tidak, lanjutkan ke keputusan berikutnya. Jika replikasi bawaan mesin database didukung, sebaiknya gunakan replikasi bawaan. Jika tidak, sebaiknya pelajari opsi migrasi lainnya.

• Dapatkah Anda menanggung periode nonaktif minimal, dan bermigrasi tanpa transformasi data 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 menjelaskan alat yang dapat digunakan untuk migrasi replikasi berkelanjutan, beserta batasan dan praktik terbaiknya.

Database Migration Service untuk migrasi replikasi berkelanjutan

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

Database Migration Service adalah alat yang hemat biaya dan mudah digunakan. Sebaiknya gunakan Database Migration Service untuk situasi dengan kondisi berikut:

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

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

• Durasi periode nonaktif bergantung pada frekuensi pencadangan log transaksi Anda.
• Cadangan tidak menyertakan login, izin, atau peran server SQL Server, karena berada di tingkat instance. Buat skrip dari instance sumber, lalu transfer ke instance target menggunakan skrip PowerShell atau alat seperti DBAtools.

Untuk mengetahui daftar lengkap batasan, lihat Batasan umum.

Replikasi bawaan mesin database

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

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

Pendekatan lain untuk migrasi replikasi berkelanjutan

Pendekatan migrasi replikasi berkelanjutan lainnya mencakup hal berikut:

• Lakukan pemfaktoran ulang pada aplikasi Anda untuk melakukan Y (menulis dan membaca) atau menggunakan microservice akses data.

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

• Terapkan fungsi yang secara berkala mengkueri data di instance sumber Anda, memfilter hanya data baru, dan menulis data ke file CSV, JSON, atau Parquet.

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

Alat pihak ketiga untuk migrasi replikasi berkelanjutan

Dalam beberapa kasus, mungkin lebih baik menggunakan satu alat pihak ketiga untuk sebagian besar mesin database. Kasus seperti ini mungkin terjadi jika Anda lebih memilih untuk menggunakan layanan migrasi terkelola dan Anda perlu memastikan bahwa database target selalu disinkronkan hampir real-time dengan sumbernya, atau jika Anda memerlukan transformasi yang lebih kompleks seperti pembersihan, restrukturisasi, 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 dalam memori end-to-end untuk mengumpulkan, memfilter, mentransformasi, memperkaya, menggabungkan, menganalisis, dan mengirimkan data secara real time:

• Kelebihan:

  • Menangani volume data yang besar dan migrasi yang kompleks.
  • Change data capture 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 transaksional yang berat.
  • Pengiriman tepat satu kali.

• Kekurangan:

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

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

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

• Kelebihan:

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

• Kekurangan:

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

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

Fivetran adalah platform pergerakan data otomatis untuk memindahkan data keluar dan di seluruh platform data cloud.

• Kelebihan:

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

• Kekurangan:

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

Menentukan rencana dan jadwal migrasi

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

Menentukan cakupan migrasi akan mengungkapkan tugas 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 kelangsungan bisnis yang ada.

Sebaiknya dokumentasi perencanaan migrasi Anda menyertakan dokumen berikut:

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

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

TDD

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

• Persyaratan dan tingkat kekritisan 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 pengelolaan project umum yang menentukan individu atau grup yang bertanggung jawab atas tugas dan hasil kerja dalam project migrasi.

Linimasa

Siapkan linimasa untuk setiap database yang perlu dimigrasikan. Sertakan semua tugas pekerjaan yang harus dilakukan, serta tentukan tanggal mulai dan perkiraan tanggal akhir.

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

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

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

Rencana T-Minus mungkin terlihat seperti berikut:

Tanggal	Fase	Kategori	Tasks	Peran	T-minus	Status
1/11/2023	Pra-migrasi	Penilaian	Membuat laporan penilaian	Tim Discovery	-21	Selesai
7/11/2023	Pra-migrasi	Persiapan target	Mendesain 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	Membangun profil koneksi	Cloud migration engineer	-3	Selesai
19/11/2023	Migrasi	Menyiapkan DMS	Membangun 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	Melakukan migrasi sistem DMS	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 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	Menghapus akun pengguna DMS	Tim keamanan	4	Belum dimulai

Beberapa migrasi database

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

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

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

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

Menentukan tugas persiapan

Tugas persiapan adalah semua aktivitas yang perlu Anda selesaikan untuk memenuhi prasyarat migrasi. Jika Anda tidak menyelesaikan tugas persiapan, migrasi tidak dapat dilakukan atau database yang dimigrasikan mungkin tidak dapat digunakan sebagai hasilnya.

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 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 untuk 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 pada port yang diperlukan.

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

• Untuk replikasi berkelanjutan (perubahan streaming melalui CDC), Anda harus menggunakan instance RDS lengkap dan bukan replika baca, dengan CDC diaktifkan. Untuk mengetahui detailnya, lihat Menggunakan change data capture dengan SQL Server.

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

Persiapan dan prasyarat database sumber

• Pastikan database sumber memiliki penyimpanan buffer dan memori yang tersedia selama operasi migrasi. Misalnya, jika Anda menggunakan file cadangan log transaksi, pantau penggunaan penyimpanan dan pastikan Anda memiliki ruang penyimpanan buffer tambahan.
• Dokumentasikan setelan parameter database Anda, dan terapkan pada instance target sebelum melakukan pengujian dan validasi migrasi.

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

  • Ukur ukuran data Anda, serta performa workload Anda. Berapa lama waktu yang diperlukan untuk kueri atau transaksi penting, rata-rata? Berapa lama selama waktu puncak?
  • Dokumentasikan pengukuran dasar untuk perbandingan nanti, guna membantu Anda memutuskan apakah fidelitas migrasi database Anda memuaskan. Tentukan apakah Anda dapat mengalihkan workload produksi dan menonaktifkan lingkungan sumber, atau apakah Anda masih membutuhkannya untuk tujuan penggantian.

Penyiapan Cloud SQL

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

Pastikan tujuan tersebut sesuai. Perlu diperhatikan bahwa opsi konfigurasi Amazon RDS mungkin berbeda dengan Cloud SQL. Jika 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 properti dan persyaratan tersebut tidak dapat diubah nanti tanpa membuatnya ulang.

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

• Melakukan 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 sama untuk memastikan kemampuan mesin yang sama.

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

• Tinjau flag konfigurasi khusus mesin database dan bandingkan nilai instance sumber dan instance targetnya. Pastikan Anda memahami dampaknya dan apakah keduanya harus sama atau tidak. Misalnya, sebaiknya bandingkan nilai dalam tampilan sys.configurations di database sumber Anda dengan nilai di instance Cloud SQL. Perlu diperhatikan bahwa tidak semua flag harus sama dan tidak semua perubahan flag diizinkan pada 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 bermigrasi, atau menggunakan alat migrasi Database Migration Service, Anda harus membuat bucket Cloud Storage. Bucket menyimpan file cadangan database dan log transaksi. Untuk mengetahui informasi selengkapnya tentang cara menggunakan Database Migration Service, lihat Menyimpan file cadangan di bucket Cloud Storage.

Jika menggunakan replikasi, Anda harus memastikan bahwa replika Cloud SQL memiliki akses ke database utama Anda. Hal ini dapat dilakukan melalui opsi konektivitas yang terdokumentasi.

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

Untuk sebagian besar alat pihak ketiga, Anda perlu menyediakan resource khusus migrasi. Misalnya, untuk Striim, Anda harus menggunakan Google Cloud Marketplace untuk memulai. Kemudian, untuk menyiapkan lingkungan migrasi di Striim, Anda dapat menggunakan Flow Designer untuk membuat dan mengubah aplikasi, atau Anda dapat memilih template yang sudah ada. Aplikasi juga dapat di-coding menggunakan bahasa pemrograman Tungsten Query Language (TQL). Dengan menggunakan dasbor validasi data, Anda bisa mendapatkan representasi visual dari data yang ditangani oleh aplikasi Striim Anda.

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

Menentukan tugas eksekusi

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

Cadangan mesin database bawaan

Untuk mengetahui informasi dan petunjuk selengkapnya terkait pencadangan khusus database, lihat Mengimpor data dari file BAK ke Cloud SQL untuk SQL Server dan Mengekspor data dari RDS untuk SQL Server. Untuk mengetahui informasi selengkapnya tentang cara mengotomatiskan upload file log transaksi, lihat Menjadwalkan 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 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 baik. Pilih waktu saat workload Anda dapat mengalami periode nonaktif singkat untuk migrasi dan cut-over produksi.

Proses migrasi biasanya melibatkan tugas-tugas berikut:

• Ekspor pencadangan penuh database sumber, lalu upload ke bucket Cloud Storage.
• Buat cadangan file log transaksi, lalu upload ke bucket Cloud Storage yang sama. Untuk mengetahui informasi selengkapnya tentang cara mengotomatiskan proses ini, lihat Menjadwalkan upload file log transaksi untuk Amazon RDS.
• Di Database Migration Service, Anda memantau pemrosesan cadangan log transaksi.
• Hentikan penulisan 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 akan diputuskan koneksinya dari instance database sumber, lalu dipromosikan ke instance utama.
• Deploy aplikasi yang mengarah ke database target baru.

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

Replikasi bawaan mesin database

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

Cloud SQL mendukung replikasi untuk SQL Server. Untuk mengetahui 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 apa pun untuk alat pihak ketiga yang telah Anda pilih. Misalnya, jika Anda memutuskan untuk menggunakan Striim, Anda perlu membuat aplikasi di namespace, dan mengonfigurasi pembaca CDC untuk terhubung ke instance Amazon. Untuk mengetahui detailnya, lihat Penyiapan SQL Server dalam dokumentasi Striim.

Menentukan skenario penggantian

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

Fallback mungkin memerlukan upaya yang signifikan. Sebagai praktik terbaik, jangan lakukan cut-over 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 batasi waktu semua tugas eksekusi migrasi Anda. Melakukan uji coba migrasi membantu mengumpulkan informasi tentang perkiraan waktu untuk setiap tugas. Misalnya, untuk migrasi pemeliharaan terjadwal, Anda dapat membayar periode nonaktif yang diwakili oleh periode migrasi sistem. Namun, Anda perlu merencanakan tindakan berikutnya jika tugas migrasi satu kali atau pemulihan cadangan gagal di tengah jalan. Bergantung pada berapa banyak waktu yang telah berlalu dari waktu nonaktif yang direncanakan, Anda mungkin harus menunda migrasi jika tugas migrasi tidak selesai dalam jumlah waktu yang diharapkan.

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

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

Meskipun penggantian adalah upaya terakhir, dan sebagian besar migrasi database tidak 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 melakukan fallback atau jika Anda tidak memerlukan transaksi yang di-commit pada sistem target baru.

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

Membalikkan replikasi

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

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

Replikasi maju

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

Gunakan pendekatan ini jika Anda ingin selalu dilindungi oleh penggantian atau saat Anda harus menghapus database sumber awal segera setelah cut-over produksi.

Operasi tulis duplikat

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

Aplikasi Anda menulis ke instance database sumber dan target awal, sehingga Anda dapat melakukan cut-over produksi secara bertahap hingga Anda hanya menggunakan instance database target. Jika ada masalah, Anda dapat menghubungkan kembali aplikasi ke sumber awal tanpa periode nonaktif. Anda dapat menghapus sumber awal dan mekanisme penulisan duplikat jika Anda menganggap migrasi telah dilakukan tanpa masalah.

Sebaiknya gunakan pendekatan ini jika tidak boleh ada periode nonaktif migrasi, memiliki penggantian yang andal, dan jika Anda memiliki waktu dan resource untuk melakukan refaktorisasi 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 ada setelah dialihkan untuk menggunakan instance target baru.

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

• Data yang akan dimigrasikan. Untuk beberapa workload, Anda mungkin tidak perlu memigrasikan semua data. Anda mungkin tidak ingin memigrasikan data yang sudah 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, yang mana 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 pemrosesan masih dalam ekspektasi yang ditentukan.

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

Dalam proses tolok ukur, Anda menerapkan urutan operasi yang mirip dengan produksi ke instance database. Selama waktu ini, Anda menangkap dan memproses metrik untuk mengukur dan membandingkan performa relatif sistem sumber dan target.

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

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

• HammerDB: alat pengujian beban dan tolok ukur database open source. HammerDB mendukung workload transaksional dan analisis yang kompleks, berdasarkan standar industri, di beberapa mesin database (baik TPROC-C maupun TPROC-H). HammerDB memiliki dokumentasi yang mendetail dan komunitas pengguna yang luas. Anda dapat membagikan dan membandingkan hasil di beberapa mesin database dan konfigurasi penyimpanan. Untuk mengetahui informasi selengkapnya, lihat Pengujian beban SQL Server menggunakan HammerDB dan Tolok ukur performa Amazon RDS SQL Server menggunakan HammerDB.
• Alat Benchmark DBT2: benchmarking khusus untuk MySQL. Serangkaian kit workload database meniru aplikasi untuk perusahaan yang memiliki gudang dan melibatkan campuran transaksi baca dan tulis. Gunakan alat ini jika Anda ingin menggunakan uji beban pemrosesan transaksi online (OLTP) 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 uji terkadang bisa lambat, bergantung pada ukuran dan kompleksitas database. Sebaiknya gunakan alat ini jika kesederhanaan diperlukan.
• DbFit: framework pengujian database open source yang mendukung pengembangan kode berbasis pengujian dan pengujian otomatis. Framework ini menggunakan sintaksis dasar untuk membuat kasus pengujian dan menampilkan pengujian berbasis data, kontrol versi, dan pelaporan hasil pengujian. Namun, dukungan untuk kueri dan transaksi yang kompleks terbatas dan tidak memiliki dukungan komunitas yang besar atau dokumentasi yang ekstensif, dibandingkan dengan alat lainnya. Sebaiknya gunakan alat ini jika kueri Anda tidak kompleks dan Anda ingin melakukan pengujian otomatis serta mengintegrasikannya dengan proses continuous integration dan delivery.

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

Pengujian data dapat dilakukan pada sebagian kecil database yang akan dimigrasikan atau seluruh set. Bergantung pada jumlah total database dan alat yang digunakan untuk menerapkan migrasinya, Anda dapat memutuskan untuk mengadopsi pendekatan berbasis risiko. Dengan pendekatan ini, Anda melakukan validasi data pada subset 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:

• Membandingkan skema sumber dan target. Periksa 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 beralih menggunakan database target (data yang dimigrasikan dibaca melalui aplikasi).
• Lakukan pengujian integrasi antara aplikasi yang dialihkan dan database target dengan menguji berbagai kasus penggunaan. Pengujian ini mencakup pembacaan dan penulisan data ke database target melalui aplikasi sehingga workload 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 pada sistem sumber mana pun. Suite kasus pengujian otomatis disesuaikan untuk dijalankan pada aplikasi yang dialihkan.

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

Data Validation Tool

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

DVT dapat membantu menyederhanakan proses validasi data dengan menawarkan fungsi validasi multi-level 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. Layanan ini juga dapat diintegrasikan dengan Cloud Run Functions dan Cloud Run untuk pemicuan dan orkestrasi berbasis peristiwa.

DVT mendukung jenis validasi berikut:

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

Untuk mengetahui informasi selengkapnya tentang DVT, lihat repositori Git dan Validasi data 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 informasi terbaru secara berkala 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 roll back.
• Buat keputusan "lanjut atau tidak" untuk setiap langkah rencana migrasi dan cut-over.
• Pertimbangkan tindakan rollback atau skenario alternatif untuk setiap langkah.

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

Melakukan cut-over produksi

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

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

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

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

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

Ikuti praktik terbaik untuk peralihan produksi Anda:

• Pantau aplikasi Anda yang berfungsi dengan database target setelah cut-over.
• Tentukan jangka waktu pemantauan untuk mempertimbangkan apakah Anda perlu menerapkan rencana penggantian atau tidak.
• Perhatikan bahwa instance Cloud SQL atau AlloyDB untuk PostgreSQL Anda mungkin perlu dimulai ulang jika Anda mengubah beberapa flag database.
• 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 migrasi sistem selesai, Anda dapat menghapus database sumber. Sebaiknya lakukan tindakan penting berikut sebelum pembersihan instance sumber:

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

• Kumpulkan setelan parameter database instance sumber Anda. Atau, periksa apakah 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 statistik di instance target. Jika statistiknya berbeda, akan sulit untuk membandingkan performa instance sumber dan instance target.

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

Sebagai praktik terbaik untuk terus mengupdate instance sumber setelah cut-over, replikasikan penulisan yang dilakukan pada instance Cloud SQL target kembali ke database sumber. Jika perlu melakukan roll back, Anda dapat beralih kembali ke instance sumber lama dengan kehilangan data yang minimal.

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

• Konfigurasikan masa pemeliharaan pada instance utama untuk mengontrol waktu saat update yang mengganggu dapat terjadi.
• Konfigurasikan penyimpanan pada instance sehingga Anda memiliki minimal 20% kapasitas yang tersedia untuk mengakomodasi operasi pemeliharaan database penting apa pun yang mungkin dijalankan Cloud SQL. Untuk menerima pemberitahuan jika kapasitas disk yang tersedia kurang dari 20%, buat kebijakan pemberitahuan berbasis metrik untuk 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 sampai lingkungan target Anda memenuhi persyaratan pengoptimalan. Langkah-langkah setiap iterasi adalah sebagai berikut:

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

Anda mengulangi urutan ini sampai Anda mencapai sasaran pengoptimalan.

Untuk mengetahui informasi selengkapnya tentang cara mengoptimalkan lingkungan Google Cloud Anda, lihat Bermigrasi ke Google Cloud: Mengoptimalkan lingkungan Anda dan Google Cloud Well-Architected Framework: Pengoptimalan performa.

Menetapkan persyaratan pengoptimalan

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

Meningkatkan keandalan dan ketersediaan database Anda

Dengan Cloud SQL, Anda dapat menerapkan strategi ketersediaan tinggi dan disaster recovery yang selaras dengan batas waktu pemulihan (RTO) dan toleransi durasi kehilangan data (RPO) Anda. Untuk meningkatkan keandalan dan ketersediaan, pertimbangkan hal berikut:

• Dalam kasus workload read-heavy, tambahkan replika baca untuk memindahkan traffic dari instance utama.
• Untuk workload sangat penting, gunakan konfigurasi ketersediaan tinggi, replika untuk failover regional, dan konfigurasi disaster recovery yang andal.
• Untuk workload yang kurang penting, pencadangan otomatis dan on-demand sudah cukup.
• Untuk mencegah penghapusan instance yang tidak disengaja, gunakan perlindungan penghapusan instance.
• Aktifkan pemulihan point-in-time (PITR) untuk instance Cloud SQL untuk SQL Server Anda.
• Otomatiskan pencadangan database SQL menggunakan rencana pemeliharaan.

Meningkatkan efektivitas biaya infrastruktur database Anda

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

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

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

• Identifikasi kemungkinan resource yang terlalu tinggi:

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

• Identifikasi instance yang tidak memerlukan konfigurasi ketersediaan tinggi atau disaster recovery, dan hapus instance tersebut dari infrastruktur Anda.

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

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

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

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

• Gunakan Active Assist untuk mendapatkan insight dan rekomendasi biaya.

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

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

• Migrasikan ke SQL Server Standard Edition, jika SLA sesuai dengan kebutuhan Anda.
• Nonaktifkan multithreading simultan (SMT) dan tambahkan 25% lebih banyak core. Core tambahan mungkin mengimbangi dampak performa apa pun akibat menonaktifkan SMT. Strategi ini dapat membantu mengurangi biaya lisensi, tetapi dapat memengaruhi performa instance Anda. Sebaiknya lakukan pengujian beban pada instance Anda untuk memastikan SLA Anda tidak terpengaruh.
• Pertimbangkan migrasi heterogen dari Cloud SQL untuk SQL Server ke Cloud SQL untuk PostgreSQL atau AlloyDB untuk PostgreSQL, bergantung pada workload Anda.

Meningkatkan performa infrastruktur database Anda

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

• Jika Anda memiliki tabel database dalam jumlah besar, tabel tersebut dapat memengaruhi performa dan ketersediaan instance, serta menyebabkan instance kehilangan cakupan SLA.

• Pastikan instance Anda tidak dibatasi pada memori atau CPU.

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

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

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

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

• Mencegah fragmentasi data dan indeks. Tetapkan jadwal untuk membangun ulang indeks di SQL Server, berdasarkan seberapa sering data Anda berubah.

• Ubah setelan khusus mesin SQL Server agar dapat berfungsi secara optimal untuk Cloud SQL.

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

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

• Pertimbangkan untuk melakukan operasi ETL pada replika baca, karena operasi tersebut dapat memengaruhi cache instance Anda.

Untuk mengetahui informasi selengkapnya tentang cara meningkatkan performa, lihat Performa di "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 instance database bisa jadi sulit dan memakan waktu. Oleh karena itu, tempat terpusat yang memungkinkan 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 hasil pengukuran terkait layanan Anda dan resource Google Cloud 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 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 bagaimana permintaan menyebar di seluruh aplikasi Anda.

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

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

• Amati status database Anda untuk membantu meningkatkan performa lingkungan, dan memecahkan masalah yang mungkin terjadi.

Praktik terbaik dan panduan operasional Cloud SQL umum

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

Berikut beberapa rekomendasi umum Cloud SQL yang penting:

• 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% kapasitas yang tersedia untuk mengakomodasi operasi pemeliharaan database penting apa pun yang mungkin dijalankan 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 tinggi.

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

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

Melakukan dan menjadwalkan operasi pemeliharaan database: Defragmentasi indeks, pembaruan statistik, analisis vacuum, dan pengindeksan ulang tabel yang sering diperbarui. Periksa apakah dan kapan operasi pemeliharaan ini terakhir 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 update 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 tepat untuk jenis workload? Selidiki kueri lambat dan rencana eksekusinya. Apakah kueri tersebut menggunakan indeks yang tersedia? Periksa pemindaian indeks, kunci, dan tunggu di resource lain. Pertimbangkan untuk menambahkan indeks guna mendukung kueri penting Anda. Menghilangkan indeks dan kunci asing yang tidak penting. Pertimbangkan untuk menulis ulang kueri dan gabungan yang kompleks. Waktu yang diperlukan untuk menyelesaikan masalah Anda bergantung pada pengalaman dan ketersediaan tim Anda, dan dapat berkisar dari jam hingga hari.

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

Re-arsitektur database: Pertimbangkan untuk mempartisi dan mengindeks database. Operasi ini memerlukan upaya yang jauh lebih besar daripada penyesuaian dan pengoptimalan database, serta 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 peningkatan skala vertikal. Namun, model data yang tepat adalah perbaikan jangka panjang. Pertimbangkan untuk mempartisi 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 melakukan penskalaan horizontal pada operasi tulis dengan melakukan sharding pada database. Sharding adalah operasi yang rumit dan melibatkan penataan ulang arsitektur database dan aplikasi Anda 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. Dengan opsi ini, Anda dapat menskalakan operasi tulis dan baca secara horizontal. Namun, hal ini meningkatkan kompleksitas workload database dan aplikasi Anda. Hal ini juga dapat menyebabkan shard yang tidak seimbang yang disebut hotspot, yang akan lebih besar daripada manfaat sharding.

Khusus untuk Cloud SQL untuk SQL Server, pertimbangkan praktik terbaik berikut:

• Untuk memperbarui setelan SQL Server agar performanya optimal dengan Cloud SQL, lihat setelan SQL Server.
• Tentukan kapasitas subsistem I/O sebelum men-deploy SQL Server.

• Jika Anda memiliki instance besar, bagi menjadi instance yang lebih kecil, jika memungkinkan:

  • Disk berukuran 4 TB atau lebih memberikan throughput dan IOPS yang lebih besar.
  • vCPU yang lebih tinggi memberikan IOPS dan throughput yang lebih tinggi. Saat menggunakan vCPU yang lebih tinggi, pantau waktu tunggu database untuk mengetahui adanya paralelisme yang juga dapat meningkat.

• Nonaktifkan SMT, jika performa menurun dalam beberapa situasi. Misalnya, jika aplikasi mengeksekusi thread yang menjadi bottleneck dan arsitektur CPU tidak menangani hal ini secara efektif.

• Tetapkan jadwal untuk mengatur ulang atau membangun ulang indeks, bergantung pada seberapa sering data Anda berubah.

• Tetapkan faktor pengisian yang sesuai untuk mengurangi fragmentasi. Pantau SQL Server untuk menemukan indeks yang hilang yang dapat menawarkan performa lebih baik.

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

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

• Pastikan Anda memahami persyaratan lokalitas, tata urutan, serta sensitivitas huruf besar/kecil dan aksen dari data yang Anda kerjakan. Saat memilih kolasi dari server, database, kolom, atau ekspresi, Anda menetapkan karakteristik tertentu ke data tersebut.

• Hash join rekursif atau hash bailout menyebabkan penurunan performa di server Anda. Jika Anda melihat banyak peristiwa hash warning dalam trace, update statistik pada kolom yang digabungkan. Untuk informasi selengkapnya, lihat Class Peristiwa Peringatan Hash.

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

Langkah berikutnya

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

Kontributor

Penulis:

• Alex Cârciu | Solutions Architect
• Marco Ferrari | Cloud Solutions Architect

Kontributor lainnya:

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