PostgreSQL اور MySQL کے درمیان کراس نقل

میں PostgreSQL اور MySQL کے درمیان کراس ریپلیکیشن کا خاکہ پیش کروں گا، نیز دو ڈیٹا بیس سرورز کے درمیان کراس ریپلیکیشن ترتیب دینے کے طریقے۔ عام طور پر، کراس نقل شدہ ڈیٹا بیس کو یکساں کہا جاتا ہے، اور یہ ایک RDBMS سرور سے دوسرے سرور میں جانے کا ایک آسان طریقہ ہے۔

PostgreSQL اور MySQL ڈیٹا بیس کو عام طور پر رشتہ دار سمجھا جاتا ہے، لیکن اضافی ایکسٹینشنز کے ساتھ وہ NoSQL کی صلاحیتیں پیش کرتے ہیں۔ یہاں ہم پوسٹگری ایس کیو ایل اور مائی ایس کیو ایل کے درمیان ایک متعلقہ DBMS نقطہ نظر سے نقل پر تبادلہ خیال کریں گے۔

ہم پورے اندرونی کاموں کو بیان نہیں کریں گے، صرف بنیادی اصولوں کو تاکہ آپ کو ڈیٹا بیس سرورز، فوائد، حدود اور استعمال کے معاملات کے درمیان نقل ترتیب دینے کا خیال آئے۔

عام طور پر، دو ایک جیسے ڈیٹا بیس سرورز کے درمیان نقل یا تو بائنری موڈ میں یا ماسٹر (عرف پبلشر، ماسٹر، یا فعال) اور غلام (سبسکرائبر، اسٹینڈ بائی، یا غیر فعال) کے درمیان سوالات کا استعمال کرتے ہوئے کیا جاتا ہے۔ نقل کا مقصد غلام سائیڈ پر ماسٹر ڈیٹا بیس کی اصل وقتی کاپی فراہم کرنا ہے۔ اس صورت میں، ڈیٹا ماسٹر سے غلام میں منتقل ہوتا ہے، یعنی فعال سے غیر فعال، کیونکہ نقل صرف ایک سمت میں انجام دیا جاتا ہے. لیکن آپ دونوں سمتوں میں دو ڈیٹا بیس کے درمیان نقل ترتیب دے سکتے ہیں، تاکہ ڈیٹا کو ایک فعال ایکٹیو کنفیگریشن میں غلام سے ماسٹر میں منتقل کیا جائے۔ یہ سب کچھ، بشمول کاسکیڈنگ ریپلیکیشن، دو یا دو سے زیادہ ایک جیسے ڈیٹا بیس سرورز کے درمیان ممکن ہے۔ ایکٹیو ایکٹو یا ایکٹیو غیر فعال کنفیگریشن کا انحصار ضرورت، ابتدائی کنفیگریشن میں ایسی صلاحیتوں کی دستیابی یا بیرونی کنفیگریشن سلوشنز اور موجودہ ٹریڈ آف کے استعمال پر ہے۔

بیان کردہ ترتیب مختلف ڈیٹا بیس سرورز کے درمیان ممکن ہے۔ سرور کو دوسرے ڈیٹا بیس سرور سے نقل شدہ ڈیٹا کو قبول کرنے کے لیے کنفیگر کیا جا سکتا ہے اور پھر بھی نقل کیے گئے ڈیٹا کے ریئل ٹائم سنیپ شاٹس کو برقرار رکھا جا سکتا ہے۔ MySQL اور PostgreSQL ان میں سے زیادہ تر کنفیگریشنز اندرون خانہ یا تھرڈ پارٹی ایکسٹینشن کے ذریعے پیش کرتے ہیں، بشمول بائنری لاگ کے طریقے، ڈسک لاکنگ، اور بیان اور قطار پر مبنی طریقے۔

MySQL اور PostgreSQL کے درمیان کراس ریپلیکیشن ایک ڈیٹا بیس سرور سے دوسرے میں ایک بار منتقلی کے لیے ضروری ہے۔ یہ ڈیٹا بیس مختلف پروٹوکول استعمال کرتے ہیں، اس لیے انہیں براہ راست لنک کرنا ممکن نہیں ہے۔ ڈیٹا ایکسچینج قائم کرنے کے لیے، آپ ایک بیرونی اوپن سورس ٹول استعمال کر سکتے ہیں، مثال کے طور پر pg_chameleon۔

pg_chameleon کیا ہے؟

pg_chameleon Python 3 میں MySQL سے PostgreSQL تک ایک نقل کا نظام ہے۔ یہ اوپن سورس mysql-replication لائبریری کا استعمال کرتا ہے، Python میں بھی۔ قطار کی تصاویر MySQL ٹیبلز سے نکالی جاتی ہیں اور PostgreSQL ڈیٹا بیس میں JSONB آبجیکٹ کے طور پر محفوظ کی جاتی ہیں، اور پھر pl/pgsql فنکشن کے ذریعے ڈکرپٹ کی جاتی ہیں اور PostgreSQL ڈیٹا بیس میں دوبارہ تیار کی جاتی ہیں۔

pg_chameleon کی خصوصیات

