Ringkasan migrasi

Dokumen ini menjelaskan proses migrasi database Anda ke Spanner. Kami menjelaskan tahapan migrasi dan alat yang kami rekomendasikan untuk setiap tahapan, bergantung pada database sumber Anda dan faktor lainnya. Alat yang direkomendasikan mencakup produk Google Cloud serta alat komersial dan open source pihak ketiga. Bersama-sama, kedua alat ini membantu Anda mempercepat migrasi dan mengurangi risiko.

Setiap migrasi Spanner melibatkan tahap inti berikut:

1. Nilai kompleksitas migrasi Anda.
2. Migrasikan skema Anda.
3. Memigrasikan aplikasi Anda.
4. Uji dan sesuaikan performa Anda.
5. Memigrasikan data.
6. Validasi migrasi.
7. Konfigurasi mekanisme migrasi sistem dan failover.

Diagram berikut menunjukkan proses ini:

Dalam tahapan tersebut, rencana migrasi Anda dapat sangat bervariasi, bergantung pada faktor-faktor seperti sumber dan ukuran database, persyaratan periode nonaktif, kompleksitas kode aplikasi, skema sharding, fungsi atau transformasi kustom, serta strategi failover dan replikasi.

Kami menyediakan panduan migrasi untuk Amazon DynamoDB, MySQL, Database Oracle, dan PostgreSQL. Jika Anda bermigrasi dari salah satu database ini, ikuti juga panduan yang relevan:

• Bermigrasi dari MySQL
• Bermigrasi dari PostgreSQL ke Spanner (dialek GoogleSQL)
• Bermigrasi dari PostgreSQL ke Spanner (dialek PostgreSQL)
• Bermigrasi dari Oracle Database
• Bermigrasi dari DynamoDB

Jika bermigrasi dari database lain, Anda mungkin memerlukan penyesuaian dan alat lebih lanjut yang tidak tercakup dalam panduan ini.

Solusi Migrasi

Sebaiknya gunakan alat berikut untuk membantu Anda dalam berbagai tahap migrasi, bergantung pada database sumber dan faktor lainnya. Beberapa alat hanya mendukung database sumber tertentu. Untuk beberapa langkah proses, tidak ada alat yang tersedia, jadi Anda menyelesaikan langkah-langkah tersebut secara manual.

• Alat migrasi Spanner adalah alat open source yang melakukan penilaian dasar serta migrasi skema dan data.
• Alat Validasi Data (DVT) adalah metode validasi data standar yang dibuat oleh Google dan didukung oleh komunitas open source. Anda dapat mengintegrasikan DVT ke produk Google Cloud yang sudah ada.
• Datastream adalah layanan Google Cloud yang memungkinkan Anda membaca peristiwa pengambilan data perubahan (CDC) dan data massal dari database sumber.
• Dataflow adalah layanan Google Cloud yang membantu Anda menulis data dalam jumlah besar ke Spanner secara lebih efisien menggunakan template. Template ini tidak menghasilkan file dump; file dump harus dihasilkan oleh alat database sumber atau alat pihak ketiga.

Tabel berikut meringkas alat utama yang kami rekomendasikan pada setiap tahap migrasi untuk beberapa database sumber umum. Anda dapat bermigrasi dari database lain dengan penyesuaian.

Database sumber	Menilai cakupannya	Memigrasikan skema	Memigrasikan aplikasi	Memigrasikan data	Memvalidasi migrasi data	Mengonfigurasi cutover dan failover
MySQL	Manual	Alat migrasi Spanner	Manual	Alat migrasi Spanner	DVT	Manual
PostgreSQL	Manual	Alat migrasi Spanner	Manual	Alat migrasi Spanner	DVT	Manual
{i>Database<i} lainnya	Manual	Alat migrasi Spanner	Manual	Manual	DVT	Manual

Menilai kompleksitas migrasi

Untuk menilai cakupan dan kompleksitas migrasi serta merencanakan pendekatan, Anda harus mengumpulkan data tentang database sumber, termasuk hal berikut:

• Pola kueri
• Jumlah logika aplikasi yang bergantung pada fitur database, seperti prosedur yang disimpan dan pemicu
• Persyaratan hardware
• Total biaya kepemilikan (TCO)

Memigrasikan skema

Sebelum memigrasikan skema ke skema Spanner, nilai kompatibilitas antar-skema, dan optimalkan skema untuk Spanner. Misalnya, Anda mungkin ingin mengubah kunci, menghapus atau menambahkan indeks, atau menambahkan atau menghapus kolom tabel yang ada. Guna mengoptimalkan skema untuk Spanner, lihat Praktik terbaik desain skema dan Strategi migrasi utama yang direkomendasikan.

