Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Artikel ini menjelaskan perangkap umum yang dihadapi dan praktik terbaik untuk memastikan migrasi yang lancar dan sukses ke Azure Database for PostgreSQL.
Validasi pramigrasi
Sebagai langkah pertama dalam migrasi, jalankan validasi pramigrasi sebelum Anda melakukan migrasi. Anda dapat menggunakan opsi Validasi dan Validasi dan migrasi pada halaman Penyiapan migrasi. Validasi pramigrasi melakukan pemeriksaan menyeluruh terhadap seperangkat aturan yang telah ditentukan sebelumnya. Tujuannya adalah untuk mengidentifikasi potensi masalah dan memberikan wawasan yang dapat ditindaklanjuti untuk tindakan perbaikan. Jalankan validasi pramigrasi terus menerus hingga menghasilkan status Berhasil. Untuk mempelajari lebih lanjut, lihat Validasi pramigrasi.
Konfigurasi fleksibel untuk server target
Selama penyalinan data dasar awal, beberapa perintah insert dijalankan pada target, yang menghasilkan log write-ahead (WAL). Sampai WAL ini diarsipkan, log akan menggunakan ruang penyimpanan di target dan juga penyimpanan yang dibutuhkan oleh database.
Untuk menghitung angka, masuk ke instans sumber dan jalankan perintah ini untuk semua database yang akan dimigrasikan:
SELECT pg_size_pretty( pg_database_size('dbname') );
Kami menyarankan agar Anda mengalokasikan penyimpanan yang memadai di server fleksibel, setara dengan 1,25 kali atau 25% lebih banyak penyimpanan daripada yang digunakan per output ke perintah sebelumnya. Anda juga dapat menggunakan Storage Autogrow.
Penting
Ukuran penyimpanan tidak dapat dikurangi dalam konfigurasi manual atau Storage Autogrow. Setiap langkah dalam spektrum konfigurasi penyimpanan berukuran ganda, jadi memperkirakan penyimpanan yang diperlukan sebelumnya bersifat bijaksana.
Panduan Cepat untuk Membuat server fleksibel Azure Database for PostgreSQL adalah tempat terbaik untuk memulai. Untuk informasi selengkapnya tentang setiap konfigurasi server, lihat Opsi komputasi dan penyimpanan di server fleksibel Azure Database for PostgreSQL.
Penting
Setelah server fleksibel dibuat, pastikan untuk mengubah parameter server password_encryption di server fleksibel Anda dari SCRAM-SHA-256 ke MD5 sebelum memulai migrasi. Ini penting bagi kredensial yang ada di server tunggal untuk bekerja di server fleksibel Anda
Garis waktu migrasi
Setiap migrasi memiliki masa pakai maksimum tujuh hari (168 jam) setelah dimulai, dan waktu habis setelah tujuh hari. Anda dapat menyelesaikan migrasi dan transisi aplikasi setelah validasi data dan semua pemeriksaan selesai untuk menghindari migrasi terputus. Dalam migrasi online, setelah salinan dasar awal selesai, jendela transisi berlangsung tiga hari (72 jam) sebelum terputus. Dalam migrasi offline, aplikasi harus berhenti menulis ke database untuk mencegah kehilangan data. Demikian pula, untuk migrasi online, menjaga lalu lintas tetap rendah selama migrasi.
Sebagian besar server nonproduksi (dev, UAT, test, dan staging) dimigrasikan dengan menggunakan migrasi offline. Karena server ini memiliki lebih sedikit data daripada server produksi, migrasinya cepat. Untuk migrasi server produksi, Anda perlu mengetahui waktu yang diperlukan untuk menyelesaikan migrasi untuk merencanakannya terlebih dahulu.
Waktu yang diperlukan untuk migrasi selesai tergantung pada beberapa faktor. Ini termasuk jumlah database, ukuran, jumlah tabel di dalam setiap database, jumlah indeks, dan distribusi data di seluruh tabel. Ini juga tergantung pada SKU server target dan IOPS yang tersedia pada instans sumber dan server target. Dengan begitu banyak faktor yang dapat memengaruhi waktu migrasi, sulit untuk memperkirakan total waktu untuk menyelesaikan migrasi. Pendekatan terbaik adalah melakukan pengujian migrasi dengan beban kerja yang Anda miliki.
Fase berikut dipertimbangkan untuk menghitung total waktu henti untuk melakukan migrasi server produksi:
Migrasi PITR: Cara terbaik untuk mendapatkan estimasi waktu yang diperlukan untuk memigrasi server basis data produksi Anda adalah dengan melakukan pemulihan titik waktu (PITR) pada server produksi dan menjalankan migrasi offline pada server yang baru dipulihkan ini.
Migrasi buffer: Setelah menyelesaikan langkah sebelumnya, Anda dapat merencanakan migrasi produksi yang sebenarnya selama periode waktu saat lalu lintas aplikasi rendah. Migrasi ini dapat direncanakan pada hari yang sama atau mungkin seminggu lagi. Pada saat ini, ukuran server sumber mungkin telah meningkat. Perbarui perkiraan waktu migrasi untuk server produksi Anda berdasarkan jumlah peningkatan ini. Jika peningkatan signifikan, pertimbangkan untuk melakukan pengujian lain dengan menggunakan server PITR. Tetapi untuk sebagian besar server, peningkatan ukuran seharusnya tidak cukup signifikan.
Validasi data: Setelah migrasi selesai untuk server produksi, Anda perlu memverifikasi apakah data di server fleksibel adalah salinan instans sumber yang tepat. Anda dapat menggunakan alat sumber terbuka atau pihak ketiga atau Anda dapat melakukan validasi secara manual. Siapkan langkah-langkah validasi yang ingin Anda lakukan sebelum migrasi aktual. Validasi dapat mencakup:
Kesesuaian jumlah baris untuk semua tabel yang terlibat dalam migrasi.
Jumlah pencocokan untuk semua objek database (tabel, urutan, ekstensi, prosedur, dan indeks).
Membandingkan ID maksimum atau minimum dari kolom kunci terkait aplikasi.
Catatan
Ukuran komparatif database bukanlah metrik yang tepat untuk validasi. Instans sumber mungkin memiliki kelebihan data atau tuple yang tidak aktif, yang dapat meningkatkan ukuran instans sumber. Biasanya memiliki perbedaan ukuran antara instans sumber dan server target. Masalah dalam tiga langkah validasi sebelumnya menunjukkan masalah dengan migrasi.
Migrasi pengaturan server: Setiap parameter server kustom, aturan firewall (jika ada), tag, dan pemberitahuan harus disalin secara manual dari instans sumber ke target.
Mengubah string koneksi: Aplikasi harus mengubah string koneksi menjadi server fleksibel setelah validasi berhasil. Aktivitas ini dikoordinasikan dengan tim aplikasi untuk mengubah semua referensi string koneksi yang menunjuk ke instans sumber. Di server fleksibel, parameter pengguna dapat digunakan dalam format user=username dalam string koneksi.
Misalnya: psql -h myflexserver.postgres.database.azure.com -u user1 -d db1
Meskipun migrasi sering berjalan tanpa masalah, praktik yang baik adalah merencanakan kontingensi jika lebih banyak waktu diperlukan untuk penelusuran kesalahan atau jika migrasi perlu dimulai ulang.
Tolok ukur kecepatan migrasi
Tabel berikut ini memperlihatkan waktu yang diperlukan untuk melakukan migrasi untuk database dengan berbagai ukuran dengan menggunakan layanan migrasi. Migrasi dilakukan dengan menggunakan server fleksibel dengan Standard_D4ds_v4 SKU (4 core, memori 16 GB).
| Ukuran database | Perkiraan waktu yang dibutuhkan (HH:MM) |
|---|---|
| 1 GB | 00:01 |
| 5 GB | 00.03 |
| 10 GB | 00:08 |
| 50 GB | 00:35 |
| 100 GB | 01:00 |
| 500 GB | 04:00 |
| 1.000 GB | 07:00 |
Angka sebelumnya memberi Anda perkiraan waktu yang diperlukan untuk menyelesaikan migrasi. Kami sangat menyarankan untuk menjalankan migrasi pengujian dengan beban kerja Anda guna mendapatkan nilai yang tepat untuk memigrasikan server Anda.
Penting
Meskipun SKU Burstable bukan batasan, disarankan untuk memilih SKU yang lebih tinggi untuk server fleksibel Anda untuk melakukan migrasi yang lebih cepat. Server fleksibel Azure Database for PostgreSQL mendukung komputasi waktu henti mendekati nol dan penskalaan IOPS, sehingga SKU dapat diperbarui dengan waktu henti minimal. Anda selalu dapat mengubah SKU agar sesuai dengan kebutuhan aplikasi pascamigrasi.
Meningkatkan kecepatan migrasi: Migrasi paralel tabel
Kami merekomendasikan SKU yang kuat untuk target karena layanan migrasi PostgreSQL kehabisan kontainer di server fleksibel. SKU yang kuat memungkinkan lebih banyak tabel untuk dimigrasikan secara paralel. Anda dapat menskalakan SKU kembali ke konfigurasi pilihan Anda setelah migrasi. Bagian ini berisi langkah-langkah untuk meningkatkan kecepatan migrasi jika distribusi data di antara tabel perlu lebih seimbang atau SKU yang lebih kuat tidak secara signifikan memengaruhi kecepatan migrasi.
Jika distribusi data pada sumber sangat tidak merata, yang sebagian besar datanya ada dalam satu tabel, komputasi yang dialokasikan untuk migrasi perlu digunakan sepenuhnya, yang menciptakan hambatan. Jadi, bagi tabel besar menjadi gugus yang lebih kecil, yang kemudian dimigrasikan secara paralel. Fitur ini berlaku untuk tabel yang lebih besar dari 20 GB. Memisahkan tabel menjadi potongan yang lebih kecil dimungkinkan jika salah satu kondisi berikut ini terpenuhi:
Tabel harus memiliki kolom dengan kunci primer sederhana (bukan komposit) atau indeks unik jenis
smallint,integerataubig int.Catatan
Dalam kasus pendekatan pertama atau kedua, Anda harus dengan hati-hati mengevaluasi implikasi penambahan kolom indeks unik ke skema sumber. Hanya setelah konfirmasi bahwa menambahkan kolom indeks unik tidak akan memengaruhi aplikasi jika Anda melanjutkan perubahan.
Jika tabel tidak memiliki kunci primer sederhana atau indeks unik jenis
smallint,integerataubig inttetapi memiliki kolom yang memenuhi kriteria jenis data, kolom dapat dikonversi menjadi indeks unik dengan menggunakan perintah berikut. Perintah ini tidak memerlukan kunci pada tabel.create unique index concurrently partkey_idx on <table name> (column name);Jika tabel tidak memiliki
smallintkunci utama ,integerataubig intatau indeks unik atau kolom apa pun yang memenuhi kriteria jenis data, Anda dapat menambahkan kolom tersebut dengan menggunakan ALTER dan menghilangkannya pascamigrasi. Menjalankan perintahALTERmemerlukan kunci pada tabel.alter table <table name> add column <column name> big serial unique;
Jika salah satu kondisi sebelumnya terpenuhi, tabel dimigrasikan dalam beberapa partisi secara paralel, yang harus memberikan peningkatan kecepatan migrasi.
Cara kerjanya
- Layanan migrasi mencari ukuran tabel untuk memeriksa apakah ukurannya lebih besar dari 20 GB.
- Jika ukurannya lebih besar dari 20 GB, dan ada
smallintinteger, ataubig intkunci primer atau indeks unik, tabel dibagi menjadi beberapa bagian dan setiap bagian dimigrasikan secara paralel.
Singkatnya, layanan migrasi PostgreSQL memigrasikan tabel dalam utas paralel dan mengurangi waktu migrasi jika:
- Tabel memiliki kolom dengan kunci primer sederhana atau indeks unik jenis
smallint,integerataubig int. - Ukuran tabel lebih besar dari 20 GB.
- SKU yang digunakan memiliki inti prosesor yang menganggur, yang dapat dimanfaatkan untuk memigrasi tabel secara paralel.
Mengatasi bloat dalam database PostgreSQL dengan vacuum
Seiring waktu, karena data ditambahkan, diperbarui, dan dihapus, PostgreSQL mungkin mengakumulasi baris mati dan ruang penyimpanan yang terbuang. Kembung ini dapat menyebabkan peningkatan persyaratan penyimpanan dan penurunan performa kueri. Menyedot debu adalah tugas pemeliharaan penting yang membantu merebut kembali ruang yang terbuang ini dan memastikan database beroperasi secara efisien. Proses pembersihan mengatasi masalah seperti baris mati dan penggembungan tabel untuk memastikan penggunaan penyimpanan yang efisien. Ini juga membantu memastikan migrasi yang lebih cepat karena waktu migrasi adalah fungsi dari ukuran database.
PostgreSQL menyediakan VACUUM perintah untuk mengklaim kembali penyimpanan yang ditempati oleh baris mati. Opsi ini ANALYZE juga mengumpulkan statistik untuk mengoptimalkan perencanaan kueri lebih lanjut. Untuk tabel dengan aktivitas tulis yang berat, proses VACUUM dapat lebih agresif dengan menggunakan VACUUM FULL, tetapi membutuhkan lebih banyak waktu untuk dijalankan.
Vakum standar
VACUUM your_table;Penghisapan dengan analisis
VACUUM ANALYZE your_table;Vakum agresif untuk tabel tulis berat
VACUUM FULL your_table;
Dalam contoh ini, ganti your_table dengan nama tabel aktual.
VACUUM Perintah tanpa FULL merebut kembali ruang secara efisien, sedangkan VACUUM ANALYZE mengoptimalkan perencanaan kueri. Opsi VACUUM FULL harus digunakan dengan bijaksana karena dampaknya yang lebih berat terhadap performa.
Beberapa database menyimpan objek besar, seperti gambar atau dokumen, yang dari waktu ke waktu dapat menyebabkan pembengkakan pada basis data. Perintah VACUUMLO ini dirancang untuk objek besar di PostgreSQL.
Menyedot objek besar
VACUUMLO;
Menerapkan strategi vakum ini secara teratur memastikan database PostgreSQL tetap terawat dengan baik.
Pertimbangan khusus
Ada kondisi khusus yang biasanya merujuk pada keadaan, konfigurasi, atau prasyarat unik yang perlu Anda waspadai sebelum melanjutkan tutorial atau modul. Kondisi ini dapat mencakup versi perangkat lunak tertentu, persyaratan perangkat keras, atau alat lain yang diperlukan untuk keberhasilan penyelesaian konten pembelajaran.
Migrasi online
Migrasi online menggunakan pgcopydb follow, dan beberapa pembatasan pada decoding logis berlaku. Kami juga menyarankan agar Anda memiliki kunci utama di semua tabel database yang sedang menjalani migrasi online. Jika kunci primer tidak ada, kekurangan ini mengakibatkan hanya operasi insert yang tercermin selama migrasi, sedangkan pembaruan atau penghapusan tidak termasuk. Tambahkan kunci primer sementara ke tabel yang relevan sebelum Anda melanjutkan migrasi online.
Catatan
Dalam kasus migrasi online tabel tanpa kunci utama, hanya insert operasi yang diputar ulang pada target. Ini bisa menyebabkan inkonsistensi dalam database jika catatan yang diperbarui atau dihapus di sumber tidak tercermin di target.
Alternatifnya adalah menggunakan perintah ALTER TABLE di mana tindakannya adalah REPLICA IDENTITY dengan opsi FULL. Opsi ini FULL merekam nilai lama semua kolom dalam baris sehingga bahkan tanpa adanya kunci primer, semua operasi CRUD tercermin pada target selama migrasi online. Jika tidak ada opsi ini yang berfungsi, lakukan migrasi offline sebagai alternatif.
Database dengan ekstensi postgres_fdw
Modul postgres_fdw menyediakan pembungkus data asing postgres_fdw, yang dapat digunakan untuk mengakses data yang disimpan di server PostgreSQL eksternal. Jika database Anda menggunakan ekstensi ini, langkah-langkah berikut harus dilakukan untuk memastikan migrasi berhasil.
- Hapus sementara (batalkan tautan) pembungkus data asing pada instans sumber.
- Lakukan migrasi data sisanya dengan menggunakan layanan migrasi.
- Pulihkan peran pembungkus data asing, pengguna, dan tautan ke target setelah migrasi.
Database dengan ekstensi postGIS
Ekstensi postGIS memiliki perubahan yang mengganggu dan masalah kompatibilitas di antara versi yang berbeda. Jika Anda bermigrasi ke server fleksibel, aplikasi harus diperiksa terhadap versi postGIS yang lebih baru untuk memastikan bahwa aplikasi tidak terpengaruh atau bahwa perubahan yang diperlukan harus dilakukan. Berita postGIS dan catatan rilis adalah titik awal yang baik untuk memahami perubahan besar di seluruh versi.
Pembersihan koneksi database
Terkadang, Anda mungkin mengalami kesalahan ini saat memulai migrasi:
CL003:Target database cleanup failed in the pre-migration step. Reason: Unable to kill active connections on the target database created by other users. Please add the pg_signal_backend role to the migration user using the command 'GRANT pg_signal_backend to <migrationuser>' and try a new migration.
Dalam skenario ini, Anda dapat memberikan migration user izin untuk menutup semua koneksi aktif ke database atau menutup koneksi secara manual sebelum Anda mencoba kembali migrasi.