Migrasi database: Konsep dan prinsip (Bagian 1)

Last reviewed 2024-03-07 UTC

Dokumen ini memperkenalkan konsep, prinsip, terminologi dan arsitektur migrasi database periode nonaktif hampir nol untuk arsitek cloud yang memigrasikan database ke Google Cloud dari lingkungan lokal atau lingkungan cloud lainnya.

Dokumen ini adalah bagian 1 dari dua bagian. Bagian 2 membahas cara menyiapkan dan menjalankan proses migrasi, termasuk skenario kegagalan.

Migrasi database adalah proses migrasi data menggunakan layanan migrasi database dari satu atau lebih database sumber ke satu atau lebih database target. Setelah migrasi selesai, semua set data di database sumber akan tetap ada, meskipun ada kemungkinan penataan ulang di database target. Klien yang mengakses database sumber akan dialihkan ke database target dan database sumber dinonaktifkan.

Diagram berikut mengilustrasikan proses migrasi database ini.

Alur data dari database sumber ke database target melalui layanan migrasi.

Dokumen ini menjelaskan migrasi database dari sudut pandang arsitektur:

  • Layanan dan teknologi yang terlibat dalam migrasi database.
  • Perbedaan antara migrasi database homogen dan migrasi database heterogen.
  • Kerugian dan pemilihan toleransi periode nonaktif migrasi.
  • Penyiapan arsitektur yang mendukung penggantian jika terjadi kesalahan yang tidak terduga selama migrasi.

Dokumen ini tidak menjelaskan cara Anda menyiapkan teknologi migrasi database tertentu. Sebaliknya, bagian ini memperkenalkan persyaratan dasar, konseptual dan prinsip di migrasi database.

Arsitektur

Diagram berikut menunjukan arsitektur migrasi database umum.

Layanan arsitektur migrasi yang mengakses database sumber dan database target.

Migrasi database berjalan di Google Cloud dan mengakses database sumber dan database target. Dua varian yang ditampilkan: (a) menunjukkan migrasi dari database sumber di pusat data lokal atau cloud jarak jauh ke database terkelola seperti Spanner; (b) menunjukkan migrasi ke database di Compute Engine.

Meskipun database target memiliki jenis (terkelola dan tidak terkelola) dan penyiapan yang berbeda, arsitektur dan konfigurasi migrasi database sama untuk kedua kasus tersebut.

Terminologi

Istilah migrasi data yang paling penting untuk dokumen ini didefinisikan sebagai berikut:

database sumber: Database yang berisi data yang akan dimigrasikan ke satu atau lebih database target.

database target: Database yang menerima data yang dimigrasikan dari satu atau lebih database sumber.

migrasi database: Migrasi data dari database sumber ke database target dengan tujuan menonaktifkan sistem database sumber setelah migrasi selesai. Seluruh set data, atau subset dimigrasikan.

migrasi homogen: Migrasi dari database sumber ke database target karena database sumber dan target memiliki sistem pengelolaan yang sama dari penyedia yang sama.

migrasi heterogen: Migrasi dari database sumber ke database target karena database sumber dan target memiliki sistem pengelolaan database berbeda dari penyedia yang berbeda.

sistem migrasi database: Sistem atau layanan software yang terhubung ke database sumber dan database target serta menjalankan migrasi data dari database sumber ke database target.

proses migrasi data: Proses yang dikonfigurasi atau diterapkan, dijalankan oleh sistem migrasi data untuk mentransfer data dari database sumber ke target, mungkin mentransformasi data selama transfer tersebut.

replikasi database: Transfer data berkelanjutan dari database sumber ke database target tanpa tujuan menonaktifkan database sumber. Replikasi database (yang terkadang disebut streaming database) adalah proses yang sedang berlangsung.

Klasifikasi migrasi database

Ada beberapa jenis migrasi database yang termasuk dalam kelas yang berbeda. Bagian ini menjelaskan kriteria yang menentukan kelas tersebut.

Replikasi versus migrasi

Dalam migrasi database, Anda memindahkan data dari database sumber ke database target. Setelah data selesai dimigrasikan, hapus database sumber dan alihkan akses klien ke database target. Terkadang Anda menyimpan database sumber sebagai langkah pengganti, jika Anda mengalami masalah yang tidak terduga dengan database target. Namun, setelah database target beroperasi dengan andal, Anda akan menghapus database sumber pada akhirnya.

Sebaliknya, dengan replikasi database, Anda mentransfer data secara terus-menerus dari database sumber ke database target tanpa menghapus database sumber. Terkadang replikasi database disebut sebagai streaming database. Meskipun terdapat penentuan waktu mulai, biasanya tidak ada penentuan waktu selesai. Replikasi mungkin dihentikan atau menjadi migrasi

Dokumen ini hanya membahas migrasi database

Migrasi sebagian versus selesai

Migrasi database dipahami sebagai transfer data yang lengkap dan konsisten. Anda menentukan set data awal yang akan ditransfer sebagai database lengkap atau database sebagian (subset data dalam database), serta setiap perubahan yang di-commit ke sistem database sumber setelahnya.

Migrasi heterogen versus migrasi homogen

Migrasi database homogen adalah migrasi antara database sumber dan target dari teknologi database yang sama, contohnya, migrasi dari database MYSQL ke database MYSQL, atau dari database Oracle® ke database Oracle®. Migrasi homogen juga mencakup migrasi antara sistem database yang dihosting sendiri seperti PostgreSQL ke versi terkelolanya seperti Cloud SQL untuk PostgreSQL atau AlloyDB untuk PostgreSQL.