Alat migrasi Spanner, alat open source yang dikelola komunitas dan dibuat oleh developer Google, secara otomatis membuat skema Spanner dari skema database sumber Anda. Anda dapat menyesuaikan skema menggunakan asisten skema alat migrasi Spanner.

Alat migrasi Spanner menyerap skema dan data dari salah satu lokasi berikut:

• File dump dari lokasi lokal atau Cloud Storage (MySQL, PostgreSQL, CSV)
• Langsung dari database sumber (MySQL, PostgreSQL)

Alat migrasi Spanner menjalankan fungsi berikut untuk penilaian skema, rekomendasi, dan migrasi:

• Penilaian dan rekomendasi kompatibilitas jenis data
• Pengeditan dan rekomendasi kunci utama
• Pengeditan dan rekomendasi indeks sekunder
• Pengeditan dan rekomendasi tabel yang tidak diperlukan
• Rekomendasi desain skema Spanner umum
• Pembuatan versi skema
• Modifikasi skema kolaboratif

Untuk mengetahui informasi selengkapnya tentang migrasi skema dengan alat migrasi Spanner, lihat file README.md alat migrasi Spanner.

Anda juga menggunakan alat migrasi Spanner untuk migrasi data.

Memigrasikan aplikasi Anda

Migrasi database memerlukan driver dan library yang berbeda, serta kompensasi untuk fitur yang tidak didukung Spanner. Untuk mencapai fungsi serupa dan mengoptimalkan kekuatan Spanner, Anda mungkin perlu mengubah kode, alur aplikasi, dan arsitektur.

Berikut ini beberapa perubahan yang diperlukan untuk memigrasikan aplikasi Anda ke Spanner:

• Spanner tidak mendukung pengoperasian kode pengguna di level database, jadi Anda perlu memindahkan prosedur dan pemicu yang disimpan di level database ke dalam aplikasi.
• Menggunakan library klien Spanner dan mapper (ORM) terkait objek. Untuk informasi selengkapnya, lihat Ringkasan API, library klien, dan driver ORM.
• Jika Anda perlu menerjemahkan kueri, terjemahkan secara manual atau gunakan alat pihak ketiga lainnya.
• Catat DML yang dipartisi, transaksi hanya baca, stempel waktu commit, dan baca stempel waktu serta cara hal tersebut dapat mengoptimalkan performa aplikasi.

Anda mungkin juga perlu membuat perubahan pada penanganan transaksi. Tidak ada alat yang tersedia untuk membantu hal ini, jadi Anda perlu menyelesaikan langkah ini secara manual. Perhatikan hal berikut:

• Batas mutasi per commit adalah 40.000. Setiap indeks sekunder pada tabel adalah mutasi tambahan per baris. Untuk mengubah data menggunakan mutasi, lihat Menyisipkan, memperbarui, dan menghapus data menggunakan mutasi. Untuk memodifikasi data dalam jumlah besar, gunakan DML yang dipartisi.
• Untuk tingkat isolasi transaksi, tidak ada penanganan yang diperlukan karena transaksi Spanner lebih terisolasi.
• Karena dapat dilinearkan, Spanner menangani konsistensi dan penguncian secara default.

Menguji dan menyesuaikan skema serta performa aplikasi

Penyesuaian performa adalah proses iteratif yang memungkinkan Anda mengevaluasi metrik seperti penggunaan dan latensi CPU berdasarkan subset data, menyesuaikan skema dan aplikasi untuk meningkatkan performa, lalu melakukan pengujian lagi.

Misalnya, dalam skema, Anda dapat menambahkan atau mengubah indeks, atau mengubah kunci utama. Dalam aplikasi, Anda dapat melakukan batch operasi tulis, atau menggabungkan atau mengubah kueri.

Khusus untuk traffic produksi, penyesuaian performa penting untuk membantu menghindari hal yang tidak diinginkan. Penyesuaian performa akan lebih efektif jika penyiapannya lebih dekat dengan throughput traffic produksi dan ukuran data aktif.

Untuk menguji dan menyesuaikan skema serta performa aplikasi, ikuti langkah-langkah berikut:

