Replikasi silang antara PostgreSQL dan MySQL

Saya akan menggariskan replikasi silang antara PostgreSQL dan MySQL, serta kaedah untuk menyediakan replikasi silang antara dua pelayan pangkalan data. Lazimnya, pangkalan data replika silang dipanggil homogen, dan ia merupakan kaedah mudah untuk berpindah dari satu pelayan RDBMS ke pelayan yang lain.

Pangkalan data PostgreSQL dan MySQL biasanya dianggap sebagai hubungan, tetapi dengan sambungan tambahan ia menawarkan keupayaan NoSQL. Di sini kita akan membincangkan replikasi antara PostgreSQL dan MySQL dari perspektif DBMS hubungan.

Kami tidak akan menerangkan keseluruhan kerja dalaman, hanya prinsip asas supaya anda mendapat idea untuk mengkonfigurasi replikasi antara pelayan pangkalan data, kelebihan, had dan kes penggunaan.

Biasanya, replikasi antara dua pelayan pangkalan data yang sama dilakukan sama ada dalam mod binari atau menggunakan pertanyaan antara induk (a.k.a. penerbit, induk atau aktif) dan hamba (pelanggan, tunggu sedia atau pasif). Tujuan replikasi adalah untuk menyediakan salinan masa nyata pangkalan data induk di sebelah hamba. Dalam kes ini, data dipindahkan dari tuan ke hamba, iaitu, dari aktif ke pasif, kerana replikasi dilakukan hanya dalam satu arah. Tetapi anda boleh menyediakan replikasi antara dua pangkalan data dalam kedua-dua arah, supaya data dipindahkan daripada hamba kepada induk dalam konfigurasi aktif-aktif. Semua ini, termasuk replikasi berlatarkan, adalah mungkin antara dua atau lebih pelayan pangkalan data yang sama. Konfigurasi aktif-aktif atau aktif-pasif bergantung pada keperluan, ketersediaan keupayaan sedemikian dalam konfigurasi awal atau penggunaan penyelesaian konfigurasi luaran dan pertukaran sedia ada .

Konfigurasi yang diterangkan adalah mungkin antara pelayan pangkalan data yang berbeza. Pelayan boleh dikonfigurasikan untuk menerima data replika daripada pelayan pangkalan data lain dan masih mengekalkan syot kilat masa nyata data yang direplikasi. MySQL dan PostgreSQL menawarkan kebanyakan konfigurasi ini secara dalaman atau melalui sambungan pihak ketiga, termasuk kaedah log binari, penguncian cakera dan kaedah berasaskan pernyataan dan baris.

Replikasi silang antara MySQL dan PostgreSQL diperlukan untuk pemindahan satu kali dari satu pelayan pangkalan data ke pelayan pangkalan data yang lain. Pangkalan data ini menggunakan protokol yang berbeza, jadi tidak mungkin untuk memautkannya secara langsung. Untuk mewujudkan pertukaran data, anda boleh menggunakan alat sumber terbuka luaran, contohnya pg_chameleon.

Apakah pg_chameleon

pg_chameleon ialah sistem replikasi daripada MySQL kepada PostgreSQL dalam Python 3. Ia menggunakan perpustakaan replikasi mysql sumber terbuka, juga dalam Python. Imej baris diekstrak daripada jadual MySQL dan disimpan sebagai objek JSONB dalam pangkalan data PostgreSQL, dan kemudian dinyahsulit oleh fungsi pl/pgsql dan diterbitkan semula dalam pangkalan data PostgreSQL.

Ciri pg_chameleon

Skema MySQL berbilang daripada kluster yang sama boleh direplikasi kepada pangkalan data PostgreSQL sasaran tunggal dalam konfigurasi satu-ke-banyak
Nama skema sumber dan sasaran tidak boleh sama.
Data replikasi boleh diambil daripada replika MySQL bertingkat.
Jadual yang tidak boleh meniru atau menghasilkan ralat dikecualikan.
Setiap fungsi replikasi dikawal oleh daemon.
Kawalan melalui parameter berasaskan YAML dan fail konfigurasi.

