Replika baca di Azure Database for PostgreSQL - Server Tunggal

  • Artikel

BERLAKU UNTUK: Azure Database for PostgreSQL - Server Tunggal

Penting

Azure Database for PostgreSQL - Server Tunggal berada di jalur penghentian. Kami sangat menyarankan Agar Anda meningkatkan ke Azure Database for PostgreSQL - Server Fleksibel. Untuk informasi selengkapnya tentang migrasi ke Azure Database for PostgreSQL - Server Fleksibel, lihat Apa yang terjadi pada Server Tunggal Azure Database for PostgreSQL?.

Fitur replika baca memungkinkan Anda untuk mereplikasi data dari server Azure Database for PostgreSQL ke server baca-saja. Replika diperbarui secara asinkron dengan teknologi replikasi fisik asli mesin PostgreSQL. Anda dapat mereplikasi dari server utama maksimal lima replika.

Replika adalah server baru yang Anda kelola mirip dengan server Azure Database for PostgreSQL biasa. Untuk setiap replika baca, Anda akan ditagih atas komputasi yang disediakan dalam vCore dan penyimpanan dalam GB/bulan.

Pelajari cara membuat dan mengelola replika.

Kapan harus menggunakan replika baca

Fitur replika baca membantu meningkatkan performa dan skala beban kerja intensif baca. Beban kerja baca dapat diisolasi ke replika, sementara beban kerja tulis dapat diarahkan ke yang utama. Replika baca juga dapat digunakan di wilayah lain dan dapat dipromosikan menjadi server baca/tulis jika terjadi pemulihan bencana.

Skenario umum adalah meminta BI dan beban kerja analitis menggunakan replika baca sebagai sumber data untuk pelaporan.

Karena bersifat baca-saja, replika tidak mengurangi beban kapasitas tulis pada replika utama secara langsung.

Pertimbangan

Fitur ini dimaksudkan untuk skenario ketika lag dapat diterima dan dimaksudkan untuk menurunkan kueri. Ini tidak dimaksudkan untuk skenario replikasi sinkron ketika data replika diperkirakan akan diperbarui. Akan ada penundaan terukur antara yang utama dan replika. Penundaan dapat berlangsung dalam hitungan menit atau bahkan jam tergantung pada beban kerja dan latensi antara yang utama dan replika. Data pada replika akhirnya selaras dengan data di server utama. Gunakan fitur tersebut untuk beban kerja yang dapat mengakomodasi penundaan ini.

Catatan

Untuk sebagian besar beban kerja, replika baca menawarkan pembaruan hampir real time dari yang utama. Namun, dengan beban kerja utama intensif tulis yang berat dan persisten, lag replikasi dapat terus bertambah dan mungkin tidak akan pernah dapat mengejar ketinggalan dengan yang utama. Ini juga dapat meningkatkan penggunaan penyimpanan di primer karena file WAL tidak dihapus hingga diterima di replika. Jika situasi ini terus berlanjut, menghapus dan membuat ulang replika baca setelah beban kerja intensif tulis selesai adalah opsi untuk mengembalikan replika ke kondisi yang baik sehubungan dengan lag. Replika baca asinkron tidak sesuai untuk beban kerja tulis berat tersebut. Saat mengevaluasi replika baca untuk aplikasi Anda, pantau lag pada replika untuk siklus beban kerja aplikasi penuh melalui waktu puncak dan non-puncaknya untuk mengakses kemungkinan lag dan RTO/RPO yang diharapkan di berbagai titik siklus beban kerja.

Catatan

Pencadangan otomatis dilakukan untuk server replika yang dikonfigurasi dengan konfigurasi penyimpanan hingga 4TB.

Replikasi lintas wilayah

Anda dapat membuat replika baca di wilayah yang berbeda dari server utama Anda. Replikasi lintas wilayah dapat membantu skenario seperti perencanaan pemulihan bencana atau mendekatkan data dengan pengguna Anda.

