Gambaran Umum Replikasi Silang PostgreSQL &MySQL

Blog ini bertujuan untuk menjelaskan gambaran umum tentang replikasi silang antara PostgreSQL dan MySQL, dan membahas lebih lanjut metode konfigurasi replikasi silang antara dua server database. Secara tradisional, database yang terlibat dalam pengaturan replikasi silang disebut database heterogen, yang merupakan pendekatan yang baik untuk berpindah dari satu server RDBMS ke server RDBMS lainnya.

Baik database PostgreSQL dan MySQL secara konvensional adalah database RDBMS tetapi mereka juga menawarkan kemampuan NoSQL dengan ekstensi tambahan untuk mendapatkan yang terbaik dari kedua dunia. Artikel ini berfokus pada pembahasan replikasi antara PostgreSQL dan MySQL dari perspektif RDBMS.

Penjelasan lengkap tentang internal replikasi tidak dalam lingkup blog ini, namun, beberapa elemen dasar akan dibahas untuk memberikan pemahaman kepada audiens tentang bagaimana replikasi dikonfigurasi antara server database, keuntungan, keterbatasan dan mungkin beberapa kasus penggunaan yang diketahui.

Secara umum replikasi antara dua server database yang identik dicapai baik dalam mode biner atau mode kueri antara node master (atau disebut penerbit, primer atau aktif) dan node budak (pelanggan, siaga atau pasif). Tujuan dari replikasi adalah untuk menyediakan salinan real-time dari database master di sisi slave, di mana data ditransfer dari master ke slave, sehingga membentuk pengaturan aktif-pasif karena replikasi hanya dikonfigurasi untuk terjadi satu arah. Di sisi lain, replikasi antara dua database dapat dikonfigurasi dua arah sehingga data juga dapat ditransfer dari slave kembali ke master, membentuk konfigurasi aktif-aktif. Semua ini dapat dikonfigurasi antara dua atau lebih server database yang identik yang mungkin juga mencakup replikasi cascading. Konfigurasi active-active atau active-passive sangat tergantung pada kebutuhan bisnis, ketersediaan fitur tersebut dalam konfigurasi asli atau penggunaan solusi eksternal untuk mengkonfigurasi dan trade-off yang berlaku.

Konfigurasi yang disebutkan di atas dapat dicapai dengan server basis data yang beragam, di mana server basis data dapat dikonfigurasi untuk menerima data yang direplikasi dari server basis data lain yang sama sekali berbeda dan masih mempertahankan snapshot waktu nyata dari data yang direplikasi. Server database MySQL dan PostgreSQL menawarkan sebagian besar konfigurasi yang dibahas di atas baik dalam nativity mereka sendiri atau dengan bantuan ekstensi pihak ketiga termasuk metode log biner, metode blok disk, metode berbasis pernyataan dan metode berbasis baris.

Persyaratan untuk mengonfigurasi replikasi silang antara MySQL dan PostgreSQL benar-benar muncul sebagai hasil dari upaya migrasi satu kali untuk berpindah dari satu server database ke server database lainnya. Karena kedua database menggunakan protokol yang berbeda sehingga mereka tidak dapat langsung berbicara satu sama lain. Untuk mencapai alur komunikasi itu, ada alat open source eksternal seperti pg_chameleon.

Latar belakang pg_chameleon

pg_chameleon adalah sistem replikasi MySQL ke PostgreSQL yang dikembangkan dengan Python 3. Ini menggunakan perpustakaan sumber terbuka yang disebut mysql-replication yang juga dikembangkan menggunakan Python. Fungsionalitasnya melibatkan pengambilan gambar baris tabel MySQL dan menyimpannya sebagai objek JSONB ke dalam database PostgreSQL, yang selanjutnya didekode oleh fungsi pl/pgsql dan memutar ulang perubahan tersebut terhadap database PostgreSQL.

Fitur pg_chameleon

• Beberapa skema MySQL dari cluster yang sama dapat direplikasi ke database PostgreSQL target tunggal, membentuk pengaturan replikasi banyak-ke-satu
• Nama skema sumber dan target tidak boleh sama
• Data replikasi dapat diambil dari replika cascading MySQL
• Tabel yang gagal mereplikasi atau menghasilkan kesalahan dikecualikan
• Setiap fungsi replikasi dikelola dengan bantuan daemon
• Dikontrol dengan bantuan parameter dan file konfigurasi berdasarkan konstruksi YAML