ایک ہی کلسٹر سے متعدد MySQL اسکیموں کو ایک سے کئی کنفیگریشن میں ایک ہی ہدف PostgreSQL ڈیٹا بیس میں نقل کیا جا سکتا ہے۔
سورس اور ٹارگٹ اسکیما کے نام ایک جیسے نہیں ہو سکتے۔
نقل کا ڈیٹا ایک جھرنے والے MySQL نقل سے حاصل کیا جا سکتا ہے۔
وہ میزیں جو نقل نہیں کر سکتیں یا غلطیاں پیدا نہیں کر سکتیں۔
ہر نقل کی تقریب ڈیمن کے ذریعہ کنٹرول ہوتی ہے۔
YAML پر مبنی پیرامیٹرز اور کنفیگریشن فائلوں کے ذریعے کنٹرول کریں۔

مثال کے طور پر

میزبان
vm1۔
vm2۔

OS ورژن
CentOS لینکس 7.6 x86_64
CentOS لینکس 7.5 x86_64

ڈی بی سرور ورژن
ایس کیو ایل 5.7.26
پوسٹگر ایس ایس ایل 10.5

ڈی بی پورٹ
3306
5433

IP ایڈریس
192.168.56.102
192.168.56.106

شروع کرنے کے لیے، pg_chameleon کو انسٹال کرنے کے لیے تمام ضروری اجزاء تیار کریں۔ یہ مثال Python 3.6.8 انسٹال کرتی ہے، جو ورچوئل ماحول کو تخلیق اور فعال کرتی ہے۔

$> wget https://www.python.org/ftp/python/3.6.8/Python-3.6.8.tar.xz
$> tar -xJf Python-3.6.8.tar.xz
$> cd Python-3.6.8
$> ./configure --enable-optimizations
$> make altinstall

Python3.6 کو کامیابی کے ساتھ انسٹال کرنے کے بعد، آپ کو بقیہ ضروریات کو پورا کرنے کی ضرورت ہے، جیسے کہ ورچوئل ماحول بنانا اور فعال کرنا۔ مزید برآں، pip ماڈیول کو تازہ ترین ورژن میں اپ ڈیٹ کیا جاتا ہے اور pg_chameleon کو انسٹال کرنے کے لیے استعمال کیا جاتا ہے۔ نیچے دی گئی کمانڈز جان بوجھ کر pg_chameleon 2.0.9 انسٹال کرتی ہیں، حالانکہ تازہ ترین ورژن 2.0.10 ہے۔ اپ ڈیٹ شدہ ورژن میں نئے کیڑے سے بچنے کے لیے یہ ضروری ہے۔

$> python3.6 -m venv venv
$> source venv/bin/activate
(venv) $> pip install pip --upgrade
(venv) $> pip install pg_chameleon==2.0.9

اس کے بعد ہم pg_chameleon (گرگٹ ایک کمانڈ ہے) کو سیٹ_configuration_files دلیل کے ساتھ pg_chameleon کو فعال کرنے اور ڈیفالٹ ڈائریکٹریز اور کنفیگریشن فائلیں بنانے کے لیے کہتے ہیں۔

(venv) $> chameleon set_configuration_files
creating directory /root/.pg_chameleon
creating directory /root/.pg_chameleon/configuration/
creating directory /root/.pg_chameleon/logs/
creating directory /root/.pg_chameleon/pid/
copying configuration  example in /root/.pg_chameleon/configuration//config-example.yml

اب ہم config-example.yml کی ایک کاپی بطور default.yml بناتے ہیں تاکہ یہ ڈیفالٹ کنفیگریشن فائل بن جائے۔ اس مثال کے لیے ایک نمونہ کنفیگریشن فائل ذیل میں فراہم کی گئی ہے۔

$> cat default.yml
---
#global settings
pid_dir: '~/.pg_chameleon/pid/'
log_dir: '~/.pg_chameleon/logs/'
log_dest: file
log_level: info
log_days_keep: 10
rollbar_key: ''
rollbar_env: ''

# type_override allows the user to override the default type conversion into a different one.
type_override:
  "tinyint(1)":
    override_to: boolean
    override_tables:
      - "*"

#postgres  destination connection
pg_conn:
  host: "192.168.56.106"
  port: "5433"
  user: "usr_replica"
  password: "pass123"
  database: "db_replica"
  charset: "utf8"

sources:
  mysql:
    db_conn:
      host: "192.168.56.102"
      port: "3306"
      user: "usr_replica"
      password: "pass123"
      charset: 'utf8'
      connect_timeout: 10
    schema_mappings:
      world_x: pgworld_x
    limit_tables:
#      - delphis_mediterranea.foo
    skip_tables:
#      - delphis_mediterranea.bar
    grant_select_to:
      - usr_readonly
    lock_timeout: "120s"
    my_server_id: 100
    replica_batch_size: 10000
    replay_max_rows: 10000
    batch_retention: '1 day'
    copy_max_memory: "300M"
    copy_mode: 'file'
    out_dir: /tmp
    sleep_loop: 1
    on_error_replay: continue
    on_error_read: continue
    auto_maintenance: "disabled"
    gtid_enable: No
    type: mysql
    skip_events:
      insert:
        - delphis_mediterranea.foo #skips inserts on the table delphis_mediterranea.foo
      delete:
        - delphis_mediterranea #skips deletes on schema delphis_mediterranea
      update:

اس مثال میں کنفیگریشن فائل ایک نمونہ pg_chameleon فائل ہے جس میں ماخذ اور ہدف کے ماحول کے مطابق معمولی ترامیم کی گئی ہیں، اور ذیل میں کنفیگریشن فائل کے مختلف حصوں کا ایک جائزہ ہے۔

