رحّل إلى ClickHouse Managed Postgres باستخدام PeerDB

تعرّف على كيفية ترحيل بيانات PostgreSQL إلى ClickHouse Managed Postgres باستخدام PeerDB

يوفّر هذا الدليل إرشادات خطوة بخطوة لترحيل قاعدة بيانات PostgreSQL الخاصة بك إلى ClickHouse Managed Postgres باستخدام PeerDB.

​

المتطلبات الأساسية

• إمكانية الوصول إلى قاعدة بيانات PostgreSQL المصدر لديك.
• مثيل من ClickHouse Managed Postgres تريد ترحيل بياناتك إليه.
• تثبيت PeerDB على جهاز. يمكنك اتباع إرشادات التثبيت في مستودع PeerDB على GitHub. كل ما عليك هو استنساخ المستودع وتشغيل docker-compose up. في هذا الدليل، سنستخدم واجهة PeerDB، وستكون متاحة على http://localhost:3000 بمجرد تشغيل PeerDB.

​

اعتبارات قبل الترحيل

قبل بدء الترحيل، ضع ما يلي في الحسبان:

• كائنات قاعدة البيانات: سينشئ PeerDB الجداول تلقائيًا في قاعدة البيانات الهدف استنادًا إلى مخطط المصدر. ومع ذلك، لن تُرحَّل بعض كائنات قاعدة البيانات، مثل الفهارس والقيود والمشغلات، تلقائيًا. وستحتاج إلى إعادة إنشاء هذه الكائنات يدويًا في قاعدة البيانات الهدف بعد الترحيل.
• تغييرات DDL: إذا فعّلت النسخ المتماثل المستمر، فسيُبقي PeerDB قاعدة البيانات الهدف متزامنة مع المصدر لعمليات DML ‏(INSERT وUPDATE وDELETE)، كما سينقل عمليات ADD COLUMN. ومع ذلك، لا تُنقل تغييرات DDL الأخرى (مثل DROP COLUMN وALTER COLUMN) تلقائيًا. لمزيد من المعلومات حول دعم تغييرات المخطط، راجع هنا
• اتصال الشبكة: تأكد من إمكانية الوصول إلى كلٍ من قاعدة البيانات المصدر وقاعدة البيانات الهدف من الجهاز الذي يعمل عليه PeerDB. وقد تحتاج إلى تهيئة قواعد جدار الحماية أو إعدادات مجموعة الأمان للسماح بالاتصال.

​

إنشاء نظراء

أولًا، نحتاج إلى إنشاء نظراء لكلٍّ من قاعدة البيانات المصدر وقاعدة البيانات الهدف. ويمثّل الـ نظير اتصالًا بقاعدة بيانات. في واجهة PeerDB، انتقل إلى قسم “Peers” بالنقر على “Peers” في الشريط الجانبي. ولإنشاء نظير جديد، انقر على الزر + New peer.

​

إنشاء source نظير

أنشئ نظير لقاعدة بيانات PostgreSQL المصدر لديك عبر إدخال تفاصيل الاتصال، مثل المضيف والمنفذ واسم قاعدة البيانات واسم المستخدم وكلمة المرور. بعد إدخال التفاصيل، انقر على الزر Create peer لحفظ الـ نظير.

​

إنشاء نظير الهدف

وبالمثل، أنشئ نظير لمثيل ClickHouse Managed Postgres الخاص بك من خلال إدخال تفاصيل الاتصال المطلوبة. يمكنك الحصول على تفاصيل الاتصال الخاصة بمثيلك من ClickHouse Cloud console. بعد إدخال التفاصيل، انقر على الزر Create peer لحفظ نظير الهدف.

الآن، ينبغي أن ترى كلاً من نظير المصدر ونظير الهدف مدرجَين في قسم “Peers”.

​

الحصول على تفريغ مخطط قاعدة البيانات المصدر

لمطابقة إعداد قاعدة البيانات المصدر في قاعدة البيانات الهدف، نحتاج إلى الحصول على تفريغ لمخطط قاعدة البيانات المصدر. يمكنك استخدام pg_dump لإنشاء تفريغ للمخطط فقط من قاعدة بيانات PostgreSQL المصدر:

تثبيت pg_dump

Ubuntu:

حدّث قوائم الحزم:

sudo apt update

ثبّت عميل PostgreSQL:

sudo apt install postgresql-client

macOS:

الطريقة 1: باستخدام Homebrew (موصى بها)

ثبّت Homebrew إذا لم يكن مثبّتًا لديك:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

ثبّت PostgreSQL:

brew install postgresql

تحقّق من التثبيت:

pg_dump --version

pg_dump -d 'postgresql://<user>:<password>@<host>:<port>/<database>'  -s > source_schema.sql

​

إزالة القيود الفريدة والفهارس من ملف تفريغ المخطط