Demo

Untuk memulainya, siapkan pengaturan dengan semua prasyarat yang diperlukan untuk menginstal pg_chameleon. Dalam demo ini Python 3.6.8 diinstal, menciptakan lingkungan virtual dan mengaktifkannya untuk digunakan.

$> 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

Setelah instalasi Python3.6 berhasil, persyaratan tambahan lebih lanjut terpenuhi seperti membuat dan mengaktifkan lingkungan virtual. Selain itu modul pip ditingkatkan ke versi terbaru dan digunakan untuk menginstal pg_chameleon. Pada perintah di bawah ini, pg_chameleon 2.0.9 sengaja diinstal sedangkan versi terbaru adalah 2.0.10. Ini dilakukan untuk menghindari bug yang baru diperkenalkan di versi yang diperbarui.

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

Langkah selanjutnya adalah memanggil pg_chameleon (bunglon adalah perintahnya) dengan argumen set_configuration_files untuk mengaktifkan pg_chameleon untuk membuat direktori dan file konfigurasi default.

(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

Sekarang, buat salinan config-example.yml sebagai default.yml untuk menjadikannya file konfigurasi default. Contoh file konfigurasi yang digunakan untuk demo ini disediakan di bawah ini.

$> 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:

File konfigurasi yang digunakan dalam demo ini adalah file sampel yang disertakan dengan pg_chameleon dengan sedikit pengeditan agar sesuai dengan lingkungan sumber dan tujuan, dan ringkasan bagian berbeda dari file konfigurasi berikut.

File konfigurasi default.yml memiliki bagian "pengaturan global" yang mengontrol detail seperti lokasi file kunci, lokasi logging dan periode penyimpanan, dll. Bagian berikutnya adalah bagian "penggantian tipe" yang merupakan seperangkat aturan untuk diganti jenis selama replikasi. Aturan penggantian tipe sampel digunakan secara default yang mengubah tinyint(1) menjadi nilai boolean. Bagian selanjutnya adalah bagian detail koneksi database tujuan yang dalam kasus kami adalah database PostgreSQL, dilambangkan dengan “pg_conn”. Bagian terakhir adalah bagian sumber yang memiliki semua detail pengaturan koneksi basis data sumber, pemetaan skema antara sumber dan tujuan, tabel apa pun untuk dilewati termasuk pengaturan batas waktu, memori, dan ukuran batch. Perhatikan "sumber" yang menunjukkan bahwa mungkin ada banyak sumber ke satu tujuan untuk membentuk pengaturan replikasi banyak-ke-satu.

Basis data "world_x" digunakan dalam demo ini yang merupakan basis data sampel dengan 4 tabel yang berisi baris sampel, yang ditawarkan komunitas MySQL untuk tujuan demo, dan dapat diunduh dari sini. Basis data sampel hadir sebagai arsip tar dan terkompresi bersama dengan instruksi untuk membuatnya dan mengimpor baris di dalamnya.

Pengguna khusus dibuat di database MySQL dan PostgreSQL dengan nama yang sama dengan usr_replica yang selanjutnya diberikan hak istimewa tambahan pada MySQL untuk memiliki akses baca ke semua tabel yang direplikasi.

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;

Sebuah database dibuat di sisi PostgreSQL yang akan menerima perubahan dari database MySQL, yang disebut sebagai “db_replica”. Pengguna "usr_replica" di PostgreSQL secara otomatis dikonfigurasi sebagai pemilik dua skema seperti "pgworld_x" dan "sch_chameleon" yang masing-masing berisi tabel yang direplikasi dan tabel katalog replikasi. Konfigurasi otomatis ini dilakukan oleh argumen create_replica_schema, yang ditunjukkan lebih lanjut di bawah.

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

Database MySQL dikonfigurasi dengan beberapa perubahan parameter untuk mempersiapkannya untuk replikasi, seperti yang ditunjukkan di bawah ini, dan server database memerlukan restart agar perubahan diterapkan.

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

Pada titik ini, penting untuk menguji konektivitas ke kedua server database untuk memastikan tidak ada masalah saat perintah pg_chameleon dijalankan.

Pada simpul PostgreSQL:

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

Pada simpul MySQL:

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

Tiga perintah berikutnya dari pg_chameleon (bunglon) adalah tempat ia mengatur lingkungan, menambahkan sumber, dan menginisialisasi replika. Argumen “create_replica_schema” dari pg_chameleon membuat skema default (sch_chameleon) dan skema replikasi (pgworld_x) dalam database PostgreSQL seperti yang telah dibahas. Argumen “add_source” menambahkan database sumber ke konfigurasi dengan membaca file konfigurasi (default.yml), yang dalam hal ini adalah “mysql”, sedangkan “init_replica” menginisialisasi konfigurasi berdasarkan pengaturan file konfigurasi.

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

Output dari tiga perintah di atas cukup jelas yang menunjukkan keberhasilan setiap perintah dengan pesan output yang jelas. Setiap kegagalan atau kesalahan sintaks secara jelas disebutkan dalam pesan sederhana dan sederhana, sehingga menyarankan dan mendorong tindakan korektif.

Langkah terakhir adalah memulai replikasi dengan “start_replica”, yang keberhasilannya ditunjukkan oleh petunjuk keluaran seperti yang ditunjukkan di bawah ini.

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

Status replikasi dapat ditanyakan dengan argumen "show_status" sementara kesalahan dapat dilihat dengan argumen 'show_errors".

$> chameleon show_status --source mysql  
OUTPUT: 
  Source id  Source name    Type    Status    Consistent    Read lag    Last read    Replay lag    Last replay
-----------  -------------  ------  --------  ------------  ----------  -----------  ------------  -------------
          1  mysql          mysql   running   No            N/A                      N/A

== Schema mappings ==
Origin schema    Destination schema
---------------  --------------------
world_x          pgworld_x

== Replica status ==
---------------------  ---
Tables not replicated  0
Tables replicated      4
All tables             4
Last maintenance       N/A
Next maintenance       N/A
Replayed rows
Replayed DDL
Skipped rows
---------------------  ---
$> chameleon show_errors --config default 
output: There are no errors in the log

Seperti yang telah dibahas sebelumnya bahwa setiap fungsi replikasi dikelola dengan bantuan daemon, yang dapat dilihat dengan menanyakan tabel proses menggunakan perintah “ps” Linux, yang ditunjukkan di bawah ini.

$>  ps -ef|grep chameleon
root       763     1  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       764   763  0 19:20 ?        00:00:01 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql
root       765   763  0 19:20 ?        00:00:00 /u01/media/mysql_samp_dbs/world_x-db/venv/bin/python3.6 /u01/media/mysq l_samp_dbs/world_x-db/venv/bin/chameleon start_replica --config default --source mysql

Tidak ada pengaturan replikasi yang selesai sampai diuji "aplikasi waktu nyata", yang telah disimulasikan seperti di bawah ini. Ini melibatkan pembuatan tabel dan memasukkan beberapa catatan dalam database MySQL, selanjutnya, argumen "sync_tables" dari pg_chameleon dipanggil untuk memperbarui daemon untuk mereplikasi tabel bersama dengan catatannya ke database PostgreSQL.

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.

Pengujian dikonfirmasi dengan menanyakan tabel dari database PostgreSQL untuk mencerminkan baris.

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

Jika ini adalah proyek migrasi maka perintah pg_chameleon berikut akan menandai akhir dari upaya migrasi. Perintah harus dijalankan setelah dikonfirmasi bahwa baris dari semua tabel target telah direplikasi, dan hasilnya akan menjadi database PostgreSQL yang dimigrasikan dengan rapi tanpa referensi ke database sumber atau skema replikasi (sch_chameleon).

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

Secara opsional, perintah berikut akan menghapus konfigurasi sumber dan skema replikasi.

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

Kelebihan Menggunakan pg_chameleon

• Penyetelan yang mudah dan konfigurasi yang tidak terlalu rumit
• Pemecahan masalah tanpa rasa sakit dan deteksi anomali dengan keluaran kesalahan yang mudah dipahami
• Tabel adhoc tambahan dapat ditambahkan ke replikasi setelah inisialisasi, tanpa mengubah konfigurasi lainnya
• Beberapa sumber dapat dikonfigurasi untuk satu database tujuan, yang berguna dalam proyek konsolidasi untuk menggabungkan data dari satu atau lebih database MySQL ke dalam satu database PostgreSQL
• Tabel yang dipilih dapat dilewati agar tidak direplikasi

Kontra Menggunakan pg_chameleon

• Hanya didukung dari MySQL 5.5 dan seterusnya sebagai database Asal dan PostgreSQL 9.5 dan seterusnya untuk database tujuan
• Memerlukan setiap tabel untuk memiliki kunci utama atau unik, jika tidak, tabel akan diinisialisasi selama proses init_replica tetapi mereka akan gagal untuk direplikasi
• Replikasi satu arah, yaitu MySQL ke PostgreSQL. Dengan demikian membatasi penggunaannya hanya untuk pengaturan aktif-pasif
• Database sumber hanya dapat berupa database MySQL sedangkan dukungan untuk database PostgreSQL sebagai sumber bersifat eksperimental dengan batasan lebih lanjut (klik di sini untuk mempelajari lebih lanjut)

Ringkasan pg_bunglon

Pendekatan replikasi yang ditawarkan oleh pg_chameleon menguntungkan untuk migrasi database MySQL ke PostgreSQL. Namun, salah satu batasan signifikan dari replikasi satu arah dapat mencegah profesional database untuk mengadopsinya selain untuk migrasi. Kelemahan dari replikasi satu arah ini dapat diatasi dengan menggunakan alat open source lain yang disebut SymmetricDS.

Untuk mempelajari utilitas lebih detail, silakan merujuk ke dokumentasi resmi di sini. Referensi baris perintah dapat diperoleh dari sini.

Ikhtisar SymmetricDS

SymmetricDS adalah alat open source yang mampu mereplikasi database apa pun ke database lain, dari daftar server database populer seperti Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird dan instans database berbasis cloud lainnya seperti Redshift dan Azure dll. Beberapa penawaran termasuk sinkronisasi database dan file, replikasi multi-master, sinkronisasi terfilter, dan transformasi. Alat ini dikembangkan menggunakan Java, membutuhkan edisi standar (versi 8.0 atau lebih tinggi) baik JRE atau JDK. Fungsionalitasnya melibatkan perubahan data yang ditangkap oleh pemicu di basis data sumber dan merutekannya ke basis data tujuan yang berpartisipasi sebagai kumpulan keluar

Fitur SymmetricDS

• Platform independent, yang berarti dua atau lebih database yang berbeda dapat berkomunikasi satu sama lain, database apapun ke database lainnya
• Basis data relasional mencapai sinkronisasi menggunakan perubahan pengambilan data sementara sistem berbasis sistem file menggunakan sinkronisasi file
• Replikasi dua arah menggunakan metode Push and Pull, yang dilakukan berdasarkan aturan yang ditetapkan
• Transfer data juga dapat terjadi melalui jaringan bandwidth yang aman dan rendah
• Pemulihan otomatis selama dimulainya kembali node yang mogok dan resolusi konflik otomatis
• Siap cloud dan berisi API ekstensi yang andal

Demo

SymmetricDS dapat dikonfigurasi dalam salah satu dari dua opsi:

• Node master (induk) yang bertindak sebagai perantara tersentralisasi yang mengoordinasikan replikasi data antara dua node budak (anak), di mana komunikasi antara dua node anak hanya dapat terjadi melalui induk.
• Sebuah node aktif (node1) dapat mereplikasi ke dan dari node aktif lainnya (node2) tanpa perantara.

Di kedua opsi, komunikasi antara node terjadi melalui peristiwa "Push" dan "Pull". Dalam demo ini, konfigurasi aktif-aktif antara dua node akan dijelaskan. Arsitektur lengkapnya bisa sangat lengkap, sehingga pembaca didorong untuk memeriksa panduan pengguna yang tersedia di sini untuk mempelajari lebih lanjut tentang internal SymmetricDS.

Menginstal SymmetricDS semudah mengunduh file zip versi open source dari sini dan mengekstraknya di lokasi yang nyaman. Detail lokasi penginstalan dan versi SymmetricDS dalam demo ini sesuai tabel di bawah ini, bersama dengan detail lain yang berkaitan dengan versi database, versi Linux, alamat ip, dan port komunikasi untuk kedua node yang berpartisipasi.

Rumah instalasi dalam hal ini adalah “/usr/local/symmetric-server-3.9.20” yang akan menjadi direktori home SymmetricDS, yang berisi berbagai sub-direktori dan file lainnya. Dua dari sub-direktori yang penting sekarang adalah "sampel" dan "mesin". Direktori sampel berisi sampel file konfigurasi properti node selain skrip SQL sampel untuk memulai demo cepat.

Tiga file konfigurasi properti node berikut dapat dilihat di direktori “sampel” dengan nama yang menunjukkan sifat node dalam pengaturan tertentu.

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

Karena SymmetricDS dilengkapi dengan semua file konfigurasi yang diperlukan untuk mendukung pengaturan 3 node dasar (opsi 1), akan lebih mudah untuk menggunakan file konfigurasi yang sama untuk menyiapkan pengaturan 2 node (opsi 2) juga. File konfigurasi yang dimaksud disalin dari direktori “samples” ke “engines” pada host vm1, dan tampilannya seperti di bawah ini.

$> 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

Nama node ini dalam konfigurasi SymmetricDS adalah “corp-000” dengan koneksi database yang ditangani dengan driver jdbc mysql menggunakan string koneksi seperti yang dinyatakan di atas bersama dengan kredensial login. Basis data yang akan dihubungkan adalah “replica_db” dan tabel akan dibuat selama pembuatan skema sampel. “sync.url” menunjukkan lokasi untuk menghubungi node untuk sinkronisasi.

Node 2 pada host vm2 dikonfigurasi sebagai "store-001" dengan rincian lainnya seperti yang dikonfigurasi dalam file node.properties, yang ditunjukkan di bawah ini. Node "store-001" menjalankan database PostgreSQL, dengan "pgdb_replica" sebagai database untuk replikasi. “registration.url” memungkinkan host “vm2” berkomunikasi dengan host “vm1” untuk menarik detail konfigurasi.

$> 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

Demo default SymmetricDS yang telah dikonfigurasi sebelumnya berisi pengaturan untuk menyiapkan replikasi dua arah antara dua server database (dua node). Langkah-langkah di bawah ini dijalankan pada host vm1 (corp-000), yang akan membuat skema sampel yang memiliki 4 tabel. Selanjutnya, eksekusi "create-sym-tables" dengan perintah "symadmin" akan membuat tabel katalog yang menyimpan dan mengontrol aturan dan arah replikasi antar node. Terakhir, tabel demo dimuat dengan data sampel.

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

Tabel demo "item" dan "item_selling_price" dikonfigurasi secara otomatis untuk mereplikasi dari corp-000 ke store-001 sedangkan tabel penjualan (sale_transaction dan sale_return_line_item) dikonfigurasi secara otomatis untuk direplikasi dari store-001 ke corp-000. Langkah selanjutnya adalah membuat contoh skema di database PostgreSQL pada host vm2 (store-001), untuk mempersiapkannya menerima data dari corp-000.

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

Penting untuk memverifikasi keberadaan tabel demo dan tabel katalog SymmetricDS di database MySQL pada vm1 pada tahap ini. Catatan, tabel sistem SymmetricDS (tabel dengan awalan “sym_”) hanya tersedia di node corp-000 saat ini, karena di situlah perintah “create-sym-tables” dijalankan, yang akan menjadi tempatnya untuk mengontrol dan mengelola replikasi. Selain itu, database node store-001 hanya akan memiliki 4 tabel demo tanpa data di dalamnya.

Lingkungan sekarang siap untuk memulai proses server “sym” di kedua node, seperti yang ditunjukkan di bawah ini.

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

Entri log keduanya dikirim ke file log latar belakang (symmetric.log) di bawah direktori log di lokasi pemasangan SymmetricDS serta ke output standar. Server “sym” sekarang dapat dimulai pada node store-001.

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

Proses startup server “sym” pada host vm2 juga akan membuat tabel katalog SymmetricDS di database PostgreSQL. Proses awal server "sym" pada kedua node akan membuat mereka berkoordinasi satu sama lain untuk mereplikasi data dari corp-000 ke store-001. Setelah beberapa detik, kueri keempat tabel di kedua sisi akan menampilkan hasil replikasi yang berhasil. Sebagai alternatif, beban awal juga dapat dikirim ke node store-001 dari corp-000 dengan perintah di bawah ini.

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

Pada titik ini, sebuah record baru dimasukkan ke dalam tabel “item” di database MySQL pada node corp-000 (host:vm1) dan dapat diverifikasi untuk berhasil direplikasi ke database PostgreSQL di node store-001 (host:vm2 ). Ini menunjukkan peristiwa “Tarik” data dari corp-000 ke store-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)