default.yml کنفیگریشن فائل میں گلوبل سیٹنگز کا ایک سیکشن ہوتا ہے، جہاں آپ سیٹنگز کو مینیج کر سکتے ہیں جیسے کہ لاک فائل کا لوکیشن، لاگز کا لوکیشن، لاگز کے لیے اسٹوریج کی مدت وغیرہ۔ اس کے بعد ٹائپ اوور رائڈ سیکشن آتا ہے، جہاں نقل کے دوران اوور رائیڈنگ اقسام کے قوانین کا ایک سیٹ۔ مثال پہلے سے طے شدہ ایک قسم کے اوور رائیڈنگ اصول پر ہے جو tinyint(1) کو بولین ویلیو میں تبدیل کرتی ہے۔ اگلے حصے میں، ہم ٹارگٹ ڈیٹا بیس سے کنکشن کی تفصیلات بتاتے ہیں۔ ہمارے معاملے میں، یہ ایک PostgreSQL ڈیٹا بیس ہے، نامزد pg_conn۔ آخری حصے میں، ہم سورس ڈیٹا کی نشاندہی کرتے ہیں، یعنی سورس ڈیٹا بیس کے کنکشن پیرامیٹرز، سورس اور ٹارگٹ ڈیٹا بیس کے درمیان میپنگ اسکیم، ٹیبلز جنہیں چھوڑنا ضروری ہے، انتظار کا وقت، میموری، پیکیج کا سائز۔ نوٹ کریں کہ "ذرائع" کثرت ہے، یعنی ہم متعدد ماخذ ڈیٹا بیس کو ایک واحد ہدف ڈیٹا بیس میں شامل کر سکتے ہیں تاکہ ایک سے زیادہ ترتیب ترتیب دی جا سکے۔

مثال کے ڈیٹا بیس world_x میں قطاروں کے ساتھ 4 میزیں ہیں جو MySQL کمیونٹی بطور مثال پیش کرتی ہے۔ اسے ڈاؤن لوڈ کیا جا سکتا ہے۔ یہاں. نمونہ ڈیٹا بیس ایک ٹار اور کمپریسڈ آرکائیو کے طور پر آتا ہے جس میں قطاریں بنانے اور درآمد کرنے کی ہدایات ہوتی ہیں۔

MySQL اور PostgreSQL ڈیٹا بیس میں، ایک خاص صارف اسی نام کے ساتھ بنایا جاتا ہے usr_replica. MySQL میں، اسے تمام نقل شدہ ٹیبلز کو پڑھنے کے اضافی حقوق دیے جاتے ہیں۔

mysql> CREATE USER usr_replica ;
mysql> SET PASSWORD FOR usr_replica='pass123';
mysql> GRANT ALL ON world_x.* TO 'usr_replica';
mysql> GRANT RELOAD ON *.* to 'usr_replica';
mysql> GRANT REPLICATION CLIENT ON *.* to 'usr_replica';
mysql> GRANT REPLICATION SLAVE ON *.* to 'usr_replica';
mysql> FLUSH PRIVILEGES;

PostgreSQL کی طرف، ایک db_replica ڈیٹا بیس بنایا گیا ہے جو MySQL ڈیٹا بیس سے تبدیلیوں کو قبول کرے گا۔ PostgreSQL میں صارف usr_replica خود بخود دو اسکیموں، pgworld_x اور sch_chameleon کے مالک کے طور پر کنفیگر ہو جاتا ہے، جس میں بالترتیب اصل نقل شدہ ٹیبلز اور ریپلیکیشن ڈائرکٹری ٹیبلز ہوتے ہیں۔ create_replica_schema دلیل خودکار ترتیب کے لیے ذمہ دار ہے، جیسا کہ آپ نیچے دیکھیں گے۔

postgres=# CREATE USER usr_replica WITH PASSWORD 'pass123';
CREATE ROLE
postgres=# CREATE DATABASE db_replica WITH OWNER usr_replica;
CREATE DATABASE

MySQL ڈیٹا بیس کو کچھ پیرامیٹر تبدیلیوں کے ساتھ ترتیب دیا گیا ہے تاکہ اسے نقل کے لیے تیار کیا جا سکے جیسا کہ ذیل میں دکھایا گیا ہے۔ تبدیلیوں کے مؤثر ہونے کے لیے آپ کو ڈیٹا بیس سرور کو دوبارہ شروع کرنے کی ضرورت ہوگی۔

$> vi /etc/my.cnf
binlog_format= ROW
binlog_row_image=FULL
log-bin = mysql-bin
server-id = 1

اب یہ ضروری ہے کہ دونوں ڈیٹا بیس سرورز کے کنکشن کو چیک کیا جائے تاکہ pg_chameleon کمانڈز چلاتے وقت کوئی پریشانی نہ ہو۔

PostgreSQL نوڈ پر:

$> mysql -u usr_replica -Ap'admin123' -h 192.168.56.102 -D world_x

MySQL نوڈ پر:

$> psql -p 5433 -U usr_replica -h 192.168.56.106 db_replica