Dalam migrasi database homogen, skema untuk database sumber dan target cenderung identik. Jika skemanya berbeda, data dari database sumber harus diubah selama migrasi.

Migrasi database heterogen adalah migrasi antara database sumber dan target dari teknologi database yang berbeda, contoh, dari database Oracle ke ke Database Spanner. Migrasi database heterogen dapat terjadi antara model data yang sama (contoh, dari relasional ke relasional), atau model data yang berbeda (contoh, dari relasional ke nilai kunci).

Migrasi antara berbagai teknologi database tidak perlu melibatkan model data yang berbeda. Contohnya, Oracle, MySQL, PostgreSQL, dan Spanner mendukung model data relasional. Namun, database multi-model seperti Oracle, MySQL, or PostgreSQL mendukung model data yang berbeda. Data yang disimpan sebagai dokumen JSON di database multi-model dapat dimigrasikan ke MongoDB dengan sedikit atau tanpa memerlukan transformasi, karena kesamaan model data di database sumber dan database target.

Meskipun perbedaan antara migrasi homogen dan migrasi heterogen berdasarkan pada teknologi database, alternatif kategorisasi didasarkan pada model data yang terlibat. Contoh, migrasi dari database Oracle ke Spanner dianggap homogen saat keduanya menggunakan model data relasional; migrasi dianggap heterogen jika, contoh, data yang disimpan sebagai objek JSON di Oracle dimigrasikan ke model relasional di Spanner.

Mengategorikan migrasi berdasarkan model data lebih akurat dalam menyatakan kompleksitas dan upaya yang diperlukan untuk memigrasikan data, dibandingkan kategorisasi berdasarkan sistem database yang terlibat. Namun,karena kategorisasi yang biasa digunakan pada industri berdasarkan sistem database yang terlibat, bagian lainnya berdasarkan perbedaan tersebut.

Periode nonaktif migrasi: nol versus minimal versus signifikan.

Setelah Anda berhasil memigrasikan set data dari database sumber ke target, alihkan akses klien ke database target dan hapus database sumber.

Mengalihkan klien dari database sumber ke database target membutuhkan beberapa proses:

  • Untuk melanjutkan pemrosesan, klien harus menutup koneksi yang ada ke database sumber dan membuat koneksi baru ke database target. Idealnya, penutupan koneksi berjalan dengan tuntas, yang berarti Anda tidak perlu membatalkan transaksi yang sedang berlangsung.
  • Setelah menutup koneksi di database sumber, Anda harus memigrasikan sisa perubahan dari database sumber ke database target (disebut draining) untuk memastikan semua perubahan disimpan.
  • Anda mungkin perlu menguji database target untuk memastikan database berfungsi serta klien berfungsi dan beroperasi sesuai tujuan tingkat layanan (SLO) yang ditentukan.

Dalam migrasi, klien tidak mungkin mencapai periode nonaktif nol sepenuhnya, adakalanya klien tidak dapat memproses permintaan. Namun, Anda dapat meminimalkan durasi klien yang tidak dapat menerima proses permintaan dalam beberapa cara (periode nonaktif hampir nol):

  • Anda dapat memulai klien pengujian dalam mode hanya baca terhadap database target jauh sebelum mengalihkan klien. Dengan pendekatan ini, pengujian berjalan sekaligus dengan migrasi.
  • Anda dapat mengonfigurasi jumlah data yang dimigrasi (yaitu, saat proses antara database sumber dan target) menjadi sekecil mungkin saat peralihan pendekatan periode. Langkah ini mengurangi pengosongan waktu karena perbedaan yang lebih sedikit antara database sumber dan database target.
  • Jika klien baru yang beroperasi pada database target dapat dimulai secara serentak dengan operasi klien yang ada di database sumber, Anda dapat mempersingkat peralihan waktu karena klien baru siap dijalankan setelah seluruh data dikosongkan.

Meskipun tidak realistis untuk mencapai periode nonaktif nol selama peralihan, Anda mungkin dapat meminimalkan periode nonaktif dengan memulai aktivitas dan migrasi yang sedang berlangsung secara serentak.

Dalam beberapa skenario migrasi database, periode nonaktif yang signifikan bisa diterima. Biasanya, alokasi ini karena kebutuhan bisnis. Dalam kasus seperti ini, Anda dapat menyederhanakan pendekatan Anda. Misalnya, dengan migrasi database homogen, Anda mungkin tidak perlu memodifikasi data; ekspor dan impor atau pencadangan dan pemulihan adalah pendekatan yang sempurna. Dengan migrasi heterogen, sistem migrasi database tidak perlu menangani pembaruan sistem database sumber selama migrasi.

Namun, Anda perlu menetapkan periode nonaktif yang dapat diterima cukup lama untuk terjadinya migrasi database dan pengujian lanjutan. Jika periode nonaktif ini tidak dapat ditetapkan dengan jelas atau tidak dapat diterima dengan lama, Anda perlu merencanakan migrasi yang melibatkan periode nonaktif minimal.

Kardinalitas migrasi database

Dalam banyak situasi, migrasi database terjadi antara sumber database tunggal dan target database tunggal. Dalam situasi tersebut, kardinalitasnya adalah 1:1 (pemetaan langsung). Berarti, database sumber dimigrasikan tanpa perubahan ke database target.