Catatan

Server tingkat dasar hanya mendukung replikasi wilayah yang sama.

Anda dapat memiliki server utama di setiap wilayah Azure Database for PostgreSQL. Server utama dapat memiliki replika di wilayah pasangannya atau wilayah replika universal. Gambar di bawah ini menunjukkan wilayah replika yang tersedia, tergantung pada wilayah utama Anda.

Baca wilayah replika

Wilayah replika universal

Anda selalu dapat membuat replika baca di salah satu wilayah berikut, terlepas dari tempat server utama Anda berada. Berikut adalah wilayah replika universal:

Australia Timur, Australia Tenggara, Brasil Selatan, Kanada Tengah, Kanada Timur, US Tengah, Asia Timur, US Timur, US Timur 2, Jepang Timur, Jepang Barat, Korea Tengah, Korea Selatan, US Tengah Utara, Eropa Utara, US Selatan Tengah, Asia Tenggara, UK Selatan, UK Barat, Eropa Barat, EU Barat, US Barat 2, Barat Sentral AS.

Wilayah yang dipasangkan

Selain wilayah replika universal, Anda dapat membuat replika baca di wilayah berpasangan Azure dari server utama Anda. Jika tidak mengetahui pasangan wilayah Anda, Anda dapat mempelajari selengkapnya dari artikel Wilayah Berpasangan Azure.

Jika menggunakan replika lintas wilayah untuk perencanaan pemulihan bencana, sebaiknya buat replika di wilayah berpasangan, bukan di salah satu wilayah lainnya. Wilayah yang dipasangkan menghindari pembaruan simultan dan memprioritaskan isolasi fisik dan residensi data.

Ada beberapa batasan untuk dipertimbangkan:

  • Pasangan satu arah: Beberapa wilayah Azure dipasangkan dalam satu arah saja. Wilayah tersebut mencakup India Barat, Brasil Selatan. Ini berarti bahwa server utama di India Barat dapat membuat replika di India Selatan. Namun, server utama di India Selatan tidak dapat membuat replika di India Barat. Karena wilayah sekunder India Barat adalah India Selatan, tetapi wilayah sekunder India Selatan bukan India Barat.

Membuat replika

Saat Anda memulai alur kerja buat replika, Azure Database for PostgreSQL kosong akan dibuat. Server baru diisi dengan data yang ada di server utama. Waktu pembuatan tergantung pada jumlah data di server utama dan waktu sejak pencadangan penuh mingguan terakhir. Waktu dapat berkisar dari beberapa menit hingga beberapa jam.

Setiap replika diaktifkan untuk penyimpanan yang bertambah secara otomatis. Fitur bertambah otomatis memungkinkan replika untuk mengikuti data yang direplikasi ke sana, dan mencegah pemutusan replikasi yang disebabkan oleh kesalahan penyimpanan.

Fitur replika baca menggunakan replikasi fisik PostgreSQL, bukan replikasi logis. Replikasi streaming dengan menggunakan slot replikasi merupakan mode operasi default. Jika perlu, pengiriman log digunakan untuk mengejar ketinggalan.

Pelajari cara membuat replika baca di portal Azure.

Jika server PostgreSQL sumber Anda dienkripsi dengan kunci yang dikelola pelanggan, lihat dokumentasi untuk pertimbangan tambahan.

Menghubungkan ke replika

Saat Anda membuat replika, replika tidak mewarisi aturan firewall atau titik akhir layanan VNet dari server utama. Aturan tersebut harus disiapkan secara independen untuk replika.

Replika mewarisi akun administrator dari server utama. Semua akun pengguna di server utama direplikasi ke replika baca. Anda hanya dapat tersambung ke replika baca dengan menggunakan akun pengguna yang tersedia di server utama.