اگلے تین pg_chameleon (گرگٹ) کمانڈز ماحول کو تیار کرتے ہیں، ماخذ شامل کرتے ہیں، اور نقل کو شروع کرتے ہیں۔ pg_chameleon کے لیے create_replica_schema دلیل PostgreSQL ڈیٹابیس میں ایک ڈیفالٹ اسکیما (sch_chameleon) اور ایک ریپلیکیشن اسکیما (pgworld_x) بناتی ہے، جیسا کہ ہم پہلے ہی بحث کر چکے ہیں۔ add_source دلیل کنفیگریشن فائل (default.yml) کو پڑھ کر کنفیگریشن میں سورس ڈیٹا بیس کا اضافہ کرتی ہے، اور ہمارے معاملے میں یہ mysql ہے، اور init_replica کنفیگریشن فائل میں پیرامیٹرز کی بنیاد پر کنفیگریشن کو شروع کرتا ہے۔

$> chameleon create_replica_schema --debug
$> chameleon add_source --config default --source mysql --debug
$> chameleon init_replica --config default --source mysql --debug

ان تینوں کمانڈز کی آؤٹ پٹ واضح طور پر اس بات کی نشاندہی کرتی ہے کہ ان پر کامیابی کے ساتھ عمل کیا گیا تھا۔ کسی بھی کریش یا نحو کی غلطیوں کی اطلاع سادہ، واضح پیغامات میں دی جاتی ہے جس میں اشارے ہوتے ہیں کہ مسئلہ کو کیسے حل کیا جائے۔

آخر میں، ہم start_replica کا استعمال کرتے ہوئے نقل شروع کرتے ہیں اور کامیابی کا پیغام موصول کرتے ہیں۔

$> chameleon start_replica --config default --source mysql 
output: Starting the replica process for source mysql

نقل کی حیثیت show_status دلیل کا استعمال کرتے ہوئے پوچھ گچھ کی جا سکتی ہے، اور غلطیوں کو show_errors دلیل کا استعمال کرتے ہوئے دیکھا جا سکتا ہے۔

نتیجہ

جیسا کہ ہم پہلے ہی کہہ چکے ہیں، ہر نقل کا فنکشن ڈیمن کے ذریعے کنٹرول کیا جاتا ہے۔ انہیں دیکھنے کے لیے، ہم لینکس پی ایس کمانڈ کے ساتھ پروسیس ٹیبل سے استفسار کرتے ہیں، جیسا کہ ذیل میں دکھایا گیا ہے۔

نتیجہ

نقل کو اس وقت تک کنفیگر نہیں سمجھا جاتا جب تک کہ ہم اسے حقیقی وقت میں جانچ نہیں لیتے، جیسا کہ ذیل میں دکھایا گیا ہے۔ ہم ایک ٹیبل بناتے ہیں، MySQL ڈیٹابیس میں کچھ ریکارڈ داخل کرتے ہیں، اور pg_chameleon میں sync_tables argument کو کال کرتے ہیں تاکہ ڈیمونز کو اپ ڈیٹ کیا جا سکے اور ٹیبل کو پوسٹگری ایس کیو ایل ڈیٹا بیس میں ریکارڈ کے ساتھ نقل کیا جا سکے۔

mysql> create table t1 (n1 int primary key, n2 varchar(10));
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t1 values (1,'one');
Query OK, 1 row affected (0.00 sec)
mysql> insert into t1 values (2,'two');
Query OK, 1 row affected (0.00 sec)

$> chameleon sync_tables --tables world_x.t1 --config default --source mysql
Sync tables process for source mysql started.

ٹیسٹ کے نتائج کی تصدیق کرنے کے لیے، ہم PostgreSQL ڈیٹا بیس سے ٹیبل سے استفسار کرتے ہیں اور قطاروں کو آؤٹ پٹ کرتے ہیں۔

$> psql -p 5433 -U usr_replica -d db_replica -c "select * from pgworld_x.t1";
 n1 |  n2
----+-------
  1 | one
  2 | two

اگر ہم ہجرت کر رہے ہیں، تو درج ذیل pg_chameleon کمانڈز اس کا خاتمہ ہوں گی۔ جب ہمیں یقین ہو جائے کہ تمام ٹارگٹ ٹیبلز کی قطاریں نقل کر دی گئی ہیں تو کمانڈز پر عمل درآمد کرنے کی ضرورت ہے، اور نتیجہ ماخذ ڈیٹا بیس یا ریپلیکشن سکیم (sch_chameleon) کے حوالے کے بغیر ایک صاف ستھرا منتقل شدہ PostgreSQL ڈیٹا بیس ہوگا۔

$> chameleon stop_replica --config default --source mysql 
$> chameleon detach_replica --config default --source mysql --debug

اگر آپ چاہیں تو، آپ اصل ترتیب اور نقل کی اسکیم کو حذف کرنے کے لیے درج ذیل کمانڈز استعمال کر سکتے ہیں۔

$> chameleon drop_source --config default --source mysql --debug
$> chameleon drop_replica_schema --config default --source mysql --debug

pg_chameleon کے فوائد