Namun, pemetaan langsung bukan satu-satunya kemungkinan. Kardinalitas lainnya meliputi hal berikut:

  • Konsolidasi (n:1). Dalam konsolidasi, Anda memigrasikan data dari beberapa database sumber ke jumlah yang lebih kecil (atau bahkan hanya satu target). Anda dapat menggunakan pendekatan ini untuk menyederhanakan pengelolaan database atau menggunakan database target yang dapat diskalakan.
  • Distribusi (1:n). Dalam distribusi, Anda memigrasikan data dari satu database sumber ke beberapa database target. Contohnya, Anda mungkin menggunakan pendekatan ini ketika Anda perlu memigrasikan database terpusat berukuran besar yang berisi data regional ke beberapa database target regional.
  • Distribusi ulang (n:m). Dalam distribusi ulang, Anda memigrasikan data dari beberapa database sumber ke beberapa database target. Anda dapat menggunakan pendekatan ini jika Anda memiliki database sumber shard dengan ukuran shard yang sangat berbeda. Distribusi ulang berarti mendistribusikan data yang di-sharding secara merata ke beberapa database target yang mewakili shard.

Migrasi database memberikan Anda peluang untuk mendesain ulang dan menerapkan arsitektur database, selain melakukan migrasi data.

Konsistensi migrasi

Migrasi database diharapkan konsisten. Dalam konteks migrasi, konsisten berarti sebagai berikut:

  • Selesai. Semua data yang ditentukan untuk migrasi telah dimigrasikan. Data yang ditentukan dapat berupa seluruh data di database sumber atau subset data.
  • Tanpa duplikat. Setiap bagian data dimigrasikan sekali, dan hanya sekali. Tidak ada data duplikat yang dimigrasikan ke database target.
  • Urut. Perubahan data di database sumber diterapkan ke database target dengan urutan yang sama seperti perubahan yang terjadi di database sumber. Aspek ini sangatlah penting untuk memastikan konsistensi data.

Cara alternatif untuk mendeskripsikan konsistensi migrasi adalah status data antara database sumber dan target tersebut sama setelah migrasi selesai. Contoh, migrasi homogen yang melibatkan pemetaan langsung database relasional, mengharuskan database sumber dan database target memiliki tabel dan baris yang sama.

Cara alternatif yang menjelaskan konsistensi migrasi ini penting karena tidak semua migrasi data yang berdasarkan pada transaksi dari database sumber diterapkan secara berurutan ke database target. Contoh, Anda mungkin mencadangkan database sumber dan menggunakan cadangannya untuk memulihkan konten database sumber ke database target (jika mungkin terjadi periode nonaktif yang signifikan).

Migrasi aktif-pasif versus migrasi aktif-aktif

Perbedaan penting adalah apakah database sumber dan target terbuka untuk mengubah pemrosesan kueri. Dalam migrasi database aktif-pasif, database sumber dapat diubah selama migrasi, sedangkan database target hanya mengizinkan akses hanya baca.

Migrasi aktif-aktif mendukung klien menulis ke database sumber dan database target selama migrasi. Dalam migrasi jenis ini, konflik bisa saja terjadi. Misalnya, jika item data yang sama di database sumber dan target diubah sehingga saling bertentangan secara semantik, Anda mungkin perlu menjalankan aturan penyelesaian konflik agar konflik tersebut selesai.

Dalam migrasi aktif-aktif, Anda harus mampu menyelesaikan semua konflik data menggunakan aturan penyelesaian konflik. Jika tidak, inkonsistensi data mungkin terjadi.

Arsitektur migrasi database

Arsitektur migrasi database menjelaskan berbagai komponen yang diperlukan untuk menjalankan migrasi database. Bagian ini memperkenalkan arsitektur deployment umum dan memperlakukan sistem migrasi database sebagai komponen terpisah. Bagian ini juga membahas fitur sistem pengelolaan database yang mendukung migrasi data dan properti non-fungsional yang penting untuk banyak kasus penggunaan.

Arsitektur deployment

Migrasi database dapat terjadi antara database sumber dan target yang berada di lingkungan apa pun, seperti lokal atau cloud yang berbeda. Setiap database sumber dan target dapat berada dilingkungan yang berbeda, tidak semua harus berada dilingkungan yang sama.

Diagram berikut menunjukkan contoh arsitektur deployment yang melibatkan beberapa lingkungan.

Arsitektur migrasi yang melibatkan cloud dan pusat data lokal.

DB1 dan DB2 adalah dua database sumber dan DB3 dan Spanner adalah database target. Database migrasi ini melibatkan dua cloud dan dua data pusat lokal. Tanda panah mewakili hubungan pemanggilan: layanan migrasi database memanggil antarmuka semua database sumber dan target.

Kasus khusus yang tidak dibahas disini adalah migrasi data dari database ke database yang sama. Kasus khusus ini menggunakan sistem migrasi database hanya untuk transformasi data, bukan untuk migrasi data antar sistem berbeda di lingkungan berbeda.

Pada dasarnya, ada tiga pendekatan untuk migrasi database, yang dibahas pada bagian ini:

Sistem database migrasi

Sistem migrasi database adalah inti dari migrasi database. Sistem menjalankan ekstraksi data aktual dari database sumber, memindahkan data ke database target dan mengubah data selama pengiriman secara opsional. Bagian ini membahas fitur dasar sistem migrasi database secara umum. Contoh sistem migrasi database adalah Database Migration Service, Striim, Debezium, tcVision dan Cloud Data Fusion.

