آموزش به روزرسانی PostgreSQL 10

/0 دیدگاه /در /توسط

حالا که با ویژگی جدید آپدیت PostgreSQL آشنا شدید، میتوانیم از آن برای حل مسئله به روز رسانی استفاده کنیم.
برای آنکه همانند سازی منطقی را به راه بیاندازیم بایستی مراحل زیر صورت گیرد:
گره ناشر را پیکربندی کنیم.
گره سابسکرایبر را پیکربندی کنیم
یوزر سابسکرایبر درست کنیم
یک انتشار درست کنیم
ساختار جدول را در subscriber ایجاد کنیم
اشتراک ایجاد کنیم
وضعیت همانند سازی را چک کنیم

برای شروع، در سمت ناشر پارامترهای زیر را در فایل postgresql.file پیکربندی میکنیم.
• Listen-addresses : به چه ip هایی گوش بدهد (برای همه از ‘*’ استفاده میکنیم)
• Wal-level : تعیین میکند که چه مقدار اطلاعات در wal نوشته شده است، ما قصد داریم آن را به صورت منطقی تنظیم کنیم.
• Max-replication-slots : حداکثر تعداد slot همانند سازی که یک سرور میتواند پشتیبانی کند را تعیین میکند و باید حداقل تعداد subscription هایی که قرار است کانکت شوند باشد، به علاوه تعدادی ذخیره برای هماهنگ سازی جدول ها.
• Max-wal-senders : حداکثر تعداد اتصالات همزمان را از سرورهای آماده به کاررا تعیین میکند.

به خاطر داشته باشید که بعضی از این تنظیمات نیاز به ری استارت شدن سرویس PostgreSQL دارند.
همچنین فایل Pg_hba.conf نیاز به تنظیماتی دارد؛ باید به یوزر همانندسازی اجازه ی دسترسی به دیتابیس را بدهیم.
بنابراین باید Publisher خود را به صورت زیر پیکربندی کنیم:

:postgresql.conf

'*' = listen_addresses 
wal_level = logical 
max_wal_senders = 8 max_replication_slots = 4

:pg_hba.conf

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host     all     rep     192.168.100.144/32     md5

کاربر را به rep تغییر میدهیم، که برای replication از آن استفاده خواهیم کرد، و همچنین ip را به
/32 192.168.100.144 که با PostgreSQL11 همخوانی داشته باشد.

در سمت Subscriber نیز نیاز به تعیین max-replication-slots داریم که در این مورد باید حداقل به تعداد Subscription هایی که به subscriber اضافه میشود باشد.
پارامترهای دیگری که باید تعیین شوند نیز در زیر آورده شده است:
• max-logical-replication-workers : حداکثر تعداد worker های همانندسازی منطقی را تعیین میکند، که شامل worker های متقاضی و همچنین worker های همسان سازی جداول است. Worker های همانندسازی منطقی از استخری که توسط max_worker_processes ایجاد شده، گرفته میشوند.که باید به تعداد subscription ها باشد، و همچنین یک تعداد ذخیره برای همانندسازی جدول.
• Max-worker-processes : حداکثر تعداد فرایندهایی که یک سیستم میتواند ساپورت کند را تعیین میکند.

حال بایستی subscriber خود را به صورت زیر پیکربندی کنیم:

 

:postgresql.conf

listen_addresses = '*'
max_replication_slots = 4
max_logical_replication_workers = 4
max_worker_processes = 8

از آن جا که PostgreSQL11 به زودی به عنوان master قرار میگیرد باید پارامترهای wal_mode و archive_mode را هم اکنون اضافه کرده تا بعد نیازی به ری استارت سرویس نداشته باشیم.

 

wal_level = logical 
archive_mode = on

 

این پارامترها میتوانند در هنگام اضافه کردن یک replication slave دیگر و یا وقتی از بک آپ PITR استفاده میکنید مفید باشد.

در publisher باید کاربری را ایجاد کنیم که با subscriber ما اتصال برقرار کند.

 

world=# CREATE ROLE rep WITH LOGIN PASSWORD '*****' REPLICATION; 
CREATE ROLE

نقشی که برای اتصال replication از آن استفاده میشود باید دارای ویژگی REPLICATION باشد، دسترسی به نقش باید در pg_hba.conf پیکربندی شده باشد و دارای ویژگی Login باشد.

برای اینکه بتوانید داده های اولیه را کپی کنید، نقش مورد استفاده در اتصال همانندسازی باید از امتیاز SELECT برخوردار باشد.

 