آسان سیٹ اپ اور ترتیب۔
واضح غلطی کے پیغامات کے ساتھ آسانی سے خرابیوں کا ازالہ کریں اور ان کی شناخت کریں۔
بقیہ کنفیگریشن کو تبدیل کیے بغیر ابتدا کے بعد نقل میں اضافی خصوصی جدولیں شامل کی جا سکتی ہیں۔
ایک واحد ٹارگٹ ڈیٹا بیس کے لیے متعدد سورس ڈیٹا بیس کو ترتیب دینا ممکن ہے، اور یہ بہت مفید ہے اگر آپ ایک یا زیادہ MySQL ڈیٹا بیس کے ڈیٹا کو ایک PostgreSQL ڈیٹا بیس میں ملا رہے ہیں۔
آپ کو منتخب کردہ میزوں کی نقل تیار کرنے کی ضرورت نہیں ہے۔

pg_chameleon کے نقصانات

صرف MySQL 5.5 اور اس سے اوپر کے ماخذ کے طور پر اور PostgreSQL 9.5 اور اس سے اوپر کے ٹارگٹ ڈیٹا بیس کے ساتھ تعاون یافتہ ہے۔
ہر ٹیبل میں ایک بنیادی یا منفرد کلید ہونی چاہیے، بصورت دیگر جدولیں init_replica کے عمل کے دوران شروع کی جاتی ہیں لیکن نقل نہیں کی جاتی ہیں۔
یک طرفہ نقل - صرف MySQL سے PostgreSQL تک۔ لہذا، یہ صرف "فعال غیر فعال" سرکٹ کے لئے موزوں ہے.
ماخذ صرف ایک MySQL ڈیٹا بیس ہو سکتا ہے، اور ایک ماخذ کے طور پر PostgreSQL ڈیٹا بیس کی حمایت صرف تجرباتی اور حدود کے ساتھ ہے (مزید جانیں یہاں)

pg_chameleon کے نتائج

ڈیٹا بیس کو MySQL سے PostgreSQL میں منتقل کرنے کے لیے pg_chameleon میں نقل کا طریقہ بہت اچھا ہے۔ اہم منفی پہلو یہ ہے کہ نقل صرف ایک طرفہ ہے، اس لیے ڈیٹا بیس کے پیشہ ور افراد اس کو منتقلی کے علاوہ کسی اور چیز کے لیے استعمال کرنا چاہتے ہیں۔ لیکن ایک طرفہ نقل کا مسئلہ ایک اور اوپن سورس ٹول - SymmetricDS سے حل کیا جا سکتا ہے۔

سرکاری دستاویزات میں مزید پڑھیں یہاں. کمانڈ لائن مدد مل سکتی ہے۔ یہاں.

SymmetricDS کا جائزہ

SymmetricDS ایک اوپن سورس ٹول ہے جو کسی بھی ڈیٹا بیس کو کسی دوسرے عام ڈیٹا بیس میں نقل کرتا ہے: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird اور دیگر کلاؤڈ ڈیٹا بیس مثالیں، جیسے Redshift، Azure، وغیرہ دستیاب خصوصیات: ڈیٹا بیس اور فائل سنکرونائزیشن، ملٹی ماسٹر ڈیٹا بیس ریپلیکشن، فلٹرڈ سنکرونائزیشن، ٹرانسفارمیشن اور دیگر۔ یہ جاوا ٹول ہے اور اس کے لیے JRE یا JDK (ورژن 8.0 یا اس سے زیادہ) کی معیاری ریلیز کی ضرورت ہے۔ یہاں، ماخذ ڈیٹا بیس میں محرکات میں ڈیٹا کی تبدیلیوں کو ریکارڈ کیا جا سکتا ہے اور بیچوں کی شکل میں مناسب ہدف ڈیٹا بیس کو بھیجا جا سکتا ہے۔

SymmetricDS خصوصیات

ٹول پلیٹ فارم سے آزاد ہے، یعنی دو یا دو سے زیادہ مختلف ڈیٹا بیس ڈیٹا کا تبادلہ کر سکتے ہیں۔
متعلقہ ڈیٹا بیسز کو ڈیٹا کی تبدیلی کے ریکارڈ کا استعمال کرتے ہوئے ہم آہنگ کیا جاتا ہے، جبکہ فائل سسٹم پر مبنی ڈیٹا بیس فائل کی مطابقت پذیری کا استعمال کرتے ہیں۔
قواعد کے ایک سیٹ کی بنیاد پر پش اور پل کے طریقوں کا استعمال کرتے ہوئے دو طرفہ نقل۔
محفوظ اور کم بینڈوتھ نیٹ ورکس پر ڈیٹا کی منتقلی ممکن ہے۔
خودکار بحالی جب نوڈس ناکامی اور خودکار تنازعات کے حل کے بعد دوبارہ کام شروع کرتے ہیں۔
کلاؤڈ ہم آہنگ اور طاقتور ایکسٹینشن APIs۔

مثال کے طور پر

SymmetricDS کو دو طریقوں میں سے ایک میں ترتیب دیا جا سکتا ہے:
ایک ماسٹر (والدین) نوڈ جو مرکزی طور پر دو غلام (بچے) نوڈس کے درمیان ڈیٹا کی نقل کو مربوط کرتا ہے، اور چائلڈ نوڈس کے درمیان مواصلت صرف والدین کے ذریعے ہوتی ہے۔
ایک فعال نوڈ (نوڈ 1) بغیر کسی بیچوان کے دوسرے فعال نوڈ (نوڈ 2) کے ساتھ نقل کے لیے بات چیت کر سکتا ہے۔