Proses migrasi data

Elemen penyusun teknis inti dari sistem migrasi database adalah proses migrasi data. Proses migrasi data ditentukan oleh developer dan menentukan database sumber dimana data diekstrak, database target dimana data dimigrasikan, dan logika modifikasi data yang diterapkan ke data selama migrasi.

Anda dapat menentukan satu atau lebih proses migrasi data dan menjalankannya secara berurutan atau serentak, tergantung pada kebutuhan migrasi. Contoh, Jika Anda memigrasikan database independen, proses migrasi data terkait dapat berjalan secara paralel.

Ekstraksi dan Penyisipan data

Anda dapat mendeteksi perubahan (penyisipan, pembaruan, penghapusan) dalam sistem database dengan dua cara: database yang didukung pengambilan data perubahan (CDC) berdasarkan log transaksi, dan kueri diferensial data menggunakan antarmuka kueri sistem pengelolaan database.

CDC berbasis log transaksi

Database yang didukung CDC didasarkan pada fitur pengelolaan database yang terpisah dari antarmuka kueri. Salah satu pendekatan didasarkan pada log transaksi (contohnya log biner di MySQL). Log transaksi berisi perubahan data dalam urutan yang benar. Log transaksi terus dibaca, sehingga setiap perubahan dapat diamati. Untuk migrasi database, logging ini sangat berguna karena CDC memastikan setiap perubahan terlihat dan kemudian dimigrasikan ke database target tanpa kehilangan dan dalam urutan yang benar.

CDC adalah pendekatan pilihan untuk menangkap perubahan di sistem pengelolaan database. CDC terintegrasi dengan database itu sendiri dan memiliki dampak pemuatan sistem yang rendah.

Kueri Diferensial

Jika tidak ada fitur sistem pengelolaan database yang dapat mengamati semua perubahan dalam urutan yang benar, Anda dapat menggunakan kueri diferensial sebagai alternatif. Dalam pendekatan ini, setiap item data di database mendapatkan atribut tambahan yang berisi stempel waktu atau nomor urut. Setiap kali item data diubah, stempel waktu perubahan ditambahkan atau nomor urut bertambah. Algoritma polling membaca semua item data sejak terakhir kali dieksekusi atau sejak nomor urut yang terakhir digunakan. Ketika algoritma polling menentukan perubahan, algoritma akan mencatat waktu saat ini atau nomor urut ke status internalnya, lalu meneruskan perubahan ke database target.

Meskipun pendekatan ini bekerja tanpa masalah untuk penyisipan dan pembaruan, Anda perlu mengatur penghapusan dengan hati-hati karena akan menghapus item data dari database. Setelah data dihapus, tidak mungkin bagi poller mendeteksi bahwa telah terjadi penghapusan. Anda dapat menerapkan penghapusan dengan menggunakan kolom status tambahan (flag penghapusan logis) yang menunjukan data.akan dihapus. Alternatifnya item data yang dihapus dapat dikumpulkan dalam satu atau beberapa tabel dan poller akan mengakses tabel tersebut untuk menentukan apakah telah terjadi penghapusan.

Untuk variasi kueri diferensial, lihat Pengambilan data perubahan.

Kueri diferensial adalah pendekatan yang tidak disarankan karena melibatkan perubahan skema dan fungsi. Pembuatan kueri database juga menambah muatan kueri yang tidak berkaitan dengan pelaksanaan logika klien.

Adaptor dan agen

Sistem migrasi database memerlukan akses ke sumber dan sistem database. Adaptor adalah abstraksi yang merangkum kemampuan akses. Dalam bentuk yang paling sederhana, adaptor dapat berupa driver JDBC untuk menyisipkan data ke dalam database target yang mendukung JDBC. Dalam kasus yang lebih kompleks, adaptor berjalan di lingkungan target (yang terkadang disebut agen), mengakses antarmuka database bawaan seperti file log. Dalam kasus yang lebih kompleks lagi, adaptor atau agen terhubung ke sistem software lain, yang nantinya mengakses database. Contoh, agen mengakses Oracle GoldenGate, dan kemudian akan mengakses database Oracle.

Adaptor atau agen yang mengakses database sumber menerapkan antarmuka CDC atau antarmuka kueri diferensial, bergantung pada desain sistem database. Dalam kedua kasus tersebut, adaptor dan agen memberikan perubahan pada sistem migrasi database, dan sistem migrasi database tidak mengetahui apakah perubahannya telah ditangkap oleh CDC atau kueri diferensial.

Modifikasi data

Dalam beberapa kasus penggunaan, data dimigrasikan dari database sumber ke database target yang tidak diubah. Migrasi langsung ini biasanya adalah homogen.

Namun, banyak kasus penggunaan yang memerlukan perubahan data selama proses migrasi. Biasanya, modifikasi diperlukan jika ada perbedaan dalam skema, atau nilai data atau peluang membersihkan data saat transisi.

Bagian berikut membahas beberapa jenis modifikasi yang mungkin diperlukan dalam migrasi data—transformasi data, pengayaan data atau korelasi, dan pengurangan atau pemfilteran data.

Transformasi data