1. Upload subset data Anda ke dalam database Spanner. Untuk mengetahui informasi selengkapnya, lihat Memigrasikan data Anda.
2. Arahkan aplikasi ke Spanner.
3. Verifikasi kebenaran dengan memeriksa alur dasar.
4. Pastikan performa memenuhi harapan Anda dengan melakukan uji beban pada aplikasi. Untuk mendapatkan bantuan dalam mengidentifikasi dan mengoptimalkan kueri yang paling mahal, baca Mendeteksi masalah performa kueri dengan insight kueri. Secara khusus, faktor berikut dapat berkontribusi pada performa kueri yang kurang optimal:
   1. Kueri yang tidak efisien: Untuk mengetahui informasi tentang cara menulis kueri yang efisien, lihat Praktik terbaik SQL.
   2. Pemakaian CPU yang tinggi: Untuk informasi selengkapnya, lihat Menyelidiki pemakaian CPU yang tinggi.
   3. Penguncian: Untuk mengurangi bottleneck yang disebabkan oleh penguncian transaksi, lihat Mengidentifikasi transaksi yang mungkin menyebabkan latensi tinggi.
   4. Desain skema yang tidak efisien: Jika skema tidak dirancang dengan baik, pengoptimalan kueri tidak akan terlalu berguna.
   5. Hotspotting: Hotspot di Spanner membatasi throughput operasi tulis, terutama untuk aplikasi QPS tinggi. Untuk mengidentifikasi hotspot atau antipola, periksa statistik Key Visualizer dari konsol Google Cloud. Untuk mengetahui informasi selengkapnya tentang menghindari hotspot, lihat Memilih kunci utama untuk mencegah hotspot.
5. Jika Anda mengubah skema atau indeks, ulangi ketepatan dan pengujian performa sampai Anda memperoleh hasil yang memuaskan.

Untuk mengetahui informasi selengkapnya tentang cara menyesuaikan performa database, hubungi dukungan Spanner.

Memigrasikan data

Setelah mengoptimalkan skema Spanner dan memigrasikan aplikasi, Anda memindahkan data ke dalam database Spanner berukuran produksi yang kosong, lalu beralih ke database Spanner.

Bergantung pada database sumber, Anda mungkin dapat memigrasikan database dengan periode nonaktif yang minimal, atau Anda mungkin memerlukan periode nonaktif yang lama.

Untuk migrasi dan migrasi periode nonaktif minimal dengan periode nonaktif yang berkepanjangan, sebaiknya gunakan Dataflow dan alat migrasi Spanner.

Tabel berikut menunjukkan perbedaan antara migrasi periode nonaktif minimal dan migrasi dengan periode nonaktif yang lebih banyak, termasuk sumber, format, ukuran, dan throughput yang didukung.

	Migrasi periode nonaktif minimal	Migrasi dengan periode nonaktif
Sumber yang didukung	MySQL, PostgreSQL	Database apa pun yang dapat diekspor ke CSV atau Avro.
Format data yang didukung	Terhubung secara langsung. Lihat Terhubung secara langsung ke database MySQL.	MySQL, PostgreSQL, CSV, Avro
Ukuran database yang didukung	Tak terbatas	Tak terbatas
Throughput maksimum	45 GB per jam	200 GB per jam

Migrasi periode nonaktif minimal

Spanner mendukung migrasi periode nonaktif minimal dari MySQL, PostgreSQL, dan Oracle Database. Migrasi periode nonaktif minimal terdiri dari dua komponen:

• Snapshot yang konsisten dari semua data dalam database
• Aliran perubahan (penyisipan dan pembaruan) sejak snapshot tersebut, disebut sebagai pengambilan data perubahan (CDC)

Meskipun migrasi periode nonaktif minimal membantu melindungi data Anda, prosesnya melibatkan tantangan, termasuk hal berikut:

• Menyimpan data CDC saat snapshot dimigrasikan.
• Menuliskan data CDC ke Spanner saat menangkap aliran CDC yang masuk.
• Memastikan migrasi data CDC ke Spanner lebih cepat daripada aliran CDC yang masuk.

Untuk mengelola migrasi periode nonaktif minimal, alat migrasi Spanner mengatur proses berikut untuk Anda:

1. Menyiapkan bucket Cloud Storage untuk menyimpan peristiwa CDC di database sumber saat migrasi snapshot berlangsung.
2. Menyiapkan tugas Datastream yang memindahkan pemuatan massal data CDC dan terus mengalirkan data CDC inkremental ke bucket Cloud Storage. Anda menyiapkan profil koneksi sumber dalam alat migrasi Spanner.
3. Menyiapkan tugas Dataflow untuk memigrasikan peristiwa CDC ke Spanner.

Setelah menyalin sebagian besar data, Dataflow akan menghentikan penulisan ke database sumber dan menunggu hingga data selesai dimigrasikan. Hal ini menyebabkan periode nonaktif singkat, sementara Spanner mengejar database sumber. Setelah itu, aplikasi dapat dialihkan ke Spanner.

Diagram berikut menunjukkan proses ini:

Migrasi dengan periode nonaktif