قبل تطبيق ذلك على قاعدة البيانات المستهدفة، نحتاج إلى إزالة القيود الفريدة والفهارس من ملف تفريغ المخطط حتى لا تعيق هذه القيود عملية إدخال PeerDB إلى الجداول المستهدفة. ويمكن إزالة هذه العناصر باستخدام:

# Preview
grep -n "CONSTRAINT.*UNIQUE" <dump_file_path>
grep -n "CREATE UNIQUE INDEX" <dump_file_path>
grep -n -E "(CONSTRAINT.*UNIQUE|CREATE UNIQUE INDEX)" <dump_file_path>

# Remove
sed -i.bak -E '/CREATE UNIQUE INDEX/,/;/d; /(CONSTRAINT.*UNIQUE|ADD CONSTRAINT.*UNIQUE)/d' <dump_file_path>

​

طبّق تفريغ المخطط على قاعدة البيانات المستهدفة

بعد تنظيف ملف تفريغ المخطط، يمكنك تطبيقه على قاعدة بيانات ClickHouse Managed Postgres المستهدفة من خلال الاتصال باستخدام psql ثم تشغيل ملف تفريغ المخطط:

psql -h <target_host> -p <target_port> -U <target_username> -d <target_database> -f source_schema.sql

هنا في جهة الهدف، لا نريد أن تعيق قيود المفاتيح الأجنبية إدخال بيانات PeerDB. ولتحقيق ذلك، يمكننا تعديل الدور الهدف (المستخدَم أعلاه في target peer) بحيث يُضبط session_replication_role على replica:

ALTER ROLE <target_role> SET session_replication_role = replica;

​

أنشئ مرآة

بعد ذلك، نحتاج إلى إنشاء مرآة لتحديد عملية ترحيل البيانات بين النظير المصدر والنظير الهدف. في واجهة PeerDB، انتقل إلى قسم “Mirrors” بالنقر على “Mirrors” في الشريط الجانبي. ولإنشاء مرآة جديدة، انقر على الزر + New mirror.

1. امنح المرآة اسمًا يعبّر عن عملية الترحيل.
2. اختر النظير المصدر والنظير الهدف اللذين أنشأتهما سابقًا من القوائم المنسدلة.
3. تأكد مما يلي:

• أن يكون Soft delete مضبوطًا على OFF.
• وسّع Advanced settings. وتأكد من أن نظام أنواع Postgres مُمكّن وأن أعمدة PeerDB معطّلة.

4. اختر الجداول التي تريد ترحيلها. يمكنك اختيار جداول محددة أو تحديد جميع الجداول من قاعدة البيانات المصدر.

اختيار الجداول

تأكد من أن أسماء الجداول في قاعدة البيانات الهدف تطابق أسماء الجداول المصدر، لأننا رحّلنا المخطط كما هو في الخطوة السابقة.

5. بعد تكوين إعدادات المرآة، انقر على الزر Create mirror.

يجب أن تظهر المرآة التي أنشأتها للتو في قسم “Mirrors”.

​

انتظر اكتمال التحميل الأولي

بعد إنشاء الـ مرآة، سيبدأ PeerDB التحميل الأولي للبيانات من المصدر إلى قاعدة البيانات الهدف. يمكنك النقر على الـ مرآة ثم الانتقال إلى علامة التبويب التحميل الأولي لمتابعة تقدّم ترحيل البيانات الأولي.

بمجرد اكتمال التحميل الأولي، يفترض أن ترى حالة تشير إلى اكتمال الترحيل.

​

مراقبة التحميل الأولي والنسخ المتماثل

إذا نقرت على نظير المصدر، فسترى قائمة بالأوامر قيد التشغيل التي ينفّذها PeerDB. على سبيل المثال:

1. في البداية، نشغّل استعلام COUNT لتقدير عدد الصفوف في كل جدول.
2. ثم نشغّل استعلام تقسيم باستخدام NTILE لتجزئة الجداول الكبيرة إلى أجزاء أصغر من أجل نقل البيانات بكفاءة.
3. بعد ذلك ننفّذ أوامر FETCH لسحب البيانات من قاعدة البيانات المصدر، ثم يزامنها PeerDB مع قاعدة البيانات الهدف.

​

مهام ما بعد الترحيل

قد تختلف هذه الخطوات بحسب حالة الاستخدام الخاصة بك ومتطلبات التطبيق. المهم هو ضمان اتساق البيانات، وتقليل فترة التعطل إلى أدنى حد، والتحقق من سلامة البيانات المُرحَّلة قبل الانتقال الكامل إلى النظام الجديد.

بعد اكتمال الترحيل:

• أجرِ فحوصات التحقق قبل التحويل النهائي

قارن الجداول الأساسية بين المصدر والوجهة قبل إعادة توجيه حركة المرور:

-- Row count comparison for critical tables
SELECT 'public.orders' AS table_name, COUNT(*) AS row_count FROM public.orders;
SELECT 'public.customers' AS table_name, COUNT(*) AS row_count FROM public.customers;

-- Spot-check latest records in high-activity tables
SELECT MAX(updated_at) FROM public.orders;
SELECT MAX(id) FROM public.orders;

• أوقف عمليات الكتابة على النظام المصدر

أوقف أولًا عمليات الكتابة من التطبيق. وكإجراء احترازي إضافي، اضبط قاعدة البيانات المصدر على وضع القراءة فقط أثناء التبديل النهائي:

ALTER DATABASE <source_db> SET default_transaction_read_only = on;

إذا احتجت إلى التراجع، يمكنك إعادة تفعيل عمليات الكتابة:

ALTER DATABASE <source_db> SET default_transaction_read_only = off;

• تأكّد من أن النسخ المتماثل متزامن بالكامل

تحقّق من تطابق أحدث صف في جدول واحد أو أكثر من الجداول ذات معدلات الكتابة العالية بين المصدر والوجهة:

-- Run on both source and target and compare results
SELECT MAX(id) AS latest_id, MAX(updated_at) AS latest_ts FROM public.orders;

• أعِد إنشاء القيود والفهارس والمشغّلات وفعّلها

إذا كنت قد أزلت القيود/الفهارس أو أجّلتها لأغراض الإدخال، فأعِد تطبيقها الآن. وأعِد أيضًا تعيين دور النسخ المتماثل على الوجهة إذا كنت قد ضبطته سابقًا على replica:

ALTER ROLE <target_role> SET session_replication_role = origin;

# Example: apply a SQL file containing constraints/indexes/triggers
psql -h <target_host> -p <target_port> -U <target_user> -d <target_db> -f post_migration_objects.sql

• أعد تعيين التسلسلات في الجداول المستهدفة

بعد تحميل البيانات، واءم التسلسلات مع القيم الحالية في الجداول:

-- Generic sequence reset for all serial/identity-backed columns in non-system schemas
DO $$
DECLARE r RECORD;
BEGIN
    FOR r IN
        SELECT
            n.nspname AS schema_name,
            c.relname AS table_name,
            a.attname AS column_name,
            pg_get_serial_sequence(format('%I.%I', n.nspname, c.relname), a.attname) AS seq_name
        FROM pg_class c
        JOIN pg_namespace n ON n.oid = c.relnamespace
        JOIN pg_attribute a ON a.attrelid = c.oid
        WHERE c.relkind = 'r'
            AND a.attnum > 0
            AND NOT a.attisdropped
            AND n.nspname NOT IN ('pg_catalog', 'information_schema')
    LOOP
        IF r.seq_name IS NOT NULL THEN
            EXECUTE format(
                'SELECT setval(%L, COALESCE((SELECT MAX(%I) FROM %I.%I), 0) + 1, false)',
                r.seq_name, r.column_name, r.schema_name, r.table_name
            );
        END IF;
    END LOOP;
END $$;

• تحويل حركة مرور التطبيق

بعد اكتمال التحقق بنجاح وتجهيز التسلسلات/القيود:

1. وجّه حركة مرور القراءة إلى ClickHouse Managed Postgres.
2. وجّه حركة مرور الكتابة إلى ClickHouse Managed Postgres.
3. راقب أخطاء التطبيق، ومخالفات القيود، وصحة قاعدة البيانات.

• تنظيف الموارد

بمجرد التأكد من نجاح الترحيل وتحويل تطبيقك لاستخدام ClickHouse Managed Postgres، يمكنك حذف الـ مرآة والـ نظراء في PeerDB.

فتحات النسخ المتماثل

إذا فعّلت النسخ المتماثل المستمر، فسينشئ PeerDB فتحة نسخ متماثل على قاعدة بيانات PostgreSQL المصدر. احرص على حذف فتحة النسخ المتماثل يدويًا من قاعدة البيانات المصدر بعد الانتهاء من الترحيل لتجنّب استهلاك الموارد دون داعٍ.

​

المراجع

• وثائق ClickHouse Managed Postgres
• دليل PeerDB لإنشاء CDC
• الأسئلة الشائعة حول Postgres ClickPipe (وينطبق ذلك أيضًا على PeerDB)

​

الخطوات التالية

تهانينا! لقد نجحت في ترحيل قاعدة بيانات PostgreSQL إلى ClickHouse Managed Postgres باستخدام pg_dump وpg_restore. أصبحت الآن جاهزًا تمامًا لاستكشاف ميزات Managed Postgres وتكامله مع ClickHouse. إليك دليل بدء سريع مدته 10 دقائق للانطلاق:

• دليل البدء السريع لـ Managed Postgres