Transformasi data mentransformasi beberapa atau semua nilai data dari database sumber. Beberapa contoh termasuk berikut ini:

  • Transformasi jenis data. Terkadang jenis data antara database sumber dan target tidak setara. Dalam kasus ini, transformasi jenis data melakukan transmisi nilai sumber ke nilai target berdasarkan aturan transformasi jenis. Contoh, jenis stempel waktu dari sumber mungkin ditransformasikan menjadi jenis string pada target.
  • Transformasi struktur data. Transformasi struktur data mengubah struktur di model database yang sama atau antara model database yang berbeda. Contoh, dalam sistem relasional, satu tabel sumber dapat dibagi menjadi dua tabel target, atau beberapa tabel sumber dapat didenormalisasi menjadi satu tabel target menggunakan gabungan. Hubungan 1:n di database sumber dapat ditransformasikan menjadi hubungan induk dan turunan di Spanner. Dokumen dari sistem database dokumen sumber dapat diuraikan menjadi sekumpulan baris relasional dalam sistem target.
  • Transformasi nilai data. Transformasi nilai data berbeda dengan transformasi jenis data. Transformasi nilai data mengubah nilainya tanpa mengubah jenis data. Contoh, zona waktu lokal dikonversi ke Coordinated Universal Time (UTC). Atau kode pos pendek (lima digit) diwakili oleh string dikonversi ke kode pos panjang (lima digit diikuti tanda hubung diikuti 4 digit, yang dikenal sebagai ZIP+4).
Pengayaan dan korelasi data

Transformasi data diterapkan pada data yang ada tanpa merujuk ke data referensi terkait lainnya. Dengan pengayaan data, data tambahan dikueri untuk melengkapi data sumber sebelum disimpan di database target.

  • Korelasi data. Adanya kemungkinan untuk mengkorelasikan data sumber. Contoh, Anda dapat menggabungkan data dari dua tabel di dua database sumber. Dalam database target, misalnya, Anda dapat menghubungkan pelanggan dengan semua pesanan yang sedang berlangsung, selesai, dan dibatalkan, dengan data pelanggan dan data pesanan berasal dari dua database sumber yang berbeda.
  • Pengayaan data. Pengayaan data menambahkan data referensi. Contoh, Anda dapat melengkapi data yang hanya berisi kode pos dengan menambahkan nama kota yang sesuai dengan kode pos tersebut. Tabel referensi yang berisi kode pos dan nama kota yang sesuai adalah set data statis yang diakses untuk kasus penggunaan ini. Data referensi juga dapat bersifat dinamis. Contoh, Anda dapat menggunakan daftar semua pelanggan yang dikenal sebagai data referensi.
Pengurangan dan pemfilteran data

Jenis transformasi data lainnya adalah mengurangi dan memfilter sumber data sebelum memigrasikannya ke database target.

  • Pengurangan data. Pengurangan data menghapus atribut dari item data. Contoh, jika kode pos ada dalam item data, nama kota yang sesuai tidak diperlukan atau dapat dihapus, karena dapat dihitung ulang atau tidak diperlukan lagi. Terkadang informasi ini disimpan karena alasan historis untuk mencatat nama kota yang dimasukkan oleh pengguna, meskipun nama kota tersebut berubah dari waktu ke waktu.
  • Memfilter data. Memfilter data menghapus item data sepenuhnya. Contoh, Semua pesanan yang dibatalkan dapat dihapus dan tidak ditransfer ke database target.
Kombinasi atau kombinasi ulang data

Jika data dimigrasikan dari database sumber ke database target yang berbeda, mungkin diperlukan cara yang lain untuk menggabungkan data antara database sumber dan target.

Misalkan data pelanggan dan data pesanan disimpan di dua database sumber yang berbeda. Satu database sumber berisi semua pesanan dan sumber database lainnya berisi semua pelanggan. Setelah migrasi, data pelanggan beserta pesanannya disimpan dalam hubungan 1:n dalam satu skema database—bukan dalam database target tunggal, namun dalam beberapa database target target, yang masing-masing berisi partisi data. Setiap database target mewakili region dan berisi semua pelanggan dan pesanan yang berada di region tersebut.

Pengalamatan database target

Setiap item data yang dimigrasi harus dikirimkan ke database target yang benar, kecuali jika hanya ada satu target. Beberapa pendekatan untuk pengalamatan database target adalah sebagai berikut:

  • Pengalamatan berdasarkan skema. Pengalamatan berdasarkan skema menentukan database target berdasarkan skema. Contoh, semua item data dari koleksi pelanggan atau semua baris dari tabel pelanggan dimigrasikan ke database target yang sama dan menyimpan informasi pelanggan, meskipun informasi ini telah didistribusikan ke beberapa database sumber.
  • Perutean berdasarkan konten. Perutean berdasarkan konten (contoh, menggunakan router berdasarkan konten, ) menentukan database target berdasarkan nilai data. Contoh, Semua pelanggan berlokasi di wilayah Amerika Latin dimigrasikan ke database target tertentu yang mewakili wilayah tersebut.

Anda dapat menggunakan kedua jenis pengalamatan secara bersamaan dalam migrasi database. Terlepas dari jenis pengalamatan yang digunakan, database target harus memiliki skema yang benar sehingga item data dapat disimpan.

Persistensi selama pengiriman data

Sistem migrasi database atau lingkungan tempat sistem dijalankan, dapat mengalami kegagalan selama migrasi dan kehilangan data saat pengiriman. Jika gagal, Anda perlu memulai ulang sistem migrasi database dan memastikan data yang disimpan di database sumber dimigrasikan ke database target secara konsisten dan lengkap.

