عندما اخترنا أداة لمعالجة البيانات الضخمة ، فكرنا في خيارات مختلفة - سواء كانت ملكية مفتوحة المصدر. قمنا بتقييم إمكانيات التكيف السريع وإمكانية الوصول ومرونة التقنيات. بما في ذلك الهجرة بين الإصدارات. نتيجة لذلك ، اخترنا حل Greenplum مفتوح المصدر ، والذي يلبي متطلباتنا على أفضل وجه ، ولكنه يتطلب حل مشكلة واحدة مهمة.
الحقيقة هي أن إصدارات ملفات قاعدة بيانات Greenplum 4 و 5 غير متوافقة مع بعضها البعض ، وبالتالي فإن الترقية البسيطة من إصدار إلى آخر أمر مستحيل. لا يمكن إجراء ترحيل البيانات إلا من خلال تحميل البيانات وتنزيلها. في هذا المنشور سأتحدث عن الخيارات الممكنة لهذه الهجرة.
تقييم خيارات الترحيل
pg_dump & psql (أو pg_restore)
يكون هذا بطيئًا جدًا عندما يتعلق الأمر بالعشرات من تيرابايت ، حيث يتم تحميل جميع البيانات وتنزيلها عبر العقد الرئيسية. ولكن بسرعة كافية لترحيل DDL والجداول الصغيرة. يمكنك تحميل الملف على حد سواء وتشغيل pg_dump و psql في نفس الوقت من خلال توجيه الإخراج على كتلة مصدر ومجموعة كتلة. يتم تحميل pg_dump ببساطة إلى ملف واحد يحتوي على كل من أوامر DDL وأوامر نسخ COPY. البيانات التي تم الحصول عليها يمكن معالجتها بسهولة ، والتي سوف تظهر أدناه.
gptransfer
يتطلب الإصدار Greenplum 4.2 أو الأحدث. من الضروري أن تعمل الكتلة المصدر والكتلة الوجهة في وقت واحد. أسرع طريقة لترحيل جداول البيانات الكبيرة للإصدار مفتوح المصدر. ولكن هذه الطريقة بطيئة للغاية لنقل الجداول الفارغة والصغيرة بسبب ارتفاع النفقات العامة.
يستخدم gptransfer pg_dump لنقل DDL و gpfdist لنقل البيانات. يجب أن لا يقل عدد القطع الأساسية في الكتلة الوجهة عن مقطع المضيف على الكتلة المصدر. من المهم مراعاة ذلك عند إنشاء مجموعات "الصندوق الرمل" ، وما إذا كان سيتم نقل البيانات من المجموعات الرئيسية إليها ، ومن المخطط استخدام الأداة المساعدة gptransfer. حتى لو كانت مضيفات الشرائح قليلة ، يمكنك نشر العدد المطلوب من الأجزاء على كل منها. قد يكون عدد الأجزاء في الكتلة الوجهة أقل من الكتلة المصدر ، ولكن هذا
سيؤثر سلبًا على سرعة نقل البيانات. بين الكتل ، يجب تكوين مصادقة ssh على الشهادات.
هذا هو مخطط الوضع السريع عندما يكون عدد القطع في الكتلة الوجهة أكبر من أو يساوي الرقم في الكتلة المصدر. يتم عرض تشغيل الأداة المساعدة نفسها في الرسم التخطيطي على العقدة الرئيسية في نظام الاستقبال. في هذا الوضع ، يتم إنشاء جدول كتابة خارجي على الكتلة المصدر ، الذي يكتب البيانات على كل قطعة إلى توجيه الإخراج المسمى. يتم تنفيذ الأمر INSERT INTO writable_external_table SELECT * FROM source_table. تتم قراءة البيانات من توجيه الإخراج المسمى بواسطة gpfdist. يتم إنشاء جدول خارجي أيضًا على نظام المجموعة الوجهة ، للقراءة فقط. يشير الجدول إلى البيانات التي يوفرها gpfdist عبر
البروتوكول الذي يحمل نفس الاسم . يتم تنفيذ الأمر INSERT INTO target_table SELECT * FROM external_gpfdist_table. يتم إعادة توزيع البيانات تلقائيًا بين مقاطع الكتلة الوجهة.
وهذا هو مخطط الوضع البطيء ، أو ، كما يعطي gptransfer نفسه ، الوضع القياسي. يتمثل الاختلاف الرئيسي في أنه في كل مضيف قطعة لمجموعة الكتلة المصدر ، يتم إطلاق زوج gpfdist لجميع شرائح مضيف القطاع. يشير جدول السجل الخارجي إلى gpfdist الذي يعمل كمستقبل للبيانات. علاوة على ذلك ، إذا تم الإشارة إلى عدة قيم للكتابة في معلمة LOCATION بالجدول الخارجي ، فسيتم توزيع الأجزاء بالتساوي بواسطة gpfdist عند كتابة البيانات. يتم تمرير البيانات بين gpfdist على قطعة المضيف عبر توجيه إخراج مسمى. لهذا السبب ، تكون سرعة نقل البيانات أقل ، لكنها لا تزال تتوقف بشكل أسرع عن نقل البيانات عبر العقدة الرئيسية فقط.
عند ترحيل البيانات من Greenplum 4 إلى Greenplum 5 ، يجب تشغيل gptransfer على العقدة الرئيسية للكتلة الوجهة. إذا قمنا بتشغيل gptransfer على نظام المجموعة المصدر ، فسنحصل على خطأ عدم وجود حقل
san_mounts في الجدول
pg_catalog.gp_segment_configuration :
gptransfer -t big_db.public.test_table --dest-host=gpdb-target-master.local --dest-database=big_db --source-map-file=/data/master/gpseg-1/host_and_IP_segments --batch-size=10 --sub-batch-size=50 --truncate 20190109:12:46:13:010893 gptransfer:gpdb-source-master.local:gpadmin-[INFO]:-Starting gptransfer with args: -t big_db.public.test_table --dest-host=gpdb-target-master.local --dest-database=big_db --source-map-file=/data/master/gpseg-1/host_and_IP_segments --batch-size=10 --sub-batch-size=50 --truncate 20190109:12:46:13:010893 gptransfer:gpdb-source-master.local:gpadmin-[INFO]:-Validating options... 20190109:12:46:13:010893 gptransfer:gpdb-source-master.local:gpadmin-[INFO]:-Retrieving configuration of source Greenplum Database... 20190109:12:46:13:010893 gptransfer:gpdb-source-master.local:gpadmin-[INFO]:-Retrieving configuration of destination Greenplum Database... 20190109:12:46:14:010893 gptransfer:gpdb-source-master.local:gpadmin-[CRITICAL]:-gptransfer failed. (Reason='error 'ERROR: column "san_mounts" does not exist LINE 2: ... SELECT dbid, content, status, unnest(san_mounts... ^ ' in ' SELECT dbid, content, status, unnest(san_mounts) FROM pg_catalog.gp_segment_configuration WHERE content >= 0 ORDER BY content, dbid '') exiting...
تحتاج أيضًا إلى التحقق من متغيرات GPHOME بحيث تتطابق بين الكتلة المصدر والكتلة الوجهة. خلاف ذلك ، حصلنا على
خطأ غريب إلى حد ما (تفشل أداة gptransfer عندما يكون للمصدر والهدف مسار GPHOME مختلف).
gptransfer -t big_db.public.test_table --source-host=gpdb-source-master.local --dest-database=big_db --source-map-file=/data1/master/gpseg-1/source_host_and_IP_segments --b atch-size=10 --sub-batch-size=50 --truncate 20190109:14:12:07:031438 gptransfer:mdw:gpadmin-[INFO]:-Starting gptransfer with args: -t big_db.public.test_table --source-host=gpdb-spurce-master.local --dest-database=big_db --source-map-file=/data1/master/gpseg-1/source_host_and_IP_segments --b atch-size=10 --sub-batch-size=50 --truncate 20190109:14:12:07:031438 gptransfer:mdw:gpadmin-[INFO]:-Validating options... 20190109:14:12:07:031438 gptransfer:mdw:gpadmin-[ERROR]:-gptransfer: error: GPHOME directory does not exist on gpdb-source-master.local
يمكنك ببساطة إنشاء symlink المقابل وتجاوز متغير GPHOME في الجلسة التي يتم فيها بدء gptransfer.
عند بدء تشغيل gptransfer على الكتلة الوجهة ، يجب أن يشير الخيار "--source-map-file" إلى ملف يحتوي على قائمة بالمضيفين وعناوين IP الخاصة بهم مع شرائح أساسية من الكتلة المصدر. على سبيل المثال:
sdw1,192.0.2.1 sdw2,192.0.2.2 sdw3,192.0.2.3 sdw4,192.0.2.4
من خلال الخيار "- كامل" ، يمكن نقل ليس فقط الجداول ، ولكن قاعدة البيانات بأكملها ، ومع ذلك ، لا ينبغي إنشاء قواعد بيانات المستخدم على الكتلة الوجهة. يجب أن تتذكر أيضًا وجود مشكلات بسبب تغييرات بناء الجملة عند نقل الجداول الخارجية.
لنقم بتقييم الحمل الإضافي ، على سبيل المثال ، عن طريق نسخ 10 جداول فارغة (الجداول من big_db.public.test_table_2 إلى big_db.public.test_table_11) باستخدام gptarnsfer:
gptransfer -f temp_filelist.txt --source-host=gpdb-source-master.local --dest-database=big_db --source-map-file=/data1/master/gpseg-1/source_host_and_IP_segments_dev --batch-size=10 --sub-ba tch-size=50 --truncate 20190118:06:14:08:031521 gptransfer:mdw:gpadmin-[INFO]:-Starting gptransfer with args: -f temp_filelist.txt --source-host=gpdb-source-master.local --dest-database=big_db --source-map-file=/data1/master/gpseg-1/source_host_and_IP_segments_dev --batch-size=10 --sub-batch-size=50 --truncate 20190118:06:14:08:031521 gptransfer:mdw:gpadmin-[INFO]:-Validating options... 20190118:06:14:08:031521 gptransfer:mdw:gpadmin-[INFO]:-Retrieving configuration of source Greenplum Database... 20190118:06:14:08:031521 gptransfer:mdw:gpadmin-[INFO]:-Retrieving configuration of destination Greenplum Database... 20190118:06:14:09:031521 gptransfer:mdw:gpadmin-[INFO]:-Retrieving source tables... 20190118:06:14:12:031521 gptransfer:mdw:gpadmin-[INFO]:-Checking for gptransfer schemas... 20190118:06:14:22:031521 gptransfer:mdw:gpadmin-[INFO]:-Retrieving list of destination tables... 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-Reading source host map file... 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-Building list of source tables to transfer... 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-Number of tables to transfer: 10 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-gptransfer will use "standard" mode for transfer. 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-Validating source host map... 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-Validating transfer table set... 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:-The following tables on the destination system will be truncated: 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:- big_db.public.test_table_2 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:- big_db.public.test_table_3 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:- big_db.public.test_table_4 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:- big_db.public.test_table_5 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:- big_db.public.test_table_6 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:- big_db.public.test_table_7 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:- big_db.public.test_table_8 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:- big_db.public.test_table_9 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:- big_db.public.test_table_10 20190118:06:14:25:031521 gptransfer:mdw:gpadmin-[INFO]:- big_db.public.test_table_11 … 20190118:06:14:34:031521 gptransfer:mdw:gpadmin-[INFO]:-Using batch size of 10 20190118:06:14:34:031521 gptransfer:mdw:gpadmin-[INFO]:-Using sub-batch size of 16 20190118:06:14:34:031521 gptransfer:mdw:gpadmin-[INFO]:-Creating work directory '/home/gpadmin/gptransfer_31521' 20190118:06:14:34:031521 gptransfer:mdw:gpadmin-[INFO]:-Creating schema public in database edw_prod... 20190118:06:14:40:031521 gptransfer:mdw:gpadmin-[INFO]:-Starting transfer of big_db.public.test_table_5 to big_db.public.test_table_5... … 20190118:06:15:02:031521 gptransfer:mdw:gpadmin-[INFO]:-Validation of big_db.public.test_table_4 successful 20190118:06:15:02:031521 gptransfer:mdw:gpadmin-[INFO]:-Removing work directories... 20190118:06:15:02:031521 gptransfer:mdw:gpadmin-[INFO]:-Finished.
نتيجة لذلك ، استغرق نقل 10 جداول فارغة حوالي 16 ثانية (14: 40-15: 02) ، أي جدول واحد - 1.6 ثانية. خلال هذا الوقت ، في حالتنا ، يمكن تنزيل حوالي 100 ميغابايت من البيانات باستخدام pg_dump & psql.
gp_dump & gp_restore
كخيار: استخدم الوظائف الإضافية فوقها ، gpcrondump & gpdbrestore ، حيث تم إهمال gp_dump & gp_restore. على الرغم من أن gpcrondump & gpdbrestore أنفسهم يستخدمون gp_dump & gp_restore في هذه العملية. هذه هي الطريقة الأكثر عالمية ، ولكن ليس الأسرع. تمثل ملفات النسخ الاحتياطي التي تم إنشاؤها باستخدام gp_dump مجموعة من أوامر DDL على العقدة الرئيسية ، وعلى القطاعات الأساسية ، وخاصة مجموعات أوامر COPY وبياناتها. مناسب للحالات التي يتعذر فيها توفير التشغيل المتزامن للكتلة الوجهة والكتلة المصدر. يوجد كلاهما في الإصدارات القديمة من Greenplum ، وفي الجديد:
gp_dump ،
gp_restore .
المرافق Gpbackup و gprestore
تم إنشاؤه كبديل لـ gp_dump & gp_restore. لعملهم ، يلزم إصدار Greenplum 4.3.17 كحد أدنى (
const MINIMUM_GPDB4_VERSION = "4.3.17" ). يشبه مخطط العمل gpbackup & gprestore ، في حين أن سرعة العمل أسرع بكثير. أسرع طريقة للحصول على أوامر DDL لقواعد البيانات الكبيرة. بشكل افتراضي ، يقوم بنقل كائنات عمومية ، تحتاج إلى تحديد "gprestore - with-globals" لاستردادها. يمكن للمعلمة الاختيارية "--jobs" تعيين عدد المهام (وجلسات العمل إلى قاعدة البيانات) عند إنشاء نسخة احتياطية. نظرًا لحقيقة إنشاء عدة جلسات ، من المهم ضمان تناسق البيانات حتى يتم تلقي جميع الأقفال. يوجد أيضًا خيار مفيد "- with-stats" ، والذي يسمح لك بنقل الإحصاءات عن الكائنات المستخدمة لإنشاء خطط التنفيذ. مزيد من المعلومات
هنا .
فائدة Gpcopy
لنسخ قواعد البيانات هناك gpcopy فائدة - بديل ل gptansfer. ولكن يتم تضمينه فقط في إصدار الملكية من Greenplum من Pivotal ، بدءاً من 4.3.26 - في الإصدار المفتوح المصدر
هذه الأداة لا . أثناء العمل على نظام المجموعة المصدر ، يتم تنفيذ الأمر COPY source_table TO PROGRAM 'gpcopy_helper ...' ON SEGMENT CSV IGNORE EXPORTAL PARTITIONS. على جانب نظام المجموعة المتلقي ، يتم إنشاء جدول خارجي مؤقت CREATE EXTERNAL WEB TEMP TABLE external_temp_table (LIKE target_table) يتم تنفيذ EXECUTE '... gpcopy_helper –listen ...' ويتم تنفيذ الأمر INSERT INTO target_table SELECT * FROM external_temp_table. نتيجة لذلك ، يتم إطلاق gpcopy_helper مع المعلمة –listen على كل مقطع من الكتلة الوجهة ، والتي تتلقى البيانات من gpcopy_helper من شرائح من الكتلة المصدر. بسبب نظام نقل البيانات هذا ، وكذلك الضغط ، فإن سرعة النقل أعلى بكثير. بين المجموعات ، يجب أيضًا تكوين مصادقة ssh على الشهادات. أريد أيضًا أن أشير إلى أن gpcopy يحتوي على خيار مناسب "- اقتطاع المصدر بعد" (و "- التحقق") للحالات التي توجد فيها مجموعات المصدر والوجهة على نفس الخوادم.
استراتيجية نقل البيانات
لتحديد استراتيجية النقل ، نحتاج إلى تحديد ما هو أكثر أهمية بالنسبة لنا: نقل البيانات بسرعة ، ولكن مع زيادة العمالة وربما أقل موثوقية (gpbackup ، gptransfer أو مزيج منها) أو مع عمل أقل ، ولكن أبطأ (gpbackup أو gptransfer دون الجمع).
أسرع طريقة لنقل البيانات - عندما يكون هناك كتلة مصدر ومجموعة كتلة - ما يلي:
- الحصول على DDL باستخدام gpbackup - البيانات الوصفية فقط ، وتحويل وتحميل من خلال خط أنابيب باستخدام psql
- حذف الفهارس
- نقل الجداول بحجم 100 ميغابايت أو أكثر باستخدام gptransfer
- نقل الجداول التي يقل حجمها عن 100 ميغابايت باستخدام pg_dump | psql كما في الفقرة الأولى
- إنشاء الفهارس المحذوفة مرة أخرى
تبين أن هذه الطريقة في قياساتنا أسرع مرتين على الأقل من gp_dump & gp_restore. الطرق البديلة: نقل جميع قواعد البيانات باستخدام gptransfer –full أو gpbackup & gprestore أو gp_dump & gp_restore.
يمكن الحصول على أحجام الجدول عن طريق الاستعلام التالي:
SELECT nspname AS "schema", coalesce(tablename, relname) AS "name", SUM(pg_total_relation_size(class.oid)) AS "size" FROM pg_class class JOIN pg_namespace namespace ON namespace.oid = class.relnamespace LEFT JOIN pg_partitions parts ON class.relname = parts.partitiontablename AND namespace.nspname = parts.schemaname WHERE nspname NOT IN ('pg_catalog', 'information_schema', 'pg_toast', 'pg_bitmapindex', 'pg_aoseg', 'gp_toolkit') GROUP BY nspname, relkind, coalesce(tablename, relname), pg_get_userbyid(class.relowner) ORDER BY 1,2;
التحويلات اللازمة
ملفات النسخ الاحتياطي في إصدارات Greenplum 4 و 5 هي أيضا غير متوافقة تماما. لذلك ، في Greenplum 5 ، نظرًا لتغيير في بناء الجملة ، لا يوجد لدى الأمرين CREATE EXTERNAL TABLE و COPY المعلمة INTO ERROR TABLE ، وتحتاج إلى تعيين المعلمة SET gp_ignore_error_table إلى true بحيث لا تفشل استعادة النسخة الاحتياطية. باستخدام مجموعة المعلمات ، نحصل على تحذير.
بالإضافة إلى ذلك ، قدم الإصدار الخامس بروتوكولًا مختلفًا للتفاعل مع جداول pxf الخارجية ، وللاستخدام ، تحتاج إلى تغيير معلمة LOCATION وتكوين خدمة pxf.
تجدر الإشارة أيضًا إلى أنه في ملفات النسخ الاحتياطي gp_dump & gp_restore على العقدة الرئيسية وعلى كل مقطع أساسي ، يتم تعيين المعلمة SET gp_strict_xml_parse على "خطأ". لا توجد مثل هذه المعلمة في Greenplum 5 ، ونتيجة لذلك ، تلقينا رسالة خطأ.
إذا تم استخدام بروتوكول gphdfs للجداول الخارجية ، فستحتاج إلى التحقق من ملفات النسخ الاحتياطي من قائمة المصادر في معلمة LOCATION للجداول الخارجية على السطر 'gphdfs: //'. على سبيل المثال ، يجب أن يكون هناك فقط 'gphdfs: //hadoop.local: 8020'. إذا كانت هناك خطوط أخرى ، فيجب إضافتها إلى البرنامج النصي البديل على العقدة الرئيسية عن طريق القياس.
grep -o gphdfs\:\/\/.*\/ /data1/master/gpseg-1/db_dumps/20181206/gp_dump_-1_1_20181206122002.gz | cut -d/ -f1-3 | sort | uniq gphdfs://hadoop.local:8020
نستبدل العقدة الرئيسية (باستخدام ملف بيانات gp_dump كمثال):
mv /data1/master/gpseg-1/db_dumps/20181206/big_db_gp_dump_1_1_20181206080001.gz /data1/master/gpseg-1/db_dumps/20181206/big_db_gp_dump_1_1_20181206080001.old.gz gunzip -c /data1/master/gpseg-1/db_dumps/20181206/big_db_gp_dump_1_1_20181206080001.old.gz | sed "s#'gphdfs://hadoop.local:8020#'pxf:/#g" | sed "s/\(^.*pxf\:\/\/.*'\)/\1\\&\&\?PROFILE=HdfsTextSimple'/" |sed "s#'&#g" | sed 's/SET gp_strict_xml_parse = false;/SET gp_ignore_error_table = true;/g' | gzip -1 > /data1/master/gpseg-1/db_dumps/20181206/big_db_gp_dump_1_1_20181206080001.gz nets
في الإصدارات الأخيرة ، تم
إعلان إهمال اسم ملف تعريف HdfsTextSimple ، والاسم الجديد هو hdfs: text.
ملخص
خارج المقالة ، ظلت الحاجة إلى التحويل الصريح إلى نص (
صب النص الضمني ) ، وهي آلية جديدة لإدارة موارد مجموعة موارد
المجموعات التي حلت محل قوائم انتظار الموارد ، محسِّن
GPORCA ، والتي يتم تضمينها افتراضيًا في Greenplum 5 ، وهي مشكلات بسيطة مع العملاء.
إنني أتطلع إلى إصدار الإصدار السادس من Greenplum ، والمقرر إجراؤه في ربيع عام 2019: مستوى التوافق مع PostgreSQL 9.4 ، بحث النص الكامل ، دعم فهرس GIN ، أنواع النطاق ، JSONB ، zStd Compression. أيضًا ، أصبحت الخطط الأولية لبرنامج Greenplum 7 معروفة: مستوى التوافق مع PostgreSQL بحد أدنى 9.6 ، أمان مستوى الصف ، تجاوز الفشل التلقائي الآلي. يعد المطورون أيضًا بتوفر أدوات ترقية قاعدة البيانات للتحديث بين الإصدارات الرئيسية ، لذلك سيكون من الأسهل العيش.
أعد هذا المقال فريق Rostelecom لإدارة البيانات