world=# GRANT SELECT ON ALL TABLES IN SCHEMA public to rep;
GRANT

انتشار pub1 برای تمامی جداول در گره Publisher ایجاد میکنیم.

world=# CREATE PUBLICATION pub1 FOR ALL TABLES; 
CREATE PUBLICATION

کاربری که یک publication ایجاد میکند باید از امتیاز CREATE در دیتابیس بهره مند باشد، اما برای ایجاد یک publication که تمامی تمامی جداول را به صورت اتوماتیک نشر دهد کاربر باید از نوع Superuser باشد.

 

برای تایید publication ایجاد شده از کاتالوگ pg_publication استفاده میکنیم، این کاتالوگ شامل تمامی اطلاعات مربوط به publication ها در دیتابیس است.

 

world=# SELECT * FROM pg_publication;
-[ RECORD 1 ]+------
pubname      | pub1
pubowner     | 16384
puballtables | t
pubinsert    | t
pubupdate    | t
pubdelete    | t
  • Pubname : نام انتشار را نشان میدهد
  • Pubowner : دارنده ی publication را نشان میدهد
  • Puballtables : اگر مقدار true داشته باشد، این انتشار شامل تمام جداول دیتابیس خواهد شد
  • Pubinsert : اگر مقدار true داشته باشد، عملیات های INSERT برای جداول در publication ها جایگزین میشوند.
  • Pubupdate : اگر مقدار true داشته باشد، عملیات های INSERT برای جداول در publication ها جایگزین میشوند.
  • Pubdelete : اگر مقدار true داشته باشند، عملیات های DELETE برای جداول در publication ها جایگزین میشوند.

 

از آنجایی که الگو همانند سازی نمیشود بایستی از postgreSQL10 بک آپ تهیه کرده و در postgreSQL11 پیاده کنیم، از آنجا که اطلاعات اصلی در همان انتقال اولیه همانندسازی میشوند، این بک آپ فقط برای scheme (الگو) به کار میرود.

در PostgreSQL10 :

$ pg_dumpall -s > schema.sql

در PostgreSQL11 :

$ psql -d postgres -f schema.sql

وقتی از پیاده سازی الگو در PostgreSQL11 مطمئن شدیم، یک subscription با مقادیری که با محیط جدیدمان مطابقت دارد میسازیم

world=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=192.168.100.143 dbname=world user=rep password=*****' PUBLICATION pub1; 
NOTICE:  created replication slot "sub1" on publisher CREATE SUBSCRIPTION

دستور بالا پروسه ی همانند سازی را آغاز کرده که محتویات جدول اولیه از جداول موجود در publication را همزمان میکند و سپس همانندسازی تغییرات افزایشی در آن جداول را شروع میکند.
کاربری که subscription را میسازد باید superuser باشد.

برای تایید subscription ساخته شده میتوانیم از کاتالوگ pg_stat_subscription استفاده کنیم.

 

world=# SELECT * FROM pg_stat_subscription; 
-[ RECORD 1 ]---------+------------------------------ subid                 | 16428 subname               | sub1 pid                   | 1111 
relid                 | received_lsn          | 0/172AF90 
last_msg_send_time    | 2018-12-05 22:11:45.195963+00 
last_msg_receipt_time | 2018-12-05 22:11:45.196065+00 
latest_end_lsn        | 0/172AF90 
latest_end_time       | 2018-12-05 22:11:45.195963+00

• Subid : OID سابسکریپشن
• Subname : نام سابسکریپشن
• Pid :شناسه پردازش
• Relid : OID از رابطه ای که worker همزمان میکند، که برای worker متقاضی تهی است.
• Received_lsn : اخرین مکان ورودی به سیستم، مقدار اولیه این فیلد 0 است.
• Last_msg_send_time : زمان ارسال اخرین پیام دریافت شده از WAL Sender
• Last_msg_reciept_time : زمان دریافت اخرین پیام دریافت شده از WAL Sender
• Latest_end_lsn : اخرین مکان ورود به سیستم که به WAL Sender گزارش شده است.
• Latest_end_time : زمان اخرین مکان ورود به سیستم که به WAL Sender گزارش شده است.

برای تایید وضعیت همانند سازی در master از pg_stat_replication استفاده میکنیم :

 