Sebagai bagian dari langkah pemulihan, sistem migrasi database perlu mengidentifikasi item data terakhir yang berhasil dimigrasikan untuk menentukan dimana ekstraksi dari database sumber dimulai. Untuk melanjutkan titik kegagalan, sistem perlu memastikan status internal pada progres migrasi.

Anda dapat mempertahankan status dengan beberapa cara:

  • Anda dapat menyimpan item data yang diekstrak dalam sistem migrasi database sebelum modifikasi database, lalu menghapus item data setelah versi modifikasinya berhasil disimpan di database target. Pendekatan ini memastikan sistem migrasi database dapat menentukan dengan tepat apa yang diekstrak dan disimpan.
  • Anda dapat mempertahankan daftar referensi ke item data saat pengiriman. Salah satunya dengan menyimpan kunci utama atau ID unik lain setiap item data beserta atribut status. Setelah kegagalan terjadi, status ini menjadi dasar pemulihan sistem secara konsisten.
  • Anda dapat membuat kueri database sumber dan target setelah terjadinya kegagalan untuk menentukan perbedaan antara sistem database sumber dan target. Item data yang akan diekstrak selanjutnya ditentukan berdasarkan perbedaannya.

Pendekatan lain untuk mempertahankan status dapat bergantung pada database sumber tertentu. Contoh, sistem migrasi database dapat melacak entri log transaksi yang diambil dari sumber database dan disisipkan ke dalam database target. Jika terjadi kegagalan, migrasi dapat dimulai ulang dari entri terakhir yang berhasil disisipkan.

Persistensi selama pengiriman data juga penting karena alasan selain kesalahan atau kegagalan. Contoh, adanya kemungkinan tidak dapat mengkueri data dari database sumber untuk menentukan statusnya. Misalnya, jika database sumber yang berisi antrean, pesan dalam antrean tersebut mungkin telah dihapus pada suatu waktu.

Kasus penggunaan lain untuk persistensi selama pengiriman data adalah pemrosesan jendela data berukuran besar. Selama modifikasi data, item diubah secara mandiri satu sama lain. Namun, terkadang modifikasi data bergantung pada beberapa item data (contoh, penomoran item yang diproses per hari dan dimulai dari nol setiap hari).

Kasus penggunaan terakhir untuk persistensi selama pengiriman data adalah memberikan pengulangan data selama modifikasi data ketika sistem database tidak dapat mengakses database sumber lagi. Contoh, Anda mungkin perlu menjalankan ulang modifikasi data dengan aturan modifikasi yang berbeda, kemudian memverifikasi dan membandingkan hasilnya dengan modifikasi data awal. Pendekatan ini mungkin penting, jika Anda perlu melacak ketidaksesuain di database target karena modifikasi data yang salah.

Verifikasi kelengkapan dan konsistensi

Anda perlu memverifikasi bahwa migrasi database telah selesai dan konsisten. Pemeriksaan ini memastikan setiap item data dimigrasikan hanya sekali, dan set data di database sumber dan target telah identik dan migrasi telah selesai.

Bergantung pada aturan modifikasi, item data mungkin diekstraksi, tapi tidak disisipkan ke dalam database target. Oleh karena itu, membandingkan database sumber dan target secara langsung bukanlah pendekatan yang dapat diandalkan untuk memverifikasi kelengkapan dan konsistensi. Namun, jika sistem migrasi database merekam item yang akan difilter, Anda dapat membandingkan database sumber dan target serta item yang difilter.

Fitur replikasi sistem pengelolaan database

Kasus penggunaan khusus di migrasi homogen adalah ketika database target merupakan salinan dari database sumber. Secara khusus, database sumber dan target memiliki skema yang sama, nilai data yang sama, dan setiap database sumber dipetakan langsung (1:1) ke database target.

Dalam hal ini, Anda dapat menggunakan fitur replikasi bawaan yang disertakan dengan sebagian besar sistem pengelolaan database untuk mereplikasi database satu ke database lain.

Ada dua jenis replikasi data: logis dan fisik.

  • Replikasi logis: Dalam kasus replikasi logis, perubahan pada objek database ditransfer berdasarkan ID replikasinya (biasanya kunci utama). Keuntungan replikasi logis adalah fleksibel, terperinci, dan Anda dapat menyesuaikannya. Dalam beberapa kasus, replikasi logis memungkinkan Anda mereplikasi perubahan di antara berbagai versi mesin database. Banyak mesin database mendukung filter replikasi logis, tempat Anda dapat menentukan kumpulan data yang akan direplikasi. Kelemahan utamanya adalah replikasi logis mungkin menyebabkan beberapa overhead performa dan latensi metode replikasi ini biasanya lebih tinggi daripada replikasi fisik.

  • Replikasi fisik: Sebaliknya, replikasi fisik berfungsi pada level blok disk dan menawarkan performa yang lebih baik dengan latensi replikasi yang lebih rendah. Untuk set data besar, replikasi fisik dapat lebih mudah dan efisien, terutama dalam kasus struktur data non-relasional. Namun, hal ini tidak dapat disesuaikan dan sangat bergantung pada versi mesin database.

Contohnya, Replikasi MySQL, Replikasi PostgreSQL (lihat juga pglogical), atau Replikasi Microsoft SQL Server.

Namun, jika modifikasi data diperlukan, atau Anda memiliki kardinalitas selain pemetaan langsung, kemampuan sistem migrasi database diperlukan untuk menangani kasus penggunaan tersebut.

Migrasi database khusus secara fungsional