Anda dapat tersambung ke replika dengan menggunakan nama host dan akun pengguna yang valid, seperti yang Anda lakukan pada Azure Database for PostgreSQL biasa. Untuk server bernama my replica dengan nama pengguna admin myadmin, Anda dapat terhubung ke replika dengan menggunakan psql:

psql -h myreplica.postgres.database.azure.com -U myadmin@myreplica -d postgres

Di perintah, masukkan kata sandi untuk akun pengguna.

Pantau replikasi

Azure Database for PostgreSQL menyediakan dua metrik untuk memantau replikasi. Kedua metrik tersebut adalah Lag Maks. Di Seluruh Replika dan Lag Replika. Untuk mempelajari cara menampilkan metrik tersebut, lihat bagian Memantau replika dari artikel petunjuk replika baca.

Metrik Lag Maks. Di Seluruh Replika menunjukkan lag dalam byte antara replika utama dan replika yang paling tertinggal. Metrik ini berlaku dan hanya tersedia di server utama, dan hanya akan tersedia jika setidaknya salah satu replika baca terhubung ke server utama dan server utama sedang dalam mode replikasi streaming. Informasi lag tidak menunjukkan detail ketika replika sedang dalam proses mengejar ketinggalan dengan server utama menggunakan log yang diarsipkan dari server utama dalam mode replikasi pengiriman file.

Metrik Lag Replika menunjukkan waktu sejak transaksi terakhir yang diputar ulang. Jika tidak ada transaksi di server utama Anda, metrik mencerminkan lag waktu ini. Metrik ini hanya berlaku dan tersedia untuk server replika. Replica Lag dihitung dari tampilan pg_stat_wal_receiver:

SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());

Atur pemberitahuan untuk memberi tahu Anda ketika lag replika mencapai nilai yang tidak dapat diterima untuk beban kerja Anda.

Untuk wawasan tambahan, lakukan kueri pada server utama secara langsung untuk mendapatkan lag replikasi dalam byte pada semua replika.

Catatan

Jika server utama atau replika baca dimulai ulang, waktu yang diperlukan untuk memulai ulang dan mengejar ketinggalan direpresentasikan dalam metrik Lag Replika.

Menghentikan replikasi/Promosikan replika

Anda dapat menghentikan replikasi antara server utama dan replika kapan saja. Tindakan berhenti menyebabkan replika dimulai ulang dan mempromosikan replika menjadi server independen yang dapat dibaca-tulis mandiri. Data di server mandiri adalah data yang tersedia di server replika pada saat replikasi dihentikan. Setiap pembaruan berikutnya di server utama tidak disebarluaskan ke replika. Namun, server replika mungkin memiliki akumulasi log yang belum diterapkan. Sebagai bagian dari proses mulai ulang, replika menerapkan semua log yang tertunda sebelum menerima koneksi klien.

Catatan

Mengatur ulang kata sandi admin di server replika saat ini tidak didukung. Selain itu, memperbarui kata sandi admin bersama dengan mempromosikan operasi replika dalam permintaan yang sama juga tidak didukung. Jika Anda ingin melakukan ini, Anda harus terlebih dahulu mempromosikan server replika kemudian memperbarui kata sandi di server yang baru dipromosikan secara terpisah.

Pertimbangan

  • Sebelum menghentikan replikasi pada replika baca, periksa lag replikasi untuk memastikan replika memiliki semua data yang diperlukan.
  • Karena replika baca harus menerapkan semua log yang tertunda sebelum dapat dijadikan server mandiri, RTO bisa menulis beban kerja berat lebih tinggi saat replikasi dihentikan karena mungkin ada penundaan yang signifikan pada replika. Perhatikan hal ini ketika berencana untuk mempromosikan replika.
  • Server replika yang dipromosikan tidak dapat dibuat menjadi replika lagi.
  • Jika Anda mempromosikan replika menjadi server utama, Anda tidak dapat membuat replikasi kembali ke server utama lama. Jika Anda ingin kembali ke wilayah utama lama, Anda dapat membuat server replika baru dengan nama baru (atau) menghapus server utama lama dan membuat replika menggunakan nama server utama lama.
  • Jika Anda memiliki beberapa replika baca, dan jika Anda mempromosikan salah satunya menjadi server utama, server replika lainnya masih terhubung ke server utama lama. Anda mungkin harus membuat ulang replika dari server baru yang dipromosikan.