Peristiwa “Push” data dari store-001 ke corp-000 dapat dicapai dengan memasukkan record ke dalam tabel “sale_transaction” dan mengonfirmasinya untuk direplikasi.

pgdb_replica=# insert into "sale_transaction" ("tran_id", "store_id", "workstation", "day", "seq") values (1000, '001', '3', '2007-11-01', 100);
vm1$> [[email protected] ~]#  mysql -uroot -p'admin123' -D replica_db -e "select * from sale_transaction";
+---------+----------+-------------+------------+-----+
| tran_id | store_id | workstation | day        | seq |
+---------+----------+-------------+------------+-----+
|     900 | 001      | 3           | 2012-12-01 |  90 |
|    1000 | 001      | 3           | 2007-11-01 | 100 |
|    2000 | 002      | 2           | 2007-11-01 | 200 |
+---------+----------+-------------+------------+-----+

Ini menandai keberhasilan konfigurasi replikasi dua arah tabel demo antara database MySQL dan PostgreSQL. Padahal, konfigurasi replikasi untuk tabel pengguna yang baru dibuat dapat dicapai dengan menggunakan langkah-langkah berikut. Contoh tabel "t1" dibuat untuk demo dan aturan replikasinya dikonfigurasi sesuai prosedur di bawah ini. Langkah-langkahnya hanya mengonfigurasi replikasi dari corp-000 ke store-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)