Contoh

Tuan rumah
vm1
vm2

versi OS
CentOS Linux 7.6 x86_64
CentOS Linux 7.5 x86_64

Versi pelayan DB
MySQL 5.7.26
PostgreSQL 10.5

port DB
3306
5433

Alamat IP
192.168.56.102
192.168.56.106

Untuk bermula, sediakan semua komponen yang diperlukan untuk memasang pg_chameleon. Contoh ini memasang Python 3.6.8, yang mencipta dan mengaktifkan persekitaran maya.

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

Selepas berjaya memasang Python3.6, anda perlu melengkapkan keperluan yang selebihnya, seperti mencipta dan mengaktifkan persekitaran maya. Selain itu, modul pip dikemas kini kepada versi terkini dan digunakan untuk memasang pg_chameleon. Arahan di bawah sengaja memasang pg_chameleon 2.0.9, walaupun versi terkini ialah 2.0.10. Ini adalah perlu untuk mengelakkan pepijat baharu dalam versi yang dikemas kini.

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

Kami kemudian memanggil pg_chameleon (bunglon ialah arahan) dengan argumen set_configuration_files untuk mendayakan pg_chameleon dan mencipta direktori lalai dan fail konfigurasi.

(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 kita mencipta salinan config-example.yml sebagai default.yml supaya ia menjadi fail konfigurasi lalai. Contoh fail konfigurasi untuk contoh ini disediakan di bawah.

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

Fail konfigurasi dalam contoh ini ialah contoh fail pg_chameleon dengan pengubahsuaian kecil untuk disesuaikan dengan sumber dan persekitaran sasaran, dan di bawah ialah gambaran keseluruhan bahagian berlainan fail konfigurasi.

Dalam fail konfigurasi default.yml terdapat bahagian tetapan global, di mana anda boleh mengurus tetapan seperti lokasi fail kunci, lokasi log, tempoh penyimpanan untuk log, dsb. Seterusnya datang bahagian override jenis, di mana satu set peraturan untuk mengatasi jenis semasa replikasi. Contoh lalai kepada peraturan mengatasi jenis yang menukarkan tinyint(1) kepada nilai boolean. Dalam bahagian seterusnya, kami menentukan butiran sambungan ke pangkalan data sasaran. Dalam kes kami, ini ialah pangkalan data PostgreSQL, yang ditetapkan pg_conn. Di bahagian terakhir, kami menunjukkan data sumber, iaitu, parameter sambungan pangkalan data sumber, skema pemetaan antara pangkalan data sumber dan sasaran, jadual yang perlu dilangkau, masa menunggu, memori, saiz pakej. Ambil perhatian bahawa "sumber" adalah jamak, bermakna kita boleh menambah pangkalan data berbilang sumber pada pangkalan data sasaran tunggal untuk menyediakan konfigurasi banyak-ke-satu.

Pangkalan data contoh world_x mengandungi 4 jadual dengan baris yang ditawarkan oleh komuniti MySQL sebagai contoh. Ia boleh dimuat turun di sini. Pangkalan data sampel datang sebagai tar dan arkib termampat dengan arahan untuk mencipta dan mengimport baris.

Dalam pangkalan data MySQL dan PostgreSQL, pengguna khas dicipta dengan nama yang sama usr_replica. Dalam MySQL, ia diberikan hak baca tambahan kepada semua jadual 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;

Di sebelah PostgreSQL, pangkalan data db_replica dicipta yang akan menerima perubahan daripada pangkalan data MySQL. Pengguna usr_replica dalam PostgreSQL dikonfigurasikan secara automatik sebagai pemilik dua skema, pgworld_x dan sch_chameleon, yang masing-masing mengandungi jadual replika sebenar dan jadual direktori replikasi. Argumen create_replica_schema bertanggungjawab untuk konfigurasi automatik, seperti yang anda akan lihat di bawah.

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

Pangkalan data MySQL dikonfigurasikan dengan beberapa perubahan parameter untuk menyediakannya untuk replikasi seperti yang ditunjukkan di bawah. Anda perlu memulakan semula pelayan pangkalan data untuk perubahan berkuat kuasa.

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

Sekarang adalah penting untuk menyemak sambungan ke kedua-dua pelayan pangkalan data supaya tiada masalah semasa menjalankan perintah pg_chameleon.

Pada nod PostgreSQL:

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

Pada nod MySQL:

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

Tiga perintah pg_chameleon (bunglon) seterusnya menyediakan persekitaran, tambah sumber dan mulakan replika. Argumen create_replica_schema kepada pg_chameleon mencipta skema lalai (sch_chameleon) dan skema replikasi (pgworld_x) dalam pangkalan data PostgreSQL, seperti yang telah kita bincangkan. Argumen add_source menambah pangkalan data sumber pada konfigurasi dengan membaca fail konfigurasi (default.yml), dan dalam kes kami ia adalah mysql, dan init_replica memulakan konfigurasi berdasarkan parameter dalam fail konfigurasi.

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

Output ketiga-tiga arahan ini jelas menunjukkan bahawa ia telah dilaksanakan dengan jayanya. Sebarang ranap sistem atau ralat sintaks dilaporkan dalam mesej ringkas dan jelas dengan petunjuk tentang cara menyelesaikan masalah.

Akhir sekali, kami memulakan replikasi menggunakan start_replica dan menerima mesej kejayaan.

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

Status replikasi boleh disoal menggunakan argumen show_status dan ralat boleh dilihat menggunakan argumen show_errors.

Keputusan.

Seperti yang telah kami katakan, setiap fungsi replikasi dikawal oleh daemon. Untuk melihatnya, kami menanyakan jadual proses dengan arahan ps Linux, seperti yang ditunjukkan di bawah.

Keputusan.

Replikasi tidak dianggap dikonfigurasikan sehingga kami mengujinya dalam masa nyata, seperti yang ditunjukkan di bawah. Kami mencipta jadual, memasukkan beberapa rekod ke dalam pangkalan data MySQL dan memanggil argumen sync_tables dalam pg_chameleon untuk mengemas kini daemon dan mereplikasi jadual dengan rekod ke pangkalan data 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.

Untuk mengesahkan keputusan ujian, kami menanyakan jadual daripada pangkalan data PostgreSQL dan mengeluarkan baris.

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

Jika kita melakukan migrasi, perintah pg_chameleon berikut akan menjadi penghujungnya. Arahan perlu dilaksanakan selepas kami pasti bahawa baris semua jadual sasaran telah direplikasi, dan hasilnya akan menjadi pangkalan data PostgreSQL yang dipindahkan dengan kemas tanpa rujukan kepada pangkalan data sumber atau skema replikasi (sch_chameleon).

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

Jika mahu, anda boleh menggunakan arahan berikut untuk memadam konfigurasi asal dan skema replikasi.

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

Kelebihan pg_chameleon

Persediaan dan konfigurasi yang mudah.
Selesaikan masalah dan kenal pasti anomali dengan mudah dengan mesej ralat yang jelas.
Jadual khas tambahan boleh ditambah pada replikasi selepas pemulaan tanpa mengubah konfigurasi yang lain.
Adalah mungkin untuk mengkonfigurasi berbilang pangkalan data sumber untuk pangkalan data sasaran tunggal, dan ini sangat berguna jika anda menggabungkan data daripada satu atau lebih pangkalan data MySQL ke dalam pangkalan data PostgreSQL tunggal.
Anda tidak perlu meniru jadual yang dipilih.

Kelemahan pg_chameleon

Hanya disokong dengan MySQL 5.5 dan ke atas sebagai sumber dan PostgreSQL 9.5 dan ke atas sebagai pangkalan data sasaran.
Setiap jadual mesti mempunyai kunci utama atau unik, jika tidak, jadual dimulakan semasa proses init_replica tetapi tidak direplikasi.
Replikasi sehala - hanya dari MySQL ke PostgreSQL. Oleh itu, ia hanya sesuai untuk litar "aktif-pasif".
Sumber hanya boleh menjadi pangkalan data MySQL, dan sokongan untuk pangkalan data PostgreSQL sebagai sumber hanyalah percubaan dan dengan pengehadan (ketahui lebih lanjut di sini)

Keputusan untuk pg_chameleon

Kaedah replikasi dalam pg_chameleon sangat bagus untuk memindahkan pangkalan data daripada MySQL ke PostgreSQL. Kelemahan yang ketara ialah replikasi hanya sehala, jadi profesional pangkalan data tidak mungkin mahu menggunakannya untuk apa-apa selain penghijrahan. Tetapi masalah replikasi sehala boleh diselesaikan dengan alat sumber terbuka yang lain - SymmetricDS.

Baca lebih lanjut dalam dokumentasi rasmi di sini. Bantuan baris arahan boleh didapati di sini.

Gambaran keseluruhan SymmetricDS

SymmetricDS ialah alat sumber terbuka yang mereplikasi mana-mana pangkalan data kepada mana-mana pangkalan data biasa yang lain: Oracle, MongoDB, PostgreSQL, MySQL, SQL Server, MariaDB, DB2, Sybase, Greenplum, Informix, H2, Firebird dan contoh pangkalan data awan lain, cth. Redshift, dan Azure, dsb. Ciri yang tersedia: pangkalan data dan penyegerakan fail, replikasi pangkalan data berbilang induk, penyegerakan ditapis, transformasi dan lain-lain. Ini ialah alat Java dan memerlukan keluaran standard JRE atau JDK (versi 8.0 atau lebih tinggi). Di sini, perubahan data kepada pencetus dalam pangkalan data sumber boleh direkodkan dan dihantar ke pangkalan data sasaran yang sesuai dalam bentuk kelompok.

Ciri SymmetricDS

Alat ini bebas platform, bermakna dua atau lebih pangkalan data yang berbeza boleh bertukar-tukar data.
Pangkalan data perhubungan disegerakkan menggunakan rekod perubahan data, manakala pangkalan data berasaskan sistem fail menggunakan penyegerakan fail.
Replikasi dua hala menggunakan kaedah Tolak dan Tarik berdasarkan set peraturan.
Pemindahan data boleh dilakukan melalui rangkaian selamat dan jalur lebar rendah.
Pemulihan automatik apabila nod menyambung semula operasi selepas kegagalan dan penyelesaian konflik automatik.
API sambungan yang serasi dengan awan dan berkuasa.

Contoh

SymmetricDS boleh dikonfigurasikan dalam salah satu daripada dua pilihan:
Nod induk (induk) yang menyelaras replikasi data secara berpusat antara dua nod hamba (anak), dan komunikasi antara nod anak berlaku hanya melalui induk.
Nod aktif (Nod 1) boleh berkomunikasi untuk replikasi dengan nod aktif lain (Nod 2) tanpa perantara.

Dalam kedua-dua pilihan, pertukaran data berlaku menggunakan Tekan dan Tarik. Dalam contoh ini kita akan mempertimbangkan konfigurasi aktif-aktif. Ia akan mengambil masa terlalu lama untuk menerangkan keseluruhan seni bina, jadi lakukan penyelidikan anda. panduanuntuk mengetahui lebih lanjut tentang peranti SymmetricDS.

Memasang SymmetricDS adalah sangat mudah: muat turun versi sumber terbuka fail zip oleh itu dan bawa keluar ke mana sahaja anda mahu. Jadual di bawah menyediakan maklumat tentang lokasi pemasangan dan versi SymmetricDS dalam contoh ini, serta versi pangkalan data, versi Linux, alamat IP dan port untuk kedua-dua nod.

Tuan rumah
vm1
vm2

versi OS
CentOS Linux 7.6 x86_64
CentOS Linux 7.6 x86_64

Versi pelayan DB
MySQL 5.7.26
PostgreSQL 10.5

port DB
3306
5832

Alamat IP
192.168.1.107
192.168.1.112

Versi SymmetricDS
SymmetricDS 3.9
SymmetricDS 3.9

Laluan pemasangan SymmetricDS
/usr/local/symmetric-server-3.9.20
/usr/local/symmetric-server-3.9.20

Nama nod SymmetricDS
kor-000
kedai-001

Di sini kami memasang SymmetricDS dalam /usr/local/symmetric-server-3.9.20, dan pelbagai subdirektori dan fail akan disimpan di sana. Kami berminat dengan sampel dan subdirektori enjin. Direktori sampel mengandungi contoh fail konfigurasi dengan sifat nod, serta contoh skrip SQL untuk membolehkan anda bermula dengan cepat.

Dalam direktori sampel kita melihat tiga fail konfigurasi dengan sifat nod - nama menunjukkan sifat nod dalam skema tertentu.

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

SymmetricDS mempunyai semua fail konfigurasi yang diperlukan untuk reka bentuk asas 3-nod (pilihan 1), dan fail yang sama boleh digunakan untuk reka bentuk 2-nod (pilihan 2). Salin fail konfigurasi yang diperlukan daripada direktori sampel ke enjin pada hos vm1. Ternyata begini:

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

Nod dalam konfigurasi SymmetricDS ini dipanggil corp-000, dan sambungan pangkalan data dikendalikan oleh pemacu jdbc mysql, yang menggunakan rentetan sambungan di atas dan bukti kelayakan log masuk. Kami menyambung ke pangkalan data replica_db dan jadual akan dibuat semasa penciptaan skema. sync.url menunjukkan lokasi sambungan ke nod untuk penyegerakan.

Nod 2 pada hos vm2 dikonfigurasikan sebagai store-001 dan selebihnya ditentukan dalam fail node.properties di bawah. Node store-001 menjalankan pangkalan data PostgreSQL dan pgdb_replica ialah pangkalan data replikasi. registration.url membenarkan hos vm2 menghubungi hos vm1 dan menerima butiran konfigurasi daripadanya.

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

Contoh SymmetricDS yang lengkap mengandungi parameter untuk menyediakan replikasi dua hala antara dua pelayan pangkalan data (dua nod). Langkah-langkah di bawah dilakukan pada hos vm1 (corp-000), yang akan mencipta contoh skema dengan 4 jadual. Kemudian menjalankan create-sym-tables dengan arahan symadmin mencipta jadual direktori di mana peraturan dan arah replikasi antara nod akan disimpan. Akhir sekali, data sampel dimuatkan ke dalam jadual.

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

Dalam contoh, jadual item dan item_selling_price dikonfigurasikan secara automatik untuk mereplikasi daripada corp-000 ke store-001, dan jadual jualan (sale_transaction and sale_return_line_item) dikonfigurasikan secara automatik untuk mereplikasi daripada store-001 ke corp-000. Kini kami mencipta skema dalam pangkalan data PostgreSQL pada hos vm2 (store-001) untuk menyediakannya untuk menerima data daripada corp-000.

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

Pastikan anda menyemak bahawa pangkalan data MySQL pada vm1 mempunyai jadual contoh dan jadual katalog SymmetricDS. Ambil perhatian bahawa jadual sistem SymmetricDS (diawali dengan sym_) pada masa ini hanya tersedia pada nod corp-000 kerana di situlah kami menjalankan perintah create-sym-tables dan akan menguruskan replikasi. Dan dalam pangkalan data di nod store-001 hanya akan ada 4 contoh jadual tanpa data.

Semua. Persekitaran sedia untuk menjalankan proses pelayan sym pada kedua-dua nod seperti yang ditunjukkan di bawah.

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

Entri log dihantar ke fail log latar belakang (symmetric.log) dalam folder log dalam direktori tempat SymmetricDS dipasang, serta ke output standard. Pelayan sym kini boleh dimulakan pada kedai nod-001.

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

Jika anda menjalankan proses pelayan sym pada hos vm2, ia juga akan mencipta jadual katalog SymmetricDS dalam pangkalan data PostgreSQL. Jika anda menjalankan proses pelayan sym pada kedua-dua nod, mereka menyelaras antara satu sama lain untuk mereplikasi data daripada corp-000 kepada store-001. Jika selepas beberapa saat kami menanyakan semua 4 jadual di kedua-dua belah pihak, kami akan melihat bahawa replikasi berjaya. Atau anda boleh menghantar bootstrap ke kedai nod-001 dari corp-000 dengan arahan berikut.

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

Pada ketika ini, rekod baharu dimasukkan ke dalam jadual item dalam pangkalan data MySQL pada nod corp-000 (hos: vm1), dan anda boleh menyemak replikasinya ke pangkalan data PostgreSQL pada stor nod-001 (hos: vm2). Kami melihat operasi Tarik untuk memindahkan data daripada 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)