Jika Anda menghentikan replikasi, replika akan kehilangan semua tautan ke replika utama dan replika lain sebelumnya.

Pelajari cara menghentikan replikasi pada replika.

Failover pada replika

Jika terjadi kegagalan server utama, tidak secara otomatis gagal ke replika baca.

Karena replikasi bersifat sinkron, mungkin ada lag yang cukup signifikan antara server utama dan replika. Jumlah lag dipengaruhi oleh beberapa faktor seperti jenis beban kerja yang berjalan di server utama dan latensi antara server utama dan replika. Dalam kasus umum dengan beban kerja tulis nominal, lag replika diperkirakan antara beberapa detik hingga beberapa menit. Namun, dalam kasus server utama menjalankan beban kerja intensif tulis yang sangat berat dan replika tidak mengejar cukup cepat, lag bisa jauh lebih tinggi. Anda dapat melacak lag replikasi untuk setiap replika menggunakan metrik Lag Replika. Metrik ini menunjukkan waktu sejak transaksi terakhir diputar ulang di replika. Sebaiknya identifikasi lag rata-rata dengan mengamati lag replika selama periode waktu tertentu. Anda dapat mengatur pemberitahuan pada lag replika, sehingga jika melampaui rentang yang diharapkan, Anda akan diberi tahu untuk mengambil tindakan.

Tip

Jika Anda melakukan failover pada replika, lag saat Anda memutuskan tautan replika dari server utama akan menunjukkan jumlah data yang hilang.

Setelah memutuskan ingin melakukan failover pada replika,

  1. Menghentikan replikasi pada replika
    Langkah ini diperlukan untuk membuat server replika menjadi server mandiri dan dapat menerima tulis. Sebagai bagian dari proses ini, server replika akan dimulai ulang dan diputus dari server utama. Setelah Anda memulai penghentian replikasi, proses backend biasanya membutuhkan waktu beberapa menit untuk menerapkan log sisa yang belum diterapkan dan untuk membuka database sebagai server yang dapat dibaca-tulis. Lihat bagian menghentikan replikasi di artikel ini untuk memahami implikasi dari tindakan ini.

  2. Arahkan aplikasi Anda ke replika (sebelumnya)
    Setiap server memiliki string koneksi yang unik. Perbarui string koneksi aplikasi Anda agar mengarah ke replika (sebelumnya) alih-alih yang utama.

Setelah aplikasi berhasil memproses baca dan tulis, artinya Anda telah menyelesaikan failover. Jumlah waktu henti yang dialami aplikasi Anda akan bergantung pada saat Anda mendeteksi masalah dan menyelesaikan langkah 1 dan 2 di atas.

Pemulihan dari bencana

Ketika ada peristiwa bencana besar seperti tingkat zona ketersediaan atau kegagalan wilayah, Anda dapat melakukan operasi pemulihan bencana dengan mempromosikan replika baca Anda. Dari portal antarmuka pengguna, Anda dapat menavigasi ke server replika baca. Kemudian klik tab replikasi dan Anda dapat menghentikan replika untuk mempromosikannya menjadi server independen. Atau, Anda dapat menggunakan Azure CLI untuk menghentikan dan mempromosikan server replika.

Pertimbangan

Bagian ini merangkum pertimbangan tentang fitur replika baca.

Prasyarat