world=# SELECT * FROM pg_stat_replication; 
-[ RECORD 1 ]----+------------------------------ 
pid              | 1178 
usesysid         | 16427 usename          | rep application_name | sub1 client_addr      | 192.168.100.144 client_hostname  | client_port      | 58270 backend_start    | 2018-12-05 22:11:45.097539+00 backend_xmin     | state            | streaming
sent_lsn         | 0/172AF90
write_lsn        | 0/172AF90 flush_lsn        | 0/172AF90 replay_lsn       | 0/172AF90 write_lag        | flush_lag        |
replay_lag       | sync_priority    | 0
sync_state       | async

• Pid : شناسه پردازش فرآیند WAL SENDER
• Usesysid : OID کاربر وارد شده به پروسه ی WAL
• Usename : نام کاربر وارد شده به پروسه WAL
• Application_name : نام اپلیکیشن متصل به پروسه WAL
• Client_addr : آدرس IP کلاینت متصل به WAL. اکر مقدار این فیلد Null باشد نشان میدهد که کاربر توسط یک سوکت Unix بر روی سرور کانکت شده است.
• Client_hostname : نام هاست کاربر متصل
• Client_Port : شماره پورت TCP که کاربر برای اتصال با WAL استفاده میکند؛ که در صورت استفاده از سوکت Unix مقداری برابر -1 دارد.
• Backend_start : زمانی که پردازش اغاز شده است.
• State : حالت کنونی WAL که مقادیر آن میتواند : startup,catchup,streaming,backup و stopping باشد.
• Sent_lsn : آخرین مکان ورود به سیستم در این اتصال
• Write_lsn : آخرین مکان ورود به سیستم که توسط سرور آماده به کار بر روی دیسک نوشته شده است.
• Flushed_lsn : آخرین مکان ورود به سیستم که توسط سرور اماده به کار آماده شده است.
• Write_lag : مدت زمان بین آپدیت آخرین WAL به صورت محلی و دریافت اعلاناتی که توسط سرور آماده به کار نوشته شده است(اما هنوز به روز رسانی و عملی نشده است)
• Flush_lag : مدت زمان بین آپدیت آخرین WAL به صورت محلی و دریافت اعلاناتی که توسط سرور آماده به کار نوشته شده است ( به روز رسانی شده اما عملی نشده)
• Replay_lag : مدت زمان بین آپدیت آخرین WAL به صورت محلی و دریافت اعلاناتی که توسط سرور آماده به کار نوشته شده است ( هم به روز رسانی شده و هم عملی شده )
• Sync_priority : اولویت انتخاب یک سرور به عنوان سرور استندبای آماده به کار
• Sync_state : حالت هم زمان این سرور استندبای؛ مقادیر این حالت میتوانند : async,potential,sync,quorum باشند

 

برای اطمینان از اتمام انتقال اولیه میتوانیم Subscriber Log را مشاهده کنیم :

 

2018-12-05 22:11:45.096 UTC [1111] LOG:  logical replication apply worker for subscription "sub1" has started
2018-12-05 22:11:45.103 UTC [1112] LOG:  logical replication table synchronization worker for subscription "sub1", table "city" has started
2018-12-05 22:11:45.114 UTC [1113] LOG:  logical replication table synchronization worker for subscription "sub1", table "country" has started
2018-12-05 22:11:45.156 UTC [1112] LOG:  logical replication table synchronization worker for subscription "sub1", table "city" has finished
2018-12-05 22:11:45.162 UTC [1114] LOG:  logical replication table synchronization worker for subscription "sub1", table "countrylanguage" has started
2018-12-05 22:11:45.168 UTC [1113] LOG:  logical replication table synchronization worker for subscription "sub1", table "country" has finished
2018-12-05 22:11:45.206 UTC [1114] LOG:  logical replication table synchronization worker for subscription "sub1", table "countrylanguage" has finished

و یا چک کردن متغیر srsubstate بر روی کاتالوگ pg_subscribtion_rel؛ این کاتالوگ شامل تمامی حالات replication در هر subsctiption است.

 

world=# SELECT * FROM pg_subscription_rel;
-[ RECORD 1 ]---------
srsubid | 16428
srrelid | 16387
srsubstate | r
srsublsn | 0/172AF20
-[ RECORD 2 ]---------
srsubid | 16428
srrelid | 16393
srsubstate | r
srsublsn | 0/172AF58
-[ RECORD 3 ]---------
srsubid | 16428
srrelid | 16400
srsubstate | r
srsublsn | 0/172AF90
  • Srsubid : ارجاع به اشتراک دارد.
  • Srrelid : ارجاع به رابطه دارد.
  • Srsubstate : I = initialize, d = data is being copied, s = synchronized, r = ready
  • Srsublsn : LSN پایانی برای حالات s و r

 

