एक विहंगम दृष्टि से, ऐसा प्रतीत होता है कि जब PostgreSQL वर्कलोड को क्लाउड में माइग्रेट करने की बात आती है, तो क्लाउड प्रदाता की पसंद से कोई फर्क नहीं पड़ना चाहिए। लीक से हटकर, PostgreSQL तार्किक प्रतिकृति के माध्यम से, बिना डाउनटाइम के, डेटा को दोहराना आसान बनाता है, हालांकि कुछ प्रतिबंधों के साथ। अपनी सेवा की पेशकश को और अधिक आकर्षक बनाने के लिए क्लाउड प्रदाता इनमें से कुछ प्रतिबंधों पर काम कर सकते हैं। जैसे ही हम उपलब्ध PostgreSQL संस्करणों, संगतता, सीमाओं, सीमाओं और प्रदर्शन में अंतर के बारे में सोचना शुरू करते हैं, यह स्पष्ट हो जाता है कि माइग्रेशन सेवाएं समग्र सेवा पेशकश में प्रमुख कारक हैं। यह अब "हम इसे पेश करते हैं, हम इसे माइग्रेट करते हैं" का मामला नहीं है। यह "हम इसे पेश करते हैं, हम इसे कम से कम सीमाओं के साथ माइग्रेट करते हैं" जैसा हो गया है।
माइग्रेशन छोटे और बड़े संगठनों के लिए समान रूप से महत्वपूर्ण है। यह PostgreSQL क्लस्टर के आकार के बारे में उतना नहीं है, जितना कि स्वीकार्य डाउनटाइम और माइग्रेशन के बाद के प्रयास के बारे में है।
एक रणनीति चुनना
माइग्रेशन रणनीति में डेटाबेस के आकार, स्रोत और लक्ष्य के बीच नेटवर्क लिंक, साथ ही क्लाउड प्रदाता द्वारा पेश किए गए माइग्रेशन टूल को ध्यान में रखा जाना चाहिए।
हार्डवेयर या सॉफ़्टवेयर?
इंटरनेट के शुरुआती दिनों में यूएसबी कुंजियों और डीवीडी को वापस भेजने की तरह, ऐसे मामलों में जहां नेटवर्क बैंडविड्थ वांछित गति से डेटा स्थानांतरित करने के लिए पर्याप्त नहीं है, क्लाउड प्रदाता हार्डवेयर समाधान पेश कर रहे हैं, सक्षम सैकड़ों पेटाबाइट डेटा तक ले जाने के लिए। नीचे तीनों में से प्रत्येक के वर्तमान समाधान दिए गए हैं:
उपलब्ध विकल्पों को दर्शाने वाली Google द्वारा प्रदान की गई एक आसान तालिका:
जीसीपी उपकरण स्थानांतरण उपकरण है
डेटा आकार बनाम नेटवर्क बैंडविड्थ के आधार पर Azure की एक समान अनुशंसा:
Azure उपकरण डेटा बॉक्स है
अपने डेटा माइग्रेशन पेज के अंत में, AWS इस बात की एक झलक प्रदान करता है कि हम क्या उम्मीद कर सकते हैं, साथ ही समाधान की उनकी सिफारिश:
ऐसे मामलों में जहां डेटाबेस का आकार 100GB से अधिक हो और सीमित नेटवर्क बैंडविड्थ AWS एक सुझाव दे हार्डवेयर समाधान।
AWS उपकरण स्नोबॉल एज है
डेटा निर्यात/आयात
डाउनटाइम को सहन करने वाले संगठन, पोस्टग्रेएसक्यूएल द्वारा उपलब्ध कराए गए सामान्य टूल की सरलता से लाभ उठा सकते हैं। हालांकि, एक क्लाउड (या होस्टिंग) प्रदाता से दूसरे क्लाउड प्रदाता को डेटा माइग्रेट करते समय, बाहर निकलने की लागत से सावधान रहें।
एडब्ल्यूएस
माइग्रेशन के परीक्षण के लिए मैंने अपने होम नेटवर्क सर्वर में से एक पर चल रहे अपने नेक्स्टक्लाउड डेटाबेस की स्थानीय स्थापना का उपयोग किया:
postgres=# select pg_size_pretty(pg_database_size('nextcloud_prod'));
pg_size_pretty
----------------
58 MB
(1 row)
nextcloud_prod=# \dt
List of relations
Schema | Name | Type | Owner
--------+-------------------------------+-------+-----------
public | awsdms_ddl_audit | table | s9sdemo
public | oc_accounts | table | nextcloud
public | oc_activity | table | nextcloud
public | oc_activity_mq | table | nextcloud
public | oc_addressbookchanges | table | nextcloud
public | oc_addressbooks | table | nextcloud
public | oc_appconfig | table | nextcloud
public | oc_authtoken | table | nextcloud
public | oc_bruteforce_attempts | table | nextcloud
public | oc_calendar_invitations | table | nextcloud
public | oc_calendar_reminders | table | nextcloud
public | oc_calendar_resources | table | nextcloud
public | oc_calendar_resources_md | table | nextcloud
public | oc_calendar_rooms | table | nextcloud
public | oc_calendar_rooms_md | table | nextcloud
...
public | oc_termsofservice_terms | table | nextcloud
public | oc_text_documents | table | nextcloud
public | oc_text_sessions | table | nextcloud
public | oc_text_steps | table | nextcloud
public | oc_trusted_servers | table | nextcloud
public | oc_twofactor_backupcodes | table | nextcloud
public | oc_twofactor_providers | table | nextcloud
public | oc_users | table | nextcloud
public | oc_vcategory | table | nextcloud
public | oc_vcategory_to_object | table | nextcloud
public | oc_whats_new | table | nextcloud
(84 rows)
The database is running PostgreSQL version 11.5:
postgres=# select version();
version
------------------------------------------------------------------------------------------------------------
PostgreSQL 11.5 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1), 64-bit
(1 row)मैंने AWS DMS द्वारा उपयोग किए जाने के लिए एक PostgreSQL उपयोगकर्ता भी बनाया है जो Amazon RDS में PostgreSQL आयात करने के लिए Amazon की सेवा है:
postgres=# \du s9sdemo
List of roles
Role name | Attributes | Member of
-----------+------------+-------------
s9sdemo | | {nextcloud}AWS DMS कई लाभ प्रदान करता है, ठीक वैसे ही जैसे हम क्लाउड में प्रबंधित समाधान से उम्मीद करते हैं:
- ऑटो-स्केलिंग (केवल संग्रहण, क्योंकि कंप्यूट इंस्टेंस का आकार सही होना चाहिए)
- स्वचालित प्रावधान
- पे-एज़-यू-गो मॉडल
- स्वचालित विफलता
हालांकि, एक लाइव डेटाबेस के लिए डेटा स्थिरता बनाए रखना एक सर्वोत्तम प्रयास है। 100% स्थिरता तभी प्राप्त होती है जब डेटाबेस केवल-पढ़ने के लिए मोड में होता है - यह इस बात का परिणाम है कि तालिका परिवर्तन कैसे कैप्चर किए जाते हैं।
दूसरे शब्दों में, तालिकाओं का समय-समय पर अलग-अलग कटओवर होता है:
जैसा कि क्लाउड में हर चीज के साथ होता है, इसके साथ एक लागत जुड़ी होती है माइग्रेशन सेवा.
माइग्रेशन परिवेश बनाने के लिए, एक प्रतिकृति उदाहरण, एक स्रोत, एक लक्ष्य समापन बिंदु, और एक या अधिक कार्यों को सेटअप करने के लिए प्रारंभ करना मार्गदर्शिका का पालन करें।
प्रतिकृति उदाहरण
एडब्ल्यूएस पर ईसी2 इंस्टेंस से परिचित किसी भी व्यक्ति के लिए प्रतिकृति इंस्टेंस बनाना आसान है:
डिफ़ॉल्ट से एकमात्र परिवर्तन एडब्ल्यूएस डीएमएस 3.3.0 या का चयन करने में था बाद में मेरे स्थानीय PostgreSQL इंजन के 11.5 होने के कारण:
और यहां वर्तमान में उपलब्ध AWS DMS संस्करणों की सूची है:
बड़े इंस्टॉलेशन को भी AWS DMS की सीमाओं पर ध्यान देना चाहिए:
ऐसी कुछ सीमाएं भी हैं जो PostgreSQL के तार्किक प्रतिकृति के परिणाम हैं। प्रतिबंध। उदाहरण के लिए, AWS DMS द्वितीयक वस्तुओं को माइग्रेट नहीं करेगा:
यह उल्लेखनीय है कि PostgreSQL में सभी इंडेक्स सेकेंडरी इंडेक्स होते हैं, और वह कोई बुरी बात नहीं है, जैसा कि इस अधिक विस्तृत चर्चा में बताया गया है।
स्रोत समापन बिंदु
स्रोत समापन बिंदु बनाने के लिए विज़ार्ड का अनुसरण करें:
सेटअप परिदृश्य में एक वीपीसी के लिए नेटवर्क के लिए कॉन्फ़िगरेशन इंटरनेट का उपयोग करना my स्रोत एंडपॉइंट आईपी पते को मेरे आंतरिक सर्वर तक पहुंचने की अनुमति देने के लिए होम नेटवर्क को कुछ बदलावों की आवश्यकता थी। सबसे पहले, मैंने पोर्ट 30485 पर पोर्ट 5432 पर मेरे आंतरिक गेटवे (10.11.11.241) पर ट्रैफ़िक भेजने के लिए एज राउटर (173.180.222.170) पर एक पोर्ट फ़ॉरवर्डिंग बनाया, जहां मैं iptables नियमों के माध्यम से स्रोत आईपी पते के आधार पर पहुंच को ठीक कर सकता हूं। वहां से, नेटवर्क ट्रैफ़िक SSH टनल के माध्यम से PostgreSQL डेटाबेस चलाने वाले वेब सर्वर पर प्रवाहित होता है। वर्णित कॉन्फ़िगरेशन के साथ pg_stat_activity के आउटपुट में client_addr 127.0.0.1 के रूप में दिखाई देगा।
आने वाले ट्रैफ़िक की अनुमति देने से पहले, iptables लॉग ip=3.227.167.58) पर प्रतिकृति उदाहरण से 12 प्रयास दिखाते हैं:
Jan 19 17:35:28 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23973 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0
Jan 19 17:35:29 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23974 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0
Jan 19 17:35:31 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23975 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0
Jan 19 17:35:35 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23976 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0
Jan 19 17:35:48 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4328 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0
Jan 19 17:35:49 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4329 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0
Jan 19 17:35:51 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4330 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0
Jan 19 17:35:55 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4331 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0
Jan 19 17:36:08 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8298 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0
Jan 19 17:36:09 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8299 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0
Jan 19 17:36:11 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8300 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0
Jan 19 17:36:16 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8301 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0स्रोत समापन बिंदु IP पते (3.227.167.58) की अनुमति देने के बाद कनेक्शन परीक्षण सफल होता है और स्रोत समापन बिंदु कॉन्फ़िगरेशन पूर्ण हो जाता है। सार्वजनिक नेटवर्क के माध्यम से यातायात को एन्क्रिप्ट करने के लिए हमारे पास एक एसएसएल कनेक्शन भी है। नीचे दी गई क्वेरी के साथ-साथ AWS कंसोल में PostgreSQL सर्वर पर इसकी पुष्टि की जा सकती है:
postgres=# SELECT datname, usename, client_addr, ssl, cipher, query, query_start FROM pg_stat_activity a, pg_stat_ssl s where a.pid=s.pid and usename = 's9sdemo';
datname | usename | client_addr | ssl | cipher | query | query_start
---------+---------+-------------+-----+--------+-------+-------------
(0 rows)…और फिर AWS कंसोल से कनेक्शन चलाते समय देखें। परिणाम निम्न के जैसा दिखना चाहिए:
postgres=# \watch
Sun 19 Jan 2020 06:50:51 PM PST (every 2s)
datname | usename | client_addr | ssl | cipher | query | query_start
----------------+---------+-------------+-----+-----------------------------+------------------------------------------------------------------------------------+-------------------------------
nextcloud_prod | s9sdemo | 127.0.0.1 | t | ECDHE-RSA-AES256-GCM-SHA384 | select cast(setting as integer) from pg_settings where name = 'server_version_num' | 2020-01-19 18:50:51.463496-08
(1 row)…जबकि AWS कंसोल को सफलता की रिपोर्ट करनी चाहिए:
जैसा कि पूर्वापेक्षाएँ अनुभाग में बताया गया है, यदि हम माइग्रेशन विकल्प पूर्ण लोड चुनते हैं , चल रही प्रतिकृति, हमें PostgreSQL उपयोगकर्ता के लिए अनुमतियों को बदलने की आवश्यकता होगी। इस माइग्रेशन विकल्प के लिए सुपरयुसर विशेषाधिकारों की आवश्यकता होती है, इसलिए मैंने पहले बनाए गए PostgreSQL उपयोगकर्ता के लिए सेटिंग्स को समायोजित किया:
nextcloud_prod=# \du s9sdemo
List of roles
Role name | Attributes | Member of
-----------+------------+-----------
s9sdemo | Superuser | {}उसी दस्तावेज़ में postgresql.conf को संशोधित करने के निर्देश हैं। यहां मूल से एक अंतर है:
--- a/var/lib/pgsql/data/postgresql.conf
+++ b/var/lib/pgsql/data/postgresql.conf
@@ -95,7 +95,7 @@ max_connections = 100 # (change requires restart)
# - SSL -
-#ssl = off
+ssl = on
#ssl_ca_file = ''
#ssl_cert_file = 'server.crt'
#ssl_crl_file = ''
@@ -181,6 +181,7 @@ dynamic_shared_memory_type = posix # the default is the first option
# - Settings -
+wal_level = logical
#wal_level = replica # minimal, replica, or logical
# (change requires restart)
#fsync = on # flush data to disk for crash safety
@@ -239,6 +240,7 @@ min_wal_size = 80MB
#max_wal_senders = 10 # max number of walsender processes
# (change requires restart)
#wal_keep_segments = 0 # in logfile segments; 0 disables
+wal_sender_timeout = 0
#wal_sender_timeout = 60s # in milliseconds; 0 disables
#max_replication_slots = 10 # max number of replication slots
@@ -451,6 +453,7 @@ log_rotation_size = 0 # Automatic rotation of logfiles will
#log_duration = off
#log_error_verbosity = default # terse, default, or verbose messagesअंत में, pg_hba.conf सेटिंग्स को एडजस्ट करना न भूलें ताकि एसएसएल कनेक्शन को प्रतिकृति इंस्टेंस आईपी एड्रेस से अनुमति मिल सके।
अब हम अगले चरण के लिए तैयार हैं।
लक्ष्य समापन बिंदु
लक्ष्य समापन बिंदु बनाने के लिए विज़ार्ड का अनुसरण करें:
यह चरण मानता है कि निर्दिष्ट समापन बिंदु के साथ RDS उदाहरण पहले से मौजूद है खाली डेटाबेस nextcloud_awsdms. डेटाबेस को RDS इंस्टेंस सेटअप के दौरान बनाया जा सकता है।
इस बिंदु पर, यदि AWS नेटवर्किंग सही ढंग से सेटअप है, तो हमें कनेक्शन परीक्षण चलाने के लिए तैयार रहना चाहिए:
पर्यावरण के साथ, अब माइग्रेशन कार्य बनाने का समय आ गया है :
माइग्रेशन टास्क
विज़ार्ड द्वारा कॉन्फ़िगरेशन पूर्ण करने के बाद ऐसा दिखाई देता है:
...और उसी दृश्य का दूसरा भाग:
एक बार जब कार्य शुरू हो जाता है तो हम प्रगति की निगरानी कर सकते हैं—कार्य को खोल सकते हैं विवरण और तालिका सांख्यिकी तक स्क्रॉल करें:
AWS DMS, डेटाबेस तालिकाओं को माइग्रेट करने के लिए कैश्ड स्कीमा का उपयोग कर रहा है। जबकि माइग्रेशन आगे बढ़ता है, हम AWS कंसोल के अलावा स्रोत डेटाबेस और PostgreSQL त्रुटि लॉग पर प्रश्नों को "देखना" जारी रख सकते हैं:
त्रुटियों के मामले में, विफलता स्थिति कंसोल में प्रदर्शित होती है: 
संकेत देखने का एक स्थान CloudWatch है, हालांकि मेरे परीक्षणों के दौरान लॉग अंत में प्रकाशित नहीं हुआ, जो संभवतः एडब्ल्यूएस डीएमएस 3.3.0 के बीटा संस्करण में एक और गड़बड़ हो सकता है क्योंकि यह इस अभ्यास के अंत में निकला:
माइग्रेशन की प्रगति AWS DMS कंसोल में अच्छी तरह से प्रदर्शित होती है:
एक बार माइग्रेशन पूरा हो जाने पर, एक बार और समीक्षा करते हुए, PostgreSQL त्रुटि लॉग , एक आश्चर्यजनक संदेश प्रकट करता है:
ऐसा प्रतीत होता है, कि PostgreSQL 9.6, 10 में pg_class तालिका है नामित कॉलम relhaspkey है, लेकिन 11 में ऐसा नहीं है। और यह AWS DMS 3.3.0 के बीटा संस्करण में गड़बड़ है जिसका मैं पहले उल्लेख कर रहा था।
जीसीपी
Google का दृष्टिकोण ओपन सोर्स टूल PgBouncer पर आधारित है। उत्साह अल्पकालिक था, क्योंकि आधिकारिक दस्तावेज़ीकरण PostgreSQL को एक कंप्यूट इंजन वातावरण में स्थानांतरित करने के बारे में बात करता है।
AWS DMS जैसा दिखने वाला Cloud SQL के लिए माइग्रेशन समाधान खोजने का और प्रयास विफल रहा। डेटाबेस माइग्रेशन रणनीतियों में PostgreSQL का कोई संदर्भ नहीं है:
ऑन-प्रिमाइसेस PostgreSQL इंस्टॉलेशन को सेवाओं का उपयोग करके क्लाउड SQL में माइग्रेट किया जा सकता है Google क्लाउड भागीदारों में से एक।
एक संभावित समाधान PgBouncer to Cloud SQL हो सकता है, लेकिन यह इस ब्लॉग के दायरे में नहीं है।
माइक्रोसॉफ्ट क्लाउड सर्विसेज (Azure)
PostgreSQL के लिए ऑन-प्रिमाइसेस से प्रबंधित Azure डेटाबेस में PostgreSQL वर्कलोड के माइग्रेशन को सुविधाजनक बनाने के लिए Microsoft Azure DMS प्रदान करता है, जो दस्तावेज़ीकरण के अनुसार न्यूनतम डाउनटाइम के साथ माइग्रेट करने के लिए उपयोग किया जा सकता है। ट्यूटोरियल डीएमएस का उपयोग करके ऑनलाइन पोस्टग्रेएसक्यूएल के लिए एज़्योर डेटाबेस में पोस्टग्रेएसक्यूएल माइग्रेट करें इन चरणों का विस्तार से वर्णन करता है।
Azure DMS दस्तावेज़ीकरण PostgreSQL वर्कलोड को Azure में माइग्रेट करने से जुड़े मुद्दों और सीमाओं पर बहुत विस्तार से चर्चा करता है।
AWS DMS से एक उल्लेखनीय अंतर मैन्युअल रूप से स्कीमा बनाने की आवश्यकता है:
इसका एक डेमो भविष्य के ब्लॉग का विषय होगा। बने रहें।