دونوں اختیارات میں، ڈیٹا کا تبادلہ پش اور پل کا استعمال کرتے ہوئے ہوتا ہے۔ اس مثال میں ہم ایک فعال ایکٹیو کنفیگریشن پر غور کریں گے۔ پورے فن تعمیر کو بیان کرنے میں بہت زیادہ وقت لگے گا، لہذا اپنی تحقیق کریں۔ رہنماSymmetricDS ڈیوائس کے بارے میں مزید جاننے کے لیے۔

SymmetricDS انسٹال کرنا بہت آسان ہے: زپ فائل کا اوپن سورس ورژن ڈاؤن لوڈ کریں۔ اس وجہ سے اور جہاں چاہو باہر لے جاؤ۔ نیچے دی گئی جدول اس مثال میں SymmetricDS کے انسٹالیشن لوکیشن اور ورژن کے بارے میں معلومات فراہم کرتی ہے، نیز ڈیٹا بیس ورژنز، لینکس ورژنز، IP ایڈریسز، اور دونوں نوڈس کے لیے پورٹس۔

میزبان
vm1۔
vm2۔

OS ورژن
CentOS لینکس 7.6 x86_64
CentOS لینکس 7.6 x86_64

ڈی بی سرور ورژن
ایس کیو ایل 5.7.26
پوسٹگر ایس ایس ایل 10.5

ڈی بی پورٹ
3306
5832

IP ایڈریس
192.168.1.107
192.168.1.112

SymmetricDS ورژن
SymmetricDS 3.9
SymmetricDS 3.9

SymmetricDS تنصیب کا راستہ
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

SymmetricDS نوڈ کا نام
corp-000
اسٹور -001

یہاں ہم SymmetricDS کو /usr/local/symmetric-server-3.9.20 میں انسٹال کرتے ہیں، اور مختلف ذیلی ڈائرکٹریاں اور فائلیں وہاں محفوظ کی جائیں گی۔ ہم نمونوں اور انجنوں کی ذیلی ڈائریکٹریوں میں دلچسپی رکھتے ہیں۔ نمونے کی ڈائرکٹری میں نوڈ پراپرٹیز کے ساتھ مثال کنفیگریشن فائلز کے ساتھ ساتھ آپ کو تیزی سے شروع کرنے کے لیے مثال SQL اسکرپٹس پر مشتمل ہے۔

نمونے کی ڈائرکٹری میں ہم نوڈ کی خصوصیات کے ساتھ تین کنفیگریشن فائلیں دیکھتے ہیں - نام ایک مخصوص اسکیم میں نوڈ کی نوعیت کو ظاہر کرتا ہے۔

corp-000.properties
store-001.properties
store-002.properties

SymmetricDS کے پاس بنیادی 3-نوڈ ڈیزائن (آپشن 1) کے لیے تمام ضروری کنفیگریشن فائلیں ہیں، اور وہی فائلیں 2-نوڈ ڈیزائن (آپشن 2) کے لیے استعمال کی جا سکتی ہیں۔ مطلوبہ کنفیگریشن فائل کو نمونے کی ڈائرکٹری سے vm1 ہوسٹ پر انجنوں میں کاپی کریں۔ یہ اس طرح نکلتا ہے:

$> cat engines/corp-000.properties
engine.name=corp-000
db.driver=com.mysql.jdbc.Driver
db.url=jdbc:mysql://192.168.1.107:3306/replica_db?autoReconnect=true&useSSL=false
db.user=root
db.password=admin123
registration.url=
sync.url=http://192.168.1.107:31415/sync/corp-000
group.id=corp
external.id=000

SymmetricDS کنفیگریشن میں اس نوڈ کو corp-000 کہا جاتا ہے، اور ڈیٹا بیس کنکشن کو mysql jdbc ڈرائیور ہینڈل کرتا ہے، جو اوپر دی گئی کنکشن سٹرنگ اور لاگ ان کی اسناد کا استعمال کرتا ہے۔ ہم replica_db ڈیٹا بیس سے جڑتے ہیں اور اسکیما کی تخلیق کے دوران ٹیبل بنائے جائیں گے۔ sync.url مطابقت پذیری کے لیے نوڈ سے کنکشن کا مقام دکھاتا ہے۔

میزبان vm2 پر نوڈ 2 کو اسٹور-001 کے طور پر ترتیب دیا گیا ہے اور باقی ذیل میں node.properties فائل میں بیان کیا گیا ہے۔ Node store-001 PostgreSQL ڈیٹا بیس چلاتا ہے اور pgdb_replica نقل کا ڈیٹا بیس ہے۔ registration.url میزبان vm2 کو میزبان vm1 سے رابطہ کرنے اور اس سے کنفیگریشن کی تفصیلات حاصل کرنے کی اجازت دیتا ہے۔

$> cat engines/store-001.properties
engine.name=store-001
db.driver=org.postgresql.Driver
db.url=jdbc:postgresql://192.168.1.112:5832/pgdb_replica
db.user=postgres
db.password=admin123
registration.url=http://192.168.1.107:31415/sync/corp-000
group.id=store
external.id=001