Setelah ini, konfigurasi diberi tahu tentang perubahan skema penambahan tabel baru dengan menjalankan perintah symadmin dengan argumen “sync-triggers” yang akan membuat ulang pemicu agar sesuai dengan definisi tabel. Selanjutnya, jalankan “send-schema” untuk mengirim perubahan skema ke store-001 node, setelah itu replikasi tabel “t1” akan berhasil dikonfigurasi.

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

Pro menggunakan SymmetricDS

• Penginstalan dan konfigurasi yang mudah termasuk kumpulan file parameter yang telah dikonfigurasi sebelumnya untuk membuat pengaturan 3-simpul atau 2-simpul
• Database lintas platform diaktifkan dan platform independen termasuk server, laptop, dan perangkat seluler
• Menggandakan database apa pun ke database lain, baik lokal, WAN, atau cloud
• Mampu menangani secara optimal beberapa database hingga beberapa ribu database untuk mereplikasi data dengan mulus
• Versi komersial dari perangkat lunak ini menawarkan konsol manajemen berbasis GUI dengan paket dukungan yang sangat baik

Kontra Penggunaan SymmetricDS

• Konfigurasi baris perintah manual mungkin melibatkan penetapan aturan dan arah replikasi melalui pernyataan SQL untuk memuat tabel katalog, yang mungkin tidak nyaman untuk dikelola
• Menyiapkan sejumlah besar tabel untuk replikasi akan menjadi upaya yang melelahkan, kecuali beberapa bentuk skrip digunakan untuk menghasilkan pernyataan SQL yang mendefinisikan aturan dan arah replikasi
• Banyak informasi logging yang mengacaukan file log, sehingga memerlukan pemeliharaan file log secara berkala agar file log tidak memenuhi disk

Ringkasan SymmetricDS

SymmetricDS menawarkan kemampuan untuk mengatur replikasi dua arah antara 2 node, 3 node dan seterusnya untuk beberapa ribu node untuk mereplikasi data dan mencapai sinkronisasi file. Ini adalah alat unik yang melakukan banyak tugas pemeliharaan penyembuhan diri seperti pemulihan otomatis data setelah periode waktu henti yang lama dalam sebuah node, komunikasi yang aman dan efisien antara node dengan bantuan HTTPS dan manajemen konflik otomatis berdasarkan aturan yang ditetapkan. , etc. The essential feature of replicating any database to any other database makes SymmetricDS ready to be deployed for a number of use cases including migration, version and patch upgrade, distribution, filtering and transformation of data across diverse platforms.

The demo was created by referring to the official quick-start tutorial of SymmetricDS which can be accessed from here. The user guide can be found here, which provides a detailed account of various concepts involved in a SymmetricDS replication setup.