Replikasi Berbilang Induk (BDR)

Replikasi PostgreSQL tradisional melibatkan satu pelayan utama dan satu atau lebih pelayan siaga (replika). Penulisan hanya berlaku pada pelayan utama, manakala bacaan boleh dipindahkan kepada replika.

Replikasi berbilang utama (MMR) berbeza. Replikasi ini membolehkan penulisan berlaku pada berbilang pelayan pangkalan data secara serentak, dengan semua perubahan disegerakkan merentasi kluster.

MMR menawarkan kelebihan yang ketara berbanding persediaan satu utama tradisional:

• Ketersediaan Tinggi: Jika satu nod utama gagal, nod lain boleh terus menerima penulisan, sekali gus memastikan operasi berterusan.
• Kebolehskalaan Penulisan: Agihkan operasi penulisan merentasi berbilang nod untuk berpotensi meningkatkan prestasi aplikasi yang banyak melakukan penulisan.
• Pengagihan Geografi: Letakkan nod pangkalan data aktif lebih dekat dengan pengguna di rantau yang berbeza bagi mengurangkan kependaman operasi setempat.

Cabaran terbesar dalam replikasi berbilang utama ialah mengendalikan konflik data.

Konflik berlaku apabila bahagian data yang sama (contohnya, baris tertentu) diubah secara berasingan pada dua nod utama yang berbeza sebelum perubahan tersebut direplikasi antara satu sama lain. Contohnya:

• Pengguna A mengemas kini satu baris pada Nod 1.
• Pengguna B mengemas kini baris yang sama pada Nod 2.

Perubahan yang manakah akhirnya patut diterima?

BDR ialah singkatan bagi Replikasi Dwiarah. BDR ialah sambungan sumber terbuka untuk PostgreSQL yang dibangunkan bagi membolehkan replikasi berbilang utama sebenar.

BDR membolehkan berbilang tika PostgreSQL menerima penulisan secara serentak sambil memastikan datanya disegerakkan. BDR dibina berdasarkan ciri replikasi logik asli PostgreSQL, tetapi menambahkan keupayaan penting untuk pengurusan konflik.

Dalam kluster BDR, setiap nod yang mengambil bahagian bertindak sebagai penerbit dan pelanggan:

• Apabila perubahan (INSERT, UPDATE, DELETE) berlaku pada Nod A, nod tersebut menerbitkan perubahan itu.
• Nod B (dan semua nod lain) menerima perubahan ini sebagai pelanggan lalu menggunakannya pada pangkalan data setempatnya.
• Proses yang sama berlaku secara terbalik: Nod B menerbitkan perubahannya dan Nod A melanggannya.

Komunikasi rakan ke rakan ini memastikan semua nod disegerakkan.

BDR menggunakan mekanisme yang kukuh untuk mengesan apabila konflik berlaku:

• BDR menjejak perubahan menggunakan gabungan pengecam baris dan nombor versi.
• Apabila perubahan yang direplikasi tiba daripada nod lain, BDR menyemak sama ada baris setempat telah diubah secara berasingan sejak keadaan sepunya terakhir.

Jenis konflik yang biasa termasuk UPDATE berbanding UPDATE, UPDATE berbanding DELETE dan INSERT berbanding INSERT (pada kunci unik).

Setelah konflik dikesan, BDR menggunakan strategi penyelesaian yang boleh dikonfigurasikan untuk menentukan versi data yang akan diterima:

• Last-Updater-Wins (LUW): Perubahan dengan cap masa serahan yang paling terkini digunakan dan menulis ganti perubahan bercanggah yang lebih lama.
• First-Updater-Wins (FUW): Perubahan yang diserahkan dahulu diterima, manakala kemas kini bercanggah yang menyusul diketepikan.
• Pengendali Konflik Tersuai: Pembangun boleh mentakrifkan logik mereka sendiri menggunakan fungsi SQL untuk menyelesaikan konflik berdasarkan peraturan perniagaan tertentu.

Menyediakan kluster BDR melibatkan beberapa langkah utama pada setiap tika PostgreSQL yang mengambil bahagian:

• Pasang sambungan BDR.
• Konfigurasikan postgresql.conf untuk replikasi logik dan tetapan khusus BDR.
• Mulakan kluster BDR dan tambahkan setiap nod sebagai rakan.
• Cipta penerbitan untuk jadual atau skema yang ingin anda replikakan.
• Cipta langganan pada nod lain untuk menerima perubahan daripada penerbitan tersebut.

Ini memastikan semua nod saling mengenali dan boleh bertukar data.

BDR amat sesuai untuk keadaan yang memerlukan pangkalan data aktif-aktif dan ketersediaan penulisan yang tinggi:

• Aplikasi Teragih Geografi: Sediakan akses penulisan setempat dengan ketekalan data global.
• Kluster Ketersediaan Tinggi: Kurangkan masa henti semasa kegagalan nod individu dengan membolehkan penulisan diteruskan di tempat lain.
• Pemulihan Bencana: Laksanakan pelan pemulihan bencana yang kukuh dengan berbilang tapak aktif.

BDR sering digunakan dalam persekitaran kompleks yang kritikal kepada misi, iaitu masa henti dan kehilangan data tidak boleh diterima.

Walaupun berkuasa, BDR menambahkan kerumitan operasi:

• Pengurusan Konflik: Memerlukan perancangan teliti tentang strategi penyelesaian untuk mengelakkan hasil data yang tidak dijangka.
• Pemantauan: Anda perlu memantau secara aktif kelewatan replikasi, kadar konflik dan kesihatan nod.
• Perubahan Skema: Memerlukan perubahan DDL (Bahasa Takrifan Data) yang diselaraskan merentasi semua nod untuk mengekalkan ketekalan.

BDR bukan penyelesaian yang boleh terus digunakan dan memerlukan pemahaman yang lebih mendalam tentang seni bina serta kelakuannya.

Replikasi berbilang utama membolehkan penulisan pada berbilang nod pangkalan data, sekali gus meningkatkan ketersediaan dan kebolehskalaan penulisan dengan ketara berbanding persediaan satu utama.

Halangan utama dalam MMR ialah menyelesaikan konflik data, yang berlaku apabila data yang sama diubah secara berasingan pada nod yang berbeza.

Sambungan BDR (Replikasi Dwiarah) PostgreSQL menyediakan keupayaan berbilang utama yang kukuh, termasuk pengesanan konflik lanjutan dan strategi penyelesaian yang boleh disesuaikan seperti Last-Updater-Wins.

Walaupun berkuasa untuk ketersediaan tinggi dan sistem teragih, BDR memerlukan reka bentuk, pemantauan dan pengurusan yang teliti kerana kerumitan bawaannya.