Beberapa alasan untuk mem-build fitur migrasi database, alih-alih menggunakan sistem migrasi database atau sistem pengelolaan database, antara lain:

  • Anda memerlukan kendali penuh atas setiap detail.
  • Anda ingin menggunakan kembali kemampuan migrasi database.
  • Anda ingin mengurangi biaya atau menyederhanakan jejak teknologi Anda.

Elemen penyusun untuk membuat fitur migrasi antara lain:

  • Ekspor dan impor: Jika periode nonaktif bukan suatu masalah, Anda dapat menggunakan ekspor database dan impor database untuk memigrasikan data dalam migrasi database homogen. Namun, dalam ekspor dan impor, Anda perlu menjeda database sumber untuk mencegah pembaruan sebelum Anda mengekspor data. Jika tidak, perubahan mungkin tidak direkam dalam ekspor, dan database target tidak berupa salinan yang sama persis dengan database sumber.
  • Pencadangan dan pemulihan: Seperti dalam kasus ekspor dan impor, pencadangan dan pemulihan akan mengalami periode nonaktif karena Anda perlu menjeda database sumber sehingga pencadangan berisi semua data dan perubahan terbaru. Periode nonaktif berlangsung hingga pemulihan di database target berhasil diselesaikan.
  • Kueri diferensial: Jika perubahan skema database bersifat opsi, Anda dapat memperluas skema tersebut sehingga perubahan database dapat dikuerikan ke antarmuka kueri. Atribut stempel waktu yang ditambahkan, menunjukkan waktu perubahan terakhir. Bendera hapus tambahan yang dapat ditambahkan, menunjukkan item data dihapus atau tidak (penghapusan logis). Dengan dua perubahan ini, poller yang dijalankan pada interval reguler dapat membuat kueri semua perubahan sejak terakhir kali dijalankan. Perubahan tersebut diterapkan ke database target. Pendekatan tambahan akan dibahas di Pengambilan data perubahan.

Ini hanyalah beberapa opsi yang memungkinkan untuk membangun migrasi database khusus. Meskipun solusi khusus memberikan fleksibilitas dan kontrol paling besar terhadap implementasi, solusi ini memerlukan pemeliharan secara terus menerus untuk mengatasi bug, pembatasan skalabilitas, dan masalah lain yang mungkin muncul selama migrasi database.

Pertimbangan tambahan untuk migrasi database

Bagian berikut membahas aspek-aspek penting non-fungsional dalam konteks migrasi database secara singkat. Aspek-aspek ini meliputi penanganan error, skalabilitas, ketersediaan tinggi, dan pemulihan dari bencana (disaster recovery).

Penanganan error

Kegagalan selama migrasi database tidak boleh menyebabkan kehilangan data atau pemrosesan database tidak sesuai dengan perintah. Integritas data harus dipertahankan, terlepas dari penyebab kegagalannya (seperti, bug pada sistem, gangguan jaringan, error VM, atau kegagalan zona).

Kehilangan data terjadi saat sistem migrasi mengambil data dari database sumber dan tidak menyimpannya di database karena beberapa kesalahan. Ketika data hilang, database target tidak sesuai dengan database sumber, sehingga tidak konsisten dan tidak lengkap. Fitur verifikasi kelengkapan dan konsistensi menandai status ini (Verifikasi kelengkapan dan konsistensi).

Skalabilitas

Dalam migrasi database, waktu migrasi merupakan metrik penting. Dalam migrasi tanpa periode nonaktif (dipahami periode nonaktif minimal), migrasi data saat database sumber terus berubah. Untuk migrasi dalam jangka waktu yang wajar, rasio transfer data harus secara signifikan lebih cepat dibandingkan rasio update di sistem database sumber, terutama ketika sistem database sumber besar. Semakin tinggi rasio transfer, migrasi database dapat diselesaikan lebih cepat.

Jika sistem database sumber dihentikan dan tidak diubah, migrasi mungkin lebih cepat karena tidak ada perubahan. Dalam database homogen, waktu migrasi mungkin cukup cepat karena Anda dapat menggunakan fitur pencadangan dan pemulihan atau ekspor dan impor, serta skala transfer file.

Ketersediaan tinggi dan pemulihan dari bencana (disaster recovery)

Secara umum, database sumber dan target dikonfigurasi untuk ketersediaan tinggi. Database utama memiliki replika baca terkait yang dipromosikan sebagai database utama ketika terjadi kegagalan.

Jika satu zona gagal, database sumber dan target beralih ke zona berbeda agar terus tersedia. Jika terjadi kegagalan selama migrasi database, sistem migrasi akan terpengaruh karena beberapa database sumber atau target sulit diakses. Sistem migrasi harus menyambung kembali ke database utama yang baru dipromosikan dan dijalankan setelah kegagalan. Sekali sistem migrasi database disambungkan kembali, sistem harus memulihkan migrasi untuk memastikan kelengkapan dan konsistensi data di database target. Sistem migrasi harus menentukan transfer terakhir yang konsisten untuk membangun kemana akan melanjutkan.

Jika sistem migrasi database gagal (contoh, zona dari sistem migrasi yang berjalan menjadi sulit diakses), maka sistem migrasi harus dipulihkan. Salah satu pendekatan pemulihan adalah cold restart. Dalam pendekatan ini, sistem migrasi database diinstal dan dimulai ulang dalam zona operasional. Masalah terbesar yang harus diatasi adalah sistem migrasi harus menentukan transfer data yang konsisten terakhir kalinya sebelum kegagalan dan meneruskan dari titik tersebut untuk memastikan kelengkapan dan konsistensi data di database target.