Untuk melaksanakan operasi Tekan untuk mengalihkan data daripada store-001 ke corp-000, kami memasukkan rekod ke dalam jadual sale_transaction dan mengesahkan bahawa replikasi berjaya.

Keputusan.

Kami melihat persediaan yang berjaya bagi replikasi dua hala bagi jadual contoh antara pangkalan data MySQL dan PostgreSQL. Untuk menyediakan replikasi bagi jadual pengguna baharu, ikut langkah berikut: Kami mencipta jadual t1 sebagai contoh dan mengkonfigurasi peraturan replikasinya seperti berikut. Dengan cara ini kami mengkonfigurasi hanya replikasi daripada 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)

Konfigurasi kemudiannya dimaklumkan tentang perubahan skema, iaitu penambahan jadual baharu, menggunakan perintah symadmin dengan hujah pencetus penyegerakan, yang mencipta semula pencetus untuk memetakan takrif jadual. send-schema dilaksanakan untuk menghantar perubahan skema ke nod store-001, dan replikasi jadual t1 dikonfigurasikan.

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

Faedah SymmetricDS

Pemasangan dan konfigurasi yang mudah, termasuk set fail siap sedia dengan parameter untuk mencipta litar tiga nod atau dua nod.
Pangkalan data merentas platform dan kebebasan platform, termasuk pelayan, komputer riba dan peranti mudah alih.
Replika mana-mana pangkalan data kepada mana-mana pangkalan data lain secara tempatan, pada WAN atau dalam awan.
Kemungkinan kerja optimum dengan beberapa pangkalan data atau beberapa ribu untuk replikasi yang mudah.
Versi berbayar dengan GUI dan sokongan yang sangat baik.