میتوانیم بعضی از رکوردها را به صورت تست در postgreSQL10 وارد کرده و از اینکه آنها را در PostgreSQL11 داریم اطمینان حاصل کنیم.

 

PostgreSQL 10:

world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5001,'city1','USA','District1',10000); INSERT 0 1 
world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5002,'city2','ITA','District2',20000); 
INSERT 0 1 world=# INSERT INTO city (id,name,countrycode,district,population) VALUES (5003,'city3','CHN','District3',30000); 
INSERT 0 1

PostgreSQL 11 :

world=# SELECT * FROM city WHERE id>5000;  
 id  | name  | countrycode | district  | population 
------+-------+-------------+-----------+------------  
5001 | city1 | USA         | District1 |      10000  
5002 | city2 | ITA         | District2 |      20000 
5003 | city3 | CHN         | District3 |      30000 
(3 rows)

اکنون همه چیز آماده ی وصل کردن اپلیکیشن ما به PostgreSQL11 است؛ اما باید اول مطمئن شویم که در همانندسازی (replication) خطا و یا کندی وجود ندارد.

بر روی master :

 

world=# SELECT  application_name,  pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) lag FROM pg_stat_replication; 
-[ RECORD 1 ]----+----- 
application_name | sub1 lag              | 0

حال بایستی endpoint اپلیکیشن را به PostgreSQL11 تغییرداده و یا در صورتی که load balancer در اختیار داریم آن را به PostgreSQL11 انتقال دهیم.
اگر از load balancer ای مانند HAProxy استفاده میکنید میتوانیم همانند شکل زیر به صورت فعال در PostgreSQl10 و به صورت بک آپ در PostgreSQL11 استفاده کنیم.

 

در پایان میتوانید subscription را از master جدیدتان در PostgreSQL11 پاک کنید:

world=# DROP SUBSCRIPTION sub1; 
NOTICE:  dropped replication slot "sub1" on publisher 
DROP SUBSCRIPTION

و مطمئن شوید که کاملا پاک شده است :

 

world=# SELECT * FROM pg_subscription_rel; 
(0 rows)
world=# SELECT * FROM pg_stat_subscription;
(0 rows)

محدودیت ها :
قبل از استفاده از همانند سازی منطقی، محدودیت های زیر را در نظر داشته باشید:

دستورات پایگاه داده و دستورات DDL همانند سازی نمیشوند، طرح اولیه را میتوان با استفاده از pg_dump نسخه برداری کرد.

داده های دنباله ای نیز همانندسازی نمیشوند؛ داده های موجود در ستون های سریالی یا هویتی که توسط دنباله ها پشتیبانی میشوند به عنوان بخشی ازجدول همانند سازی میشوند، اما خود دنباله ها همچنان مقدار شروع را در subscriber نشان میدهد.

همانند سازی دستورات TRUNCATE پشتیبانی میشود، اما در هنگام کوتاه کردن گروه های جداول متصل به کلیدهای خارجی باید دقت بیشتری انجام شود.

هنگام تکرار یک عمل کوتاه، subscriber همان گروه جداول را که در ناشر کوتاه شده است یا به طور ضمنی توسط CASCADE جمع آوری شده است، منهای جداول که جزِئی از اشتراک نیستند را کوتاه میکند.

اشیا بزرگ همانند سازی نمیشوند، هیچ راه حل دیگری به غیر از ذخیره کردن داده ها در جداول نرمال وجود ندارد؛ تکثیر فقط از جداول پایه تا جداول پایه امکان پذیر است.
یعنی جداول موجود در انتشار و در قسمت اشتراک باید جداول نرمال باشند و نه view ها یا materialized view, partition root tables, foreign tables

در مورد پارتیشن ها میتوانید یک سلسله مراتب پارتیشن را یک به یک تکرار کنید اما در حال حاضر نمیتوانید به یک پارتیشن متفاوت replicate کنید.

در این آموزش ما سعی کردیم نحوه آپگرید کردن PostgreSQL10 به ورژن بعدی آن را به صورت جامع تشریح کنیم، امیدواریم از این مطلب حداکثر استفاده را برده باشید.

0 پاسخ

دیدگاه خود را ثبت کنید

تمایل دارید در گفتگوها شرکت کنید؟
در گفتگو ها شرکت کنید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *