Dokumen ini menjelaskan proses migrasi database Anda ke Spanner. Kami menjelaskan tahap migrasi dan alat yang kami rekomendasikan untuk setiap tahap, bergantung pada database sumber dan faktor lainnya. Alat yang direkomendasikan mencakup produk Google Cloud serta alat komersil dan open source pihak ketiga. Bersama-sama, alat-alat ini membantu Anda mempercepat migrasi dan mengurangi risiko.
Setiap migrasi Spanner melibatkan tahap inti berikut:
- Nilai kompleksitas migrasi Anda.
- Migrasikan skema Anda.
- Memuat data sampel.
- Migrasikan aplikasi Anda.
- Uji dan sesuaikan performa Anda.
- Memigrasikan data.
- Validasi migrasi.
- Konfigurasikan mekanisme transisi dan failover.
Dalam tahap-tahap ini, 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 replikasi dan failover.
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, sehingga Anda harus menyelesaikan langkah-langkah tersebut secara manual.
Alat migrasi Spanner (SMT) adalah alat open source yang dapat melakukan penilaian dasar, konversi skema, dan migrasi data.
Database Migration Assessment (DMA) menawarkan penilaian dasar untuk memigrasikan PostgreSQL ke Spanner.
Datastream adalah layanan Google Cloud yang memungkinkan Anda membaca peristiwa pengambilan data perubahan (CDC) dan data massal dari database sumber dan menulis ke tujuan yang ditentukan.
Dataflow adalah layanan Google Cloud yang membantu Anda menulis data dalam jumlah besar ke Spanner secara lebih efisien menggunakan template.
Migrasi data massal adalah template Dataflow yang memungkinkan Anda memigrasikan set data MySQL yang besar langsung ke Spanner.
Migrasi dengan periode nonaktif minimal menggunakan Datastream dan Dataflow untuk memigrasikan:
- Data yang ada di database sumber Anda.
- Aliran perubahan yang dibuat pada database sumber Anda selama migrasi.
Alat Validasi Data (DVT) adalah metode validasi data standar yang dibuat oleh Google dan didukung oleh komunitas open source. Anda dapat mengintegrasikan DVT ke dalam produk Google Cloud yang ada.
Alat migrasi untuk database sumber MySQL
Jika database sumber Anda adalah MySQL, Anda dapat melakukan beberapa tahap migrasi awal menggunakan file dump MySQL. Anda harus terhubung langsung ke database MySQL sumber yang sedang berjalan untuk menyelesaikan migrasi produksi.
Tabel berikut merekomendasikan alat migrasi berdasarkan tahap migrasi dan apakah Anda bekerja menggunakan file dump atau langsung menghubungkan database sumber:
| Tahap migrasi | File dump | Koneksi langsung ke database sumber |
|---|---|---|
| Penilaian | Gunakan SMT dengan mysqldump. |
Gunakan SMT dengan mysqldump. |
| Konversi skema | Gunakan SMT dengan mysqldump. |
Gunakan SMT untuk mengonfigurasi dan mengonversi skema. |
| Pemuatan data sampel |
|
Lakukan migrasi massal. |
| Migrasi data | Tidak berlaku | Lakukan migrasi massal, lalu lakukan migrasi dengan periode nonaktif minimal. |
| Validasi data | Tidak berlaku | Gunakan DVT. |
| Konfigurasi failover | Tidak berlaku | Gunakan SMT untuk replikasi balik. |
Alat migrasi untuk database sumber PostgreSQL
Jika database sumber Anda menggunakan PostgreSQL, Anda dapat melakukan beberapa tahap migrasi menggunakan file dump PostgreSQL. Anda harus terhubung langsung ke database PostgreSQL sumber yang sedang berjalan untuk menyelesaikan migrasi.
Tabel berikut merekomendasikan alat migrasi berdasarkan tahap migrasi dan apakah Anda menggunakan file dump atau terhubung langsung dari database sumber:
| Tahap migrasi | File dump | Koneksi langsung ke database sumber |
|---|---|---|
| Penilaian | Gunakan SMT dengan pg_dump. |
Gunakan DMA. |
| Konversi skema | Gunakan SMT dengan pg_dump. |
Gunakan SMT untuk mengonfigurasi dan mengonversi skema. |
| Pemuatan data sampel |
|
Lakukan migrasi dengan periode nonaktif minimal. |
| Migrasi data | Tidak berlaku | Lakukan migrasi dengan periode nonaktif minimal. |
| Validasi data | Tidak berlaku | Gunakan DVT. |
| Failover | Tidak berlaku | Tidak berlaku |
Menilai kompleksitas migrasi Anda
Untuk menilai cakupan dan kompleksitas migrasi serta merencanakan pendekatan, Anda perlu mengumpulkan data tentang database sumber, termasuk hal berikut:
- Pola kueri
- Jumlah logika aplikasi yang bergantung pada fitur database seperti prosedur tersimpan dan pemicu
- Persyaratan hardware
- Total biaya kepemilikan (TCO)
Memigrasikan skema
Sebelum memigrasikan skema ke skema Spanner, nilai kompatibilitas antara skema, dan optimalkan skema Anda untuk Spanner. Misalnya, Anda mungkin ingin mengubah kunci, menghapus atau menambahkan indeks, atau menambahkan atau menghapus kolom tabel yang ada. Untuk mengoptimalkan skema Anda untuk Spanner, lihat Praktik terbaik desain skema dan Rekomendasi strategi migrasi kunci utama.
Alat migrasi Spanner, alat open source yang dikelola komunitas dan dibuat oleh developer Google, secara otomatis mem-build 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, rekomendasi, dan migrasi skema:
- Rekomendasi dan penilaian kompatibilitas jenis data
- Rekomendasi dan pengeditan kunci utama
- Rekomendasi dan pengeditan indeks sekunder
- Menggabungkan pengeditan dan rekomendasi tabel
- Rekomendasi desain skema Spanner umum
- Pembuatan versi skema
- Modifikasi skema kolaboratif
Untuk 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.
Memuat data sampel
Setelah membuat skema yang kompatibel dengan Spanner, Anda dapat menyiapkan database untuk diuji menggunakan data sampel. Anda dapat menggunakan alur kerja ETL terbalik BigQuery untuk memuat data contoh. Untuk informasi selengkapnya, lihat Memuat data contoh.
Memigrasikan aplikasi Anda
Migrasi database memerlukan driver dan library yang berbeda, serta kompensasi untuk fitur yang tidak didukung Spanner. Untuk mengoptimalkan kekuatan Spanner, Anda mungkin perlu mengubah kode, alur aplikasi, dan arsitektur.
Berikut beberapa perubahan yang diperlukan untuk memigrasikan aplikasi Anda ke Spanner:
- Spanner tidak mendukung kode pengguna yang berjalan di tingkat database, sehingga Anda perlu memindahkan prosedur dan pemicu yang disimpan di tingkat database ke dalam aplikasi.
- Gunakan library klien Spanner dan pemetaan relasional objek (ORM). 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.
- Perhatikan DML berpartisi, transaksi hanya baca, stempel waktu commit, dan stempel waktu baca serta cara mengoptimalkan performa aplikasi.
Anda mungkin juga perlu melakukan perubahan pada penanganan transaksi. Tidak ada alat yang tersedia untuk membantu hal ini, jadi Anda harus menyelesaikan langkah ini secara manual. Perhatikan hal-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 mengubah data dalam jumlah besar, gunakan DML berpartisi.
- Untuk tingkat isolasi transaksi, tidak diperlukan penanganan karena transaksi Spanner lebih terisolasi.
- Karena Spanner bersifat linear, Spanner menangani konsistensi dan penguncian secara default.
Menguji dan menyesuaikan performa skema dan aplikasi
Penyesuaian performa adalah proses berulang yang digunakan untuk mengevaluasi metrik seperti pemakaian CPU dan latensi berdasarkan sebagian data, menyesuaikan skema dan aplikasi untuk meningkatkan performa, lalu menguji lagi.
Misalnya, dalam skema, Anda dapat menambahkan atau mengubah indeks, atau mengubah kunci utama. Dalam aplikasi, Anda dapat melakukan penulisan secara batch, atau menggabungkan atau mengubah kueri.
Khusus untuk traffic produksi, penyesuaian performa penting untuk membantu menghindari kejutan. Penyesuaian performa akan lebih efektif jika konfigurasinya lebih dekat dengan throughput traffic produksi langsung dan ukuran data.
Untuk menguji dan menyesuaikan skema dan performa aplikasi, ikuti langkah-langkah berikut:
- Upload sebagian data Anda ke database Spanner. Untuk mengetahui informasi selengkapnya, lihat Memigrasikan data.
- Arahkan aplikasi ke Spanner.
- Verifikasi kebenarannya dengan memeriksa alur dasar.
- Verifikasi bahwa performa memenuhi ekspektasi Anda dengan melakukan pengujian beban
pada aplikasi Anda. Untuk mendapatkan bantuan dalam mengidentifikasi dan mengoptimalkan kueri yang paling mahal, lihat Mendeteksi masalah performa kueri dengan insight kueri.
Secara khusus, faktor berikut dapat berkontribusi pada performa kueri yang suboptimal:
- Kueri yang tidak efisien: Untuk informasi tentang cara menulis kueri yang efisien, lihat Praktik terbaik SQL.
- Penggunaan CPU yang tinggi: Untuk informasi selengkapnya, lihat Menyelidiki penggunaan CPU yang tinggi.
- Penguncian: Untuk mengurangi bottleneck yang disebabkan oleh penguncian transaksi, lihat Mengidentifikasi transaksi yang mungkin menyebabkan latensi tinggi.
- Desain skema yang tidak efisien: Jika skema tidak dirancang dengan baik, pengoptimalan kueri tidak akan terlalu berguna.
- Hotspot: Hotspot di Spanner membatasi throughput operasi tulis, terutama untuk aplikasi dengan QPS tinggi. Untuk mengidentifikasi hotspot atau antipola, periksa statistik Key Visualizer dari konsol Google Cloud. Untuk mengetahui informasi selengkapnya tentang cara menghindari hotspot, lihat Memilih kunci utama untuk mencegah hotspot.
- Jika Anda mengubah skema atau indeks, ulangi pengujian akurasi dan performa hingga Anda mendapatkan hasil yang memuaskan.
Untuk informasi selengkapnya tentang cara meningkatkan performa database, hubungi dukungan Spanner.
Memigrasikan data
Setelah mengoptimalkan skema Spanner dan memigrasikan aplikasi, Anda akan memindahkan data ke database Spanner kosong berukuran produksi, lalu beralih ke database Spanner.
Bergantung pada database sumber, Anda mungkin dapat memigrasikan database dengan periode nonaktif minimal, atau Anda mungkin memerlukan periode nonaktif yang berkepanjangan.
Untuk migrasi periode nonaktif minimal dan migrasi dengan periode nonaktif yang berkepanjangan, sebaiknya gunakan Dataflow dan alat migrasi Spanner.
Tabel berikut menunjukkan perbedaan antara migrasi dengan waktu nonaktif minimal dan migrasi dengan waktu nonaktif lebih lama, termasuk sumber, format, ukuran, dan throughput yang didukung.
| Migrasi dengan 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 langsung. Lihat Menghubungkan 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 dengan periode nonaktif minimal
Spanner mendukung migrasi dengan periode nonaktif minimal dari Database MySQL, PostgreSQL, dan Oracle. Migrasi dengan periode nonaktif minimal terdiri dari dua komponen:
- Snapshot konsisten dari semua data dalam database
- Aliran perubahan (penyisipan dan pembaruan) sejak snapshot tersebut, disebut sebagai pengambilan data perubahan (CDC)
Meskipun migrasi dengan periode nonaktif minimal membantu melindungi data Anda, proses ini melibatkan tantangan, termasuk hal berikut:
- Menyimpan data CDC saat snapshot dimigrasikan.
- Menulis data CDC ke Spanner sambil merekam streaming CDC yang masuk.
- Memastikan bahwa migrasi data CDC ke Spanner lebih cepat daripada aliran CDC yang masuk.
Untuk mengelola migrasi dengan periode nonaktif minimal, alat migrasi Spanner akan mengatur proses berikut untuk Anda:
- Menyiapkan bucket Cloud Storage untuk menyimpan peristiwa CDC di database sumber saat migrasi snapshot berlangsung.
- Menyiapkan tugas Datastream yang memindahkan pemuatan massal data CDC dan terus melakukan streaming data CDC inkremental ke bucket Cloud Storage. Anda menyiapkan profil koneksi sumber dalam alat migrasi Spanner.
- Menyiapkan tugas Dataflow untuk memigrasikan peristiwa CDC ke Spanner.
Setelah menyalin sebagian besar data, Dataflow akan berhenti menulis ke database sumber dan menunggu data selesai dimigrasikan. Hal ini menyebabkan periode nonaktif singkat saat Spanner mengejar database sumber. Setelah itu, aplikasi dapat dipotong ke Spanner.
Diagram berikut menunjukkan proses ini:
Migrasi dengan periode nonaktif
Untuk database selain MySQL, PostgreSQL, atau Database Oracle, jika database dapat diekspor ke CSV atau Avro, Anda dapat bermigrasi 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 aktif, migrasi dengan periode nonaktif dapat menyebabkan hilangnya data.
Untuk melakukan migrasi selama periode nonaktif, ikuti langkah-langkah umum berikut:
- Buat file dump data dari database sumber.
- Upload file dump ke Cloud Storage dalam format dump MySQL, PostgreSQL, Avro, atau CSV.
- Muat file dump ke Spanner menggunakan Dataflow atau alat migrasi Spanner.
Membuat 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 membuat snapshot data yang konsisten, perhatikan hal-hal berikut:
- Untuk mencegah data berubah selama pembuatan file dump, sebelum Anda melakukan dump, terapkan kunci baca pada database sumber.
- Buat file dump menggunakan replika baca dari database sumber dengan replikasi dinonaktifkan.
Format yang direkomendasikan untuk migrasi massal
Avro adalah format pilihan untuk migrasi massal ke Spanner. Jika Anda menggunakan Avro, pertimbangkan hal berikut:
- Untuk membuat dump Avro data, gunakan alat seperti DBeam. Untuk mengetahui informasi selengkapnya tentang 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 sendiri atau menggunakan template impor Google Cloud. Untuk informasi selengkapnya, lihat Template pipeline data Dataflow.
Jika menggunakan MySQL atau PostgreSQL, Anda dapat menggunakan alat migrasi Spanner.
Untuk informasi tentang penggunaan 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 keduanya cocok.
Alat Validasi Data (DVT) adalah alat open source yang dapat terhubung ke penyimpanan data dan melakukan pemeriksaan antara sumber dan Spanner. Sebaiknya gunakan untuk melakukan validasi dasar sebagai bagian dari migrasi Anda, seperti berikut:
- Pastikan semua tabel telah dibuat dan semua pemetaan skema sudah benar .
- Mencocokkan jumlah baris untuk setiap tabel.
- Ekstrak baris acak untuk memverifikasi kebenaran.
- Validasi kolom Anda (
count,sum,avg,min,max,group by). - Membandingkan cyclic redundancy check atau fungsi hash di tingkat baris.
Untuk melakukan validasi yang lebih spesifik, buat pemeriksaan kustom selama migrasi.
Mengonfigurasi mekanisme transisi 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 menulis kembali ke database sumber melalui aliran seperti Pub/Sub atau Cloud Storage.
Replikasi balik perlu melakukan hal berikut:
- Menangani perubahan pada jenis data atau konten.
- Membalikkan transformasi apa pun yang dilakukan selama migrasi.
- Kirim data ke tujuan yang sesuai, dengan mempertimbangkan skema sharding pada sumber.