Ada berbagai pendekatan untuk memperbarui PostgreSQL, tetapi beberapa mengarah pada downtime. Jika Anda ingin menghindari downtime, gunakan replikasi untuk meningkatkan - logis atau fisik (streaming), tergantung pada skenario. Pada artikel ini, kita akan melihat perbedaan antara replikasi logis dan fisik dalam PostgreSQL. Lalu kami akan berbicara secara rinci cara memperbarui versi menggunakan replikasi logis sambil menghindari waktu henti aplikasi. Artikel selanjutnya akan membahas replikasi fisik.
Pada artikel sebelumnya, kita telah berbicara tentang metode untuk memperbarui PostgreSQL ( Memutakhirkan PostgreSQL menggunakan pg_dumpall dan Memutakhirkan PostgreSQL menggunakan pg_dump / pg_restore ) sebagai bagian dari seri Upgrade atau Migrasi Versi PostgreSQL Lama . Tetapi kedua metode ini tidak mengecualikan downtime.
Jenis Replikasi Logis
Di sini kita membahas 2 jenis replikasi:
- Replikasi antara PostgreSQL 10 dan 11 menggunakan replikasi logis bawaan.
- Replikasi antara PostgreSQL 9.4 (atau sebelum PG 11) dan PostgreSQL 11 menggunakan ekstensi pglogical .
Untuk meminimalkan waktu henti, Anda dapat memutakhirkan menggunakan replikasi. Ketika semua data yang relevan direplikasi ke server PostgreSQL terbaru lainnya, Anda cukup mentransfer aplikasi ke server baru dengan downtime minimal - walaupun, tentu saja, semua itu tergantung pada kompleksitas tumpukan aplikasi.
Replikasi logis dalam PostgreSQL memungkinkan pengguna untuk mereplikasi tabel secara selektif dan membuka server cadangan untuk operasi penulisan. Replikasi fisik dalam PostgreSQL dilakukan dalam blok. Dalam hal ini, setiap database dalam panduan direplikasi ke server cadangan, tidak dapat diakses untuk menulis operasi. Selanjutnya, kita akan memanggil streaming replikasi fisik.
Saat menggunakan replikasi logis pada server siaga, Anda dapat mengaktifkan replikasi dari beberapa master. Ini berguna dalam situasi di mana Anda perlu mereplikasi data dari beberapa database PostgreSQL (OLTP) ke server PostgreSQL tunggal untuk pelaporan dan penyimpanan data.
Keuntungan utama dari replikasi logis daripada streaming adalah bahwa dengan replikasi logis, Anda dapat mereplikasi perubahan dari versi PostgreSQL lama ke yang baru. Replikasi aliran hanya berfungsi ketika master dan server cadangan memiliki versi utama yang sama. Idealnya, versi tambahan juga harus cocok.
Replikasi antara PostgreSQL 10 dan 11
Dimulai dengan PostgreSQL 10, replikasi logis tersedia secara default. Oleh karena itu, Anda dapat dengan mudah mereplikasi database PostgreSQL 10 di PostgreSQL 11. Replikasi logis menggunakan model publikasikan dan berlangganan. Node yang mengirimkan perubahan menjadi penerbit. Dan node yang berlangganan perubahan ini menjadi pelanggan. Mungkin ada beberapa langganan per publikasi.
Posting
Publikasi adalah serangkaian perubahan yang dibuat oleh sekelompok tabel. Ini disebut set perubahan atau set replikasi . Publikasi hanya dapat berisi tabel, tetapi bukan objek lain. DML dalam tabel ini dapat direplikasi, tetapi DDL tidak bisa.
Dalam publikasi, Anda dapat memilih tipe DML mana yang akan direplikasi: INSERT, DELETE, UPDATE, atau ALL. Secara default, ALL dipilih. Tabel harus memiliki pengidentifikasi replika untuk mereplikasi operasi UPDATE dan DELETE kepada pelanggan. Pengidentifikasi replika membantu Anda menemukan baris yang diperbarui atau dihapus.
Kunci utama tabel adalah pengidentifikasi replika default. Atau Anda dapat membuat pengidentifikasi sebagai indeks unik dengan nilai TIDAK NULL. Jika Anda tidak memiliki kunci utama atau indeks unik tanpa nilai NULL, atur replica_identity ke FULL. Dalam hal ini, Postgres menggunakan seluruh string sebagai kuncinya. Tapi ini tidak terlalu rasional.
Jika tabel tanpa kunci utama dan pengidentifikasi replika ditambahkan ke publikasi secara default setelah operasi UPDATE atau DELETE, kesalahan dapat terjadi.
Berlangganan
Pelanggan dapat berlangganan satu publikasi atau lebih. Sebelum menambahkan langganan, pastikan bahwa tabel yang direplikasi dibuat pada node pelanggan. Untuk melakukan ini, hanya buang skema dari penerbit ke pelanggan.
Contoh Replikasi Logis
Contoh berikut ini menjelaskan replikasi logis hanya antara PostgreSQL versi 10 dan 11.
Buat publikasi di situs penerbit. Tambahkan semua atau hanya beberapa tabel ke publikasi.
-- For adding ALL Tables in Database CREATE PUBLICATION percpub FOR ALL TABLES; -- For adding Selected Tables in Database CREATE PUBLICATION percpub FOR TABLE scott.employee scott.departments;
Di situs pelanggan, buat berlangganan ke publikasi ini. Lakukan dump DDL dari tabel ke pelanggan sebelum membuat langganan, seperti yang disebutkan di atas.
$ pg_dump -h publisher_server_ip -p 5432 -d percona -Fc -s -U postgres | pg_restore -d percona -h subscriber_node_ip -p 5432 -U postgres CREATE SUBSCRIPTION percsub CONNECTION 'host=publisher_server_ip dbname=percona user=postgres password=secret port=5432' PUBLICATION percpub;
Perintah ini juga menyalin data yang ada di tabel. Jika Anda ingin menonaktifkan penyalinan data yang ada, gunakan perintah berikut dan hanya perubahan pada penerbit yang akan disalin.
CREATE SUBSCRIPTION percsub CONNECTION 'host=publisher_server_ip dbname=percona user=postgres password=oracle port=5432' PUBLICATION percpub WITH (copy_data = false);
Lacak replikasi menggunakan perintah berikut di simpul penerbit:
$ psql \x select * from pg_stat_replication;
Replikasi antara PostgreSQL 9.4 dan PostgreSQL 11
Apa yang harus dilakukan dengan versi sebelum PostgreSQL 10? Untuk versi 9.4 hingga 11 ada ekstensi khusus - pglogical . Menggunakan pglogical, Anda dapat mereplikasi PostgreSQL 9.4 ke PostgreSQL 11 dengan dua cara.
Berikut ini adalah petunjuk umum untuk mengatur replikasi antara PG 9.4 dan PG 11 menggunakan ekstensi pglogical .
Langkah 1. Pertimbangkan pgserver_94 sebagai server sumber dengan basis data percona_94 pada PostgreSQL 9.4. Buat ekstensi berikut.
kode
[pgserver_94:] $psql -d percona_94 -c "CREATE EXTENSION pglogical_origin" CREATE EXTENSION [pgserver_94:] $psql -d percona_94 -c "CREATE EXTENSION pglogical" CREATE EXTENSION
Langkah 2. Sekarang tambahkan semua atau beberapa tabel ke skema atau beberapa skema untuk replikasi. Dalam contoh berikut, Anda melihat kesalahan karena salah satu tabel tidak memiliki kunci utama.
[pgserver_94:] $psql -d percona_94 psql (9.4.21) Type "help" for help. percona_94=# SELECT pglogical.create_node(node_name := 'provider1',dsn := 'host=192.168.0.24 port=5432 dbname=percona_94'); create_node ------------- 2976894835 (1 row) percona_94=# SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']); ERROR: table pgbench_history cannot be added to replication set default DETAIL: table does not have PRIMARY KEY and given replication set is configured to replicate UPDATEs and/or DELETEs HINT: Add a PRIMARY KEY to the table percona_94=# ALTER TABLE pgbench_history ADD PRIMARY KEY (tid,aid,delta); ALTER TABLE percona_94=# SELECT pglogical.replication_set_add_all_tables('default', ARRAY['public']); replication_set_add_all_tables -------------------------------- t (1 row)
Langkah 3. Pada node pelanggan, yaitu, dalam database PostgreSQL 11, jalankan perintah berikut.
[pgserver_11:] $psql -d percona_11 psql (11.2) Type "help" for help. percona_11=# SELECT pglogical.create_node(node_name := 'subscriber1',dsn := 'host=127.0.0.1 port=5432 dbname=percona_11 password=secret'); create_node ------------- 330520249 (1 row) percona_11=# SELECT pglogical.create_subscription(subscription_name := 'subscription1',provider_dsn := 'host=192.168.0.24 port=5432 dbname=percona_94 password=secret'); create_subscription --------------------- 1763399739 (1 row)
Langkah 4. Kemudian periksa status replikasi dengan mengirimkan permintaan ke beberapa tabel, yang selalu diperbarui:
percona_11=# select * from pglogical.local_sync_status; sync_kind | sync_subid | sync_nspname | sync_relname | sync_status | sync_statuslsn -----------+------------+--------------+------------------+-------------+---------------- f | 1763399739 | public | pgbench_accounts | r | 0/2EB7D48 f | 1763399739 | public | pgbench_history | r | 0/2EB7D48 f | 1763399739 | public | pgbench_tellers | r | 0/2EB7D48 f | 1763399739 | public | pgbench_branches | r | 0/2EB7D48 d | 1763399739 | | | r | 0/0 (5 rows) percona_11=# select * from pglogical.subscription; sub_id | sub_name | sub_origin | sub_target | sub_origin_if | sub_target_if | sub_enabled | sub_slot_name | sub_rep lication_sets | sub_forward_origins | sub_apply_delay ------------+---------------+------------+------------+---------------+---------------+-------------+----------------------------------------+---------------- -----------------------+---------------------+----------------- 1763399739 | subscription1 | 2976894835 | 330520249 | 2402836775 | 2049915666 | t | pgl_percona_11_provider1_subscription1 | {default,defaul t_insert_only,ddl_sql} | {all} | 00:00:00 (1 row)
Pemilihan Kunci Utama
Pada langkah kedua, Anda melihat bagaimana semua tabel dalam skema publik ditambahkan ke set replikasi dengan membuat kunci utama untuk tabel yang tidak memiliki satu. Saya mungkin telah memilih kunci utama yang salah untuk tabel ini, tetapi ini hanya untuk demonstrasi. Saat memilih kunci utama, pastikan itu benar. Itu harus unik dan menggunakan kolom yang tidak mengandung nilai NULL. Jika Anda tidak menemukan kunci utama yang benar, ini dapat menyebabkan penghentian aplikasi. Berikut adalah contoh kesalahan yang mungkin terjadi:
[pgserver_94:] $pgbench -c 10 -T 300 -n percona_94 Client 7 aborted in state 12: ERROR: duplicate key value violates unique constraint "pgbench_history_pkey" DETAIL: Key (tid, aid, delta)=(7, 63268, 2491) already exists.
Inilah cara menggunakan pglogical untuk membuat replikasi antara versi PostgreSQL lama dan baru. Setelah mengatur replikasi, cukup alihkan aplikasi ke versi terbaru sehingga downtime menjadi minimal.