Untuk database selain MySQL, PostgreSQL, atau Oracle Database, jika database dapat diekspor ke CSV atau Avro, Anda dapat melakukan migrasi ke Spanner dengan periode nonaktif. Sebaiknya gunakan Dataflow atau alat migrasi Spanner.

Migrasi dengan periode nonaktif hanya direkomendasikan untuk lingkungan pengujian atau aplikasi yang dapat menangani periode nonaktif beberapa jam. Pada database yang aktif, migrasi dengan periode nonaktif dapat menyebabkan kehilangan data.

Untuk melakukan migrasi periode nonaktif, ikuti langkah-langkah tingkat tinggi berikut:

1. Membuat file dump data dari database sumber.
2. Upload file dump ke Cloud Storage dalam format dump MySQL, PostgreSQL, Avro, atau CSV.
3. Muat file dump ke Spanner menggunakan Dataflow atau alat migrasi Spanner.

Menghasilkan beberapa file dump kecil akan mempercepat penulisan ke Spanner, karena Spanner dapat membaca beberapa file dump secara paralel.

Saat membuat file dump dari database sumber, untuk menghasilkan snapshot data yang konsisten, perhatikan hal berikut:

• Agar data tidak berubah selama pembuatan file dump, terapkan kunci baca pada database sumber sebelum Anda melakukan dump.
• Buat file dump menggunakan replika baca dari database sumber dengan replikasi yang dinonaktifkan.

Format yang direkomendasikan untuk migrasi massal

Avro adalah format yang lebih disukai untuk migrasi massal ke Spanner. Jika Anda menggunakan Avro, pertimbangkan hal berikut:

• Untuk menghasilkan dump data Avro, gunakan alat seperti DBeam. Untuk informasi selengkapnya tentang cara mengekspor ke Avro, lihat Mengekspor data dari database non-Spanner ke file Avro.
• Untuk mengimpor data Avro, gunakan tugas impor Dataflow. Untuk informasi selengkapnya, lihat Mengimpor file Avro dari database non-Spanner ke Spanner.

Jika Anda menggunakan CSV, pertimbangkan hal berikut:

• Untuk membuat dump CSV data, gunakan pembuatan CSV yang didukung oleh sumber. Jika data berisi baris baru, gunakan pemisah baris kustom.
• Untuk mengimpor data CSV, gunakan tugas impor Dataflow. Anda dapat membuat template impor Dataflow Anda sendiri atau menggunakan template impor Google Cloud. Untuk mengetahui informasi selengkapnya, lihat Template pipeline data Dataflow.

Jika menggunakan MySQL atau PostgreSQL, Anda dapat menggunakan alat migrasi Spanner.

Untuk mengetahui informasi tentang cara menggunakan skrip kustom untuk memuat data ke Spanner, lihat Panduan performa untuk pemuatan massal.

Memvalidasi migrasi data

Validasi data adalah proses membandingkan data dari tabel sumber dan tabel tujuan untuk memastikan kecocokannya.

Alat Validasi Data (DVT) adalah alat open source yang dapat terhubung ke penyimpanan data dan melakukan pemeriksaan antara sumber dan Spanner. Sebaiknya gunakan API tersebut untuk melakukan validasi dasar sebagai bagian dari migrasi Anda, seperti berikut:

• Pastikan semua tabel telah dibuat dan semua pemetaan skema sudah benar .
• Cocokkan jumlah baris setiap tabel.
• Ekstrak baris acak untuk memverifikasi ketepatan.
• Validasi kolom (count, sum, avg, min, max, group by).
• Membandingkan setiap {i>cyclic redundancy check<i} atau fungsi {i>hash<i} di tingkat baris.

Untuk melakukan validasi yang lebih spesifik, buat pemeriksaan kustom selama migrasi.

Mengonfigurasi mekanisme migrasi sistem dan failover

Migrasi sering kali memakan waktu dan rumit. Buat penggantian untuk menghindari dampak yang signifikan jika terjadi error selama migrasi, sehingga Anda dapat beralih kembali ke database sumber dengan periode nonaktif minimal.

Rekomendasi saat ini adalah menggunakan aliran perubahan untuk melakukan replikasi balik, dan melakukan penulisan kembali ke database sumber melalui aliran data seperti Pub/Sub atau Cloud Storage.

Replikasi balik perlu melakukan hal berikut:

• Menangani perubahan jenis data atau konten.
• Kembalikan transformasi apa pun yang dilakukan selama migrasi.
• Mengirim data ke tujuan yang sesuai, dengan mempertimbangkan skema sharding pada sumber.

Peringatan: Nonaktifkan CDC maju sebelum replikasi balik mulai menulis kembali ke sumber. Jika CDC maju masih aktif, menulis ke tabel yang sama dengan sumber dapat menyebabkan loop tanpa henti.