Kelemahan SymmetricDS

Anda perlu menentukan secara manual peraturan dan arah replikasi pada baris arahan melalui pernyataan SQL untuk memuatkan jadual katalog, yang boleh menyusahkan.
Menyediakan banyak jadual untuk replikasi boleh menjadi membosankan melainkan anda menggunakan skrip untuk mencipta pernyataan SQL yang mentakrifkan peraturan dan arah replikasi.
Terdapat terlalu banyak maklumat yang direkodkan dalam log, dan kadangkala anda perlu mengemas fail log supaya ia tidak mengambil terlalu banyak ruang.

Keputusan untuk SymmetricDS

SymmetricDS membolehkan anda menyediakan replikasi dua hala antara dua, tiga, atau bahkan beberapa ribu nod untuk mereplikasi dan menyegerakkan fail. Ini ialah alat unik yang melaksanakan banyak tugas secara bebas, seperti pemulihan data automatik selepas tempoh masa henti yang lama pada nod, pertukaran data yang selamat dan cekap antara nod melalui HTTPS, pengurusan konflik automatik berdasarkan set peraturan, dsb. SymmetricDS melakukan replikasi antara mana-mana pangkalan data, oleh itu, ia boleh digunakan untuk pelbagai jenis senario, termasuk migrasi, migrasi, pengedaran, penapisan dan transformasi data merentas platform.

Contohnya adalah berdasarkan rasmi panduan pantas oleh SymmetricDS. DALAM manual pengguna Menghuraikan secara terperinci pelbagai konsep yang terlibat dalam menyediakan replikasi dengan SymmetricDS.

Sumber: www.habr.com