Replika baca dan decoding logis keduanya bergantung pada Postgres write ahead log (WAL) untuk informasi. Kedua fitur ini membutuhkan tingkat pengelogan yang berbeda dari Postgres. Pendekodean logis membutuhkan tingkat pengelogan yang lebih tinggi daripada replika baca.

Untuk mengonfigurasi tingkat pengelogan yang benar, gunakan parameter dukungan replikasi Azure. Dukungan replikasi Azure memiliki tiga opsi pengaturan:

  • Nonaktif - Menempatkan informasi paling sedikit di WAL. Pengaturan ini tidak tersedia di sebagian besar server Azure Database for PostgreSQL.
  • Replika - Lebih verbose daripada Nonaktif. Ini adalah tingkat pencatatan minimum yang diperlukan agar replika baca berfungsi. Pengaturan ini telah default di sebagian besar server.
  • Logis - Lebih verbose daripada Replika. Ini adalah level minimum pengelogan agar dekode logis berfungsi. Replika baca juga berfungsi pada pengaturan ini.

Replika baru

Replika baca dibuat sebagai server Azure Database for PostgreSQL baru. Server yang sudah ada tidak dapat dibuat menjadi replika. Anda tidak dapat membuat replika atas replika baca lain.

Konfigurasi replika

Replika dibuat dengan menggunakan pengaturan komputasi dan penyimpanan yang sama dengan server utama. Setelah replika dibuat, beberapa pengaturan dapat diubah, termasuk penyimpanan dan periode retensi cadangan.

Aturan firewall, aturan jaringan virtual, dan pengaturan parameter tidak diturunkan dari server utama ke replika ketika replika sedang dibuat atau sesudahnya.

Penskalaan

Penskalaan vCore atau antara Tujuan Umum dan Memori yang Dioptimalkan:

  • PostgreSQL mengharuskan pengaturan max_connections pada server sekunder lebih besar dari atau sama dengan pengaturan pada server utama, jika tidak, server sekunder tidak akan dimulai.
  • Di Azure Database for PostgreSQL, koneksi maksimum yang diizinkan untuk setiap server ditetapkan ke sku komputasi karena koneksi menempati memori. Anda dapat mempelajari selengkapnya tentang pemetaan antara max_connections dan sku komputasi.
  • Peningkatan skala: Pertama, tingkatkan skala komputasi replika, lalu tingkatkan skala utama. Perintah ini akan mencegah kesalahan melanggar persyaratan max_connections.
  • Menurunkan skala: Pertama-tama turunkan skala komputasi utama, lalu turunkan skala replika. Jika Anda mencoba menskalakan replika lebih rendah dari yang utama, akan ada kesalahan karena tindakan ini melanggar persyaratan max_connections.

Penyimpanan penskalaan:

  • Semua replika mengaktifkan penyimpanan yang bertambah secara otomatis untuk mencegah masalah replikasi dari replika penyimpanan penuh. Pengaturan ini tidak dapat dinonaktifkan.
  • Anda juga dapat meningkatkan penyimpanan secara manual, seperti yang Anda lakukan di server lain

Tingkat Dasar

Server tingkat dasar hanya mendukung replikasi wilayah yang sama.

max_prepared_transactions

PostgreSQL mengharuskan nilai parameter max_prepared_transactions pada replika baca lebih besar dari atau sama dengan nilai utama; jika tidak, replika tidak akan dimulai. Jika Anda ingin mengubah max_prepared_transactions pada server utama, ubah dulu pada replika.

Replika yang dihentikan

Jika Anda menghentikan replikasi antara server utama dan replika baca, replika akan dimulai ulang untuk menerapkan perubahan. Replika yang dihentikan menjadi server mandiri yang menerima baca dan tulis. Server mandiri tidak dapat dibuat menjadi replika lagi.

Server utama dan mandiri yang dihapus

Ketika server utama dihapus, semua replika bacanya menjadi server mandiri. Replika dimulai ulang untuk merepresentasikan perubahan ini.

Langkah berikutnya