Jika sistem migrasi database diaktifkan untuk ketersediaan tinggi, sistem migrasi dapat dialihkan dan melanjutkan pemrosesan setelahnya. Jika periode nonaktif yang lebih sedikit pada sistem migrasi database penting, Anda perlu memilih database menerapkan ketersediaan tinggi.

Dalam hal pemulihan migrasi database, pemulihan bencana sangat mirip dengan ketersediaan tinggi. Daripada menghubungkan kembali database utama yang baru dipromosikan di zona lain, sistem migrasi database harus menghubungkan kembali ke database di region lain (failover region). Hal yang sama juga berlaku pada sistem migrasi database itu sendiri. Jika region tempat sistem migrasi database berjalan menjadi tidak dapat diakses, sistem migrasi database harus beralih ke region lain dan melanjutkan dari transfer data konsistensi terakhir.

Kesalahan

Beberapa kesalahan yang menyebabkan data di database target tidak konsisten. Beberapa kesalahan umum yang harus dihindari adalah sebagai berikut:

  • Pelanggaran pesan Jika skalabilitas sistem migrasi dicapai melalui penyebaran skala, maka beberapa proses transfer data berjalan secara serentak (dalam paralel). Perubahan di sistem database sumber akan diurutkan berdasarkan transaksi yang di-commit. Jika perubahan diambil dari log transaksi, urutannya harus dipertahankan selama migrasi. Transfer data paralel dapat mengubah urutan karena perbedaan kecepatan antara proses yang mendasarinya. Penting untuk memastikan bahwa data telah disisipkan ke dalam database target sesuai dengan urutan yang sama seperti pada database sumber.
  • Pelanggaran konsistensi Untuk kueri diferensial, database sumber memiliki atribut data tambahan, contoh stempel waktu commit. Database target tidak memiliki stempel waktu commit, karena stempel waktu commit hanya diterapkan untuk menetapkan manajemen perubahan di database sumber. Penting untuk memastikan penyisipan ke dalam database target harus memiliki stempel waktu yang konsisten, artinya semua perubahan dengan stempel waktu yang sama harus berada dalam penyisipan, pembaruan, atau transaksi upsert. Jika tidak, database target akan mengalami status tidak konsisten (untuk sementara) jika beberapa perubahan disisipkan sedangkan perubahan lain dengan stempel waktu yang sama tidak. Status tidak konsisten sementara ini bukan sebuah masalah jika database target tidak diakses untuk pemrosesan. Namun, jika database target digunakan untuk pengujian, konsistensi dianggap penting. Aspek lainnya adalah pembuatan nilai stempel waktu di database sumber dan cara mengaitkan ke waktu commit pada transaksi dimana nilai tersebut ditetapkan. Karena dependensi commit transaksi, transaksi dengan stempel waktu sebelumnya mungkin menjadi terlihat setelah transaksi dengan stempel waktu berikutnya. Jika kueri diferensial dieksekusi antara dua transaksi, kueri tidak akan melihat transaksi dengan stempel sebelumnya, sehingga terjadi inkonsistensi di database target.
  • Data hilang atau terduplikat. Saat failover terjadi, diperlukan pemulihan secara hati-hati, jika beberapa data antara replika utama dan failover tidak direplikasi. Contoh, database sumber mengalami fail over dan semua data tidak direplikasi ke replika failover. Pada saat yang sama, data sudah dimigrasikan ke database target sebelum kegagalan terjadi. Setelah failover, database utama yang baru dipromosikan mendasari aturan perubahan data ke database target (disebut dengan flashback). Sistem migrasi perlu mengenali situasi ini dan memulihkannya dengan cara database target dan sumber kembali ke status konsisten.
  • Transaksi lokal. Untuk memastikan database sumber dan target menerima perubahan yang sama, pendekatan umumnya adalah meminta klien menulis ke dua database yaitu database sumber dan target, alih-alih menggunakan sistem migrasi. Pendekatan ini memiliki kemungkinan kesalahan. Salah satunya, penulisan dua database menjadi dua transaksi terpisah; Anda mungkin mengalami kegagalan setelah yang pertama selesai dan sebelum yang kedua selesai. Skenario ini menyebabkan data tidak konsisten dan harus Anda pulihkan. Juga, adanya beberapa klien umum, dan mereka tidak terkoordinasi. Klien tidak mengetahui urutan commit dalam database sumber, sehingga tidak dapat menulis ke database target dengan menerapkan urutan transaksi. Klien dapat mengubah urutan, yang dapat menyebabkan data tidak konsisten. Kecuali semua akses melewati klien yang terkoordinasi, dan semua klien memastikan urutan transaksi target, pendekatan ini dapat menyebabkan status dan database target tidak konsisten.

Secara umum, ada kesalahan lain yang harus diperhatikan. Cara terbaik menemukan masalah yang menyebabkan data tidak konsisten adalah melakukan analisis kegagalan yang mengulangi semua kemungkinan skenario gagal. Jika konkurensi diterapkan di sistem migrasi database, semua kemungkinan urutan eksekusi proses migrasi data harus diperiksa untuk memastikan konsistensi data dipertahankan. Jika ketersediaan tinggi atau pemulihan bencana (atau keduanya) diterapkan, semua kemungkinan kombinasi kegagalan harus diperiksa.

Langkah berikutnya