مکمل شدہ SymmetricDS مثال دو ڈیٹا بیس سرورز (دو نوڈس) کے درمیان دو طرفہ نقل ترتیب دینے کے لیے پیرامیٹرز پر مشتمل ہے۔ نیچے دیے گئے اقدامات میزبان vm1 (corp-000) پر کیے گئے ہیں، جو 4 ٹیبلز کے ساتھ ایک مثالی اسکیما بنائے گا۔ پھر symadmin کمانڈ کے ساتھ create-sym-tables چلانے سے ڈائریکٹری ٹیبلز بنتی ہیں جہاں نوڈس کے درمیان نقل کے قواعد اور سمت کو محفوظ کیا جائے گا۔ آخر میں، نمونہ ڈیٹا میزوں میں بھری ہوئی ہے۔

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> ./dbimport --engine corp-000 --format XML create_sample.xml
vm1$> ./symadmin --engine corp-000 create-sym-tables
vm1$> ./dbimport --engine corp-000 insert_sample.sql

مثال میں، آئٹم اور آئٹم_سیلنگ_پرائس ٹیبلز خودکار طور پر corp-000 سے اسٹور-001 تک نقل کرنے کے لیے ترتیب دی جاتی ہیں، اور سیل ٹیبلز (sale_transaction اور sale_return_line_item) اسٹور-001 سے corp-000 تک نقل کرنے کے لیے خودکار طور پر ترتیب دی جاتی ہیں۔ اب ہم میزبان vm2 (store-001) پر PostgreSQL ڈیٹا بیس میں ایک اسکیما بناتے ہیں تاکہ اسے corp-000 سے ڈیٹا حاصل کرنے کے لیے تیار کیا جا سکے۔

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> ./dbimport --engine store-001 --format XML create_sample.xml

اس بات کو یقینی بنائیں کہ vm1 پر MySQL ڈیٹا بیس میں مثال کی میزیں اور SymmetricDS کیٹلاگ کی میزیں ہیں۔ نوٹ کریں کہ SymmetricDS سسٹم ٹیبلز (sym_ کے ساتھ پریفکسڈ) فی الحال صرف node corp-000 پر دستیاب ہیں کیونکہ اسی جگہ ہم نے create-sym-tables کمانڈ چلائی اور نقل کا انتظام کریں گے۔ اور node store-001 کے ڈیٹا بیس میں ڈیٹا کے بغیر صرف 4 مثالی میزیں ہوں گی۔

تمام ماحول دونوں نوڈس پر سم سرور کے عمل کو چلانے کے لیے تیار ہے جیسا کہ ذیل میں دکھایا گیا ہے۔

vm1$> cd /usr/local/symmetric-server-3.9.20/bin
vm1$> sym 2>&1 &

لاگ انٹریز کو بیک گراؤنڈ لاگ فائل (symmetric.log) میں لاگس فولڈر میں ڈائرکٹری میں بھیجی جاتی ہے جہاں SymmetricDS انسٹال ہوتا ہے، نیز معیاری آؤٹ پٹ پر۔ سم سرور کو اب نوڈ اسٹور-001 پر شروع کیا جا سکتا ہے۔

vm2$> cd /usr/local/symmetric-server-3.9.20/bin
vm2$> sym 2>&1 &

اگر آپ vm2 ہوسٹ پر sym سرور کا عمل چلاتے ہیں، تو یہ PostgreSQL ڈیٹا بیس میں SymmetricDS کیٹلاگ ٹیبلز بھی بنائے گا۔ اگر آپ سم سرور کے عمل کو دونوں نوڈس پر چلاتے ہیں، تو وہ کارپوریشن-000 سے اسٹور-001 تک ڈیٹا کی نقل تیار کرنے کے لیے ایک دوسرے کے ساتھ ہم آہنگی پیدا کرتے ہیں۔ اگر چند سیکنڈز کے بعد ہم دونوں اطراف کے تمام 4 ٹیبلز سے استفسار کرتے ہیں، تو ہم دیکھیں گے کہ نقل کامیاب رہی۔ یا آپ بوٹسٹریپ کو corp-001 سے node store-000 پر درج ذیل کمانڈ کے ساتھ بھیج سکتے ہیں۔

vm1$> ./symadmin --engine corp-000 reload-node 001

اس وقت، نوڈ corp-000 (میزبان: vm1) پر MySQL ڈیٹا بیس میں آئٹم ٹیبل میں ایک نیا ریکارڈ داخل کیا جاتا ہے، اور آپ نوڈ اسٹور-001 (میزبان: vm2) پر پوسٹگری ایس کیو ایل ڈیٹا بیس میں اس کی نقل کو چیک کر سکتے ہیں۔ ہم ڈیٹا کو corp-000 سے سٹور-001 میں منتقل کرنے کے لیے ایک پل آپریشن دیکھتے ہیں۔

mysql> insert into item values ('22000002','Jelly Bean');
Query OK, 1 row affected (0.00 sec)

vm2$> psql -p 5832 -U postgres pgdb_replica -c "select * from item"
 item_id  |   name
----------+-----------
 11000001 | Yummy Gum
 22000002 | Jelly Bean
(2 rows)

سٹور-001 سے corp-000 میں ڈیٹا منتقل کرنے کے لیے پش آپریشن کرنے کے لیے، ہم sale_transaction ٹیبل میں ایک ریکارڈ داخل کرتے ہیں اور تصدیق کرتے ہیں کہ نقل کامیاب ہے۔

نتیجہ

ہم MySQL اور PostgreSQL ڈیٹا بیس کے درمیان مثال کے جدولوں کی دو طرفہ نقل کا کامیاب سیٹ اپ دیکھتے ہیں۔ نئے یوزر ٹیبلز کے لیے نقل ترتیب دینے کے لیے، ان مراحل پر عمل کریں: ہم مثال کے طور پر ٹیبل ٹی 1 بناتے ہیں اور اس کے نقل کے اصول مندرجہ ذیل ترتیب دیتے ہیں۔ اس طرح ہم corp-000 سے سٹور-001 تک صرف نقل تیار کرتے ہیں۔

mysql> create table  t1 (no integer);
Query OK, 0 rows affected (0.01 sec)

mysql> insert into sym_channel (channel_id,create_time,last_update_time) 
values ('t1',current_timestamp,current_timestamp);
Query OK, 1 row affected (0.01 sec)

mysql> insert into sym_trigger (trigger_id, source_table_name,channel_id,
last_update_time, create_time) values ('t1', 't1', 't1', current_timestamp,
current_timestamp);
Query OK, 1 row affected (0.01 sec)

mysql> insert into sym_trigger_router (trigger_id, router_id,
Initial_load_order, create_time,last_update_time) values ('t1',
'corp-2-store-1', 1, current_timestamp,current_timestamp);
Query OK, 1 row affected (0.01 sec)

اس کے بعد کنفیگریشن کو اسکیما کی تبدیلی کے بارے میں مطلع کیا جاتا ہے، یعنی ایک نئے ٹیبل کا اضافہ، sync-triggers argument کے ساتھ symadmin کمانڈ کا استعمال کرتے ہوئے، جو ٹیبل کی تعریفوں کو نقشہ بنانے کے لیے محرکات کو دوبارہ بناتا ہے۔ send-schema کو نوڈ اسٹور-001 میں اسکیما تبدیلیاں بھیجنے کے لیے عمل میں لایا جاتا ہے، اور ٹیبل t1 کی نقل ترتیب دی جاتی ہے۔

vm1$> ./symadmin -e corp-000 --node=001 sync-triggers    
vm1$> ./symadmin send-schema -e corp-000 --node=001 t1

SymmetricDS کے فوائد

آسان تنصیب اور ترتیب، بشمول تین نوڈ یا دو نوڈ سرکٹ بنانے کے لیے پیرامیٹرز کے ساتھ فائلوں کا تیار سیٹ۔
کراس پلیٹ فارم ڈیٹا بیس اور پلیٹ فارم کی آزادی، بشمول سرورز، لیپ ٹاپس اور موبائل آلات۔
کسی بھی ڈیٹا بیس کو مقامی طور پر، WAN پر یا کلاؤڈ میں کسی دوسرے ڈیٹا بیس میں نقل کریں۔
آسان نقل کے لیے چند ڈیٹا بیس یا کئی ہزار کے ساتھ بہترین کام کا امکان۔
GUI اور بہترین سپورٹ کے ساتھ ادا شدہ ورژن۔

SymmetricDS کے نقصانات

کیٹلاگ ٹیبلز کو لوڈ کرنے کے لیے آپ کو کمانڈ لائن پر ایس کیو ایل اسٹیٹمنٹس کے ذریعے نقل کے قواعد اور سمت کو دستی طور پر بیان کرنے کی ضرورت ہے، جو کہ تکلیف دہ ہوسکتی ہے۔
نقل کے لیے بہت سی جدولیں ترتیب دینا مشکل ہو سکتا ہے جب تک کہ آپ ایس کیو ایل سٹیٹمنٹس بنانے کے لیے اسکرپٹس کا استعمال نہ کریں جو نقل کے قواعد اور سمت کی وضاحت کرتے ہیں۔
لاگز میں بہت زیادہ معلومات ریکارڈ کی جاتی ہیں، اور بعض اوقات آپ کو لاگ فائل کو صاف کرنے کی ضرورت ہوتی ہے تاکہ یہ زیادہ جگہ نہ لے۔

SymmetricDS کے نتائج

SymmetricDS آپ کو دو، تین، یا یہاں تک کہ کئی ہزار نوڈس کے درمیان دو طرفہ نقل ترتیب دینے کی اجازت دیتا ہے تاکہ فائلوں کو نقل اور مطابقت پذیر بنایا جا سکے۔ یہ ایک انوکھا ٹول ہے جو آزادانہ طور پر بہت سے کام انجام دیتا ہے، جیسے کہ نوڈ پر طویل مدت کے بند ہونے کے بعد خودکار ڈیٹا کی بازیافت، HTTPS کے ذریعے نوڈس کے درمیان محفوظ اور موثر ڈیٹا کا تبادلہ، قوانین کے ایک سیٹ کی بنیاد پر خودکار تنازعات کا انتظام وغیرہ۔ SymmetricDS انجام دیتا ہے۔ کسی بھی ڈیٹا بیس کے درمیان نقل، اس لیے، اسے مختلف قسم کے منظرناموں کے لیے استعمال کیا جا سکتا ہے، بشمول نقل مکانی، منتقلی، تقسیم، فلٹرنگ، اور پلیٹ فارمز میں ڈیٹا کی تبدیلی۔

مثال سرکاری پر مبنی ہے۔ فوری گائیڈ SymmetricDS کی طرف سے. میں صارف دستی SymmetricDS کے ساتھ نقل ترتیب دینے میں شامل مختلف تصورات کو تفصیل سے بیان کرتا ہے۔

ماخذ: www.habr.com