Basis data dapat gagal tanpa peringatan - baik karena kerusakan yang disebabkan oleh bug perangkat lunak, atau komponen perangkat keras yang mendasarinya. Cloud membawa dimensi lain pada masalah ini, karena sifat komputasi dan sumber daya penyimpanan yang bersifat sementara. Untuk melindungi infrastruktur database kami dari kegagalan ini, kami membangun redundansi ke dalam sistem kami. Jika sebuah instans menjadi tidak tersedia, sistem siaga harus dapat mengambil beban kerja dan melanjutkan dari sana. Replikasi adalah metode yang terkenal dan diadopsi secara luas untuk membuat salinan database master yang berlebihan.
Dalam posting ini, kita akan membandingkan fungsi replikasi di dua sistem database paling populer di planet ini (menurut db-engines) - Oracle dan MySQL. Kami secara khusus akan melihat replikasi logis Oracle 12c, dan MySQL 5.7. Kedua teknologi tersebut menawarkan sistem siaga yang andal untuk menurunkan beban kerja produksi dan membantu jika terjadi bencana. Kami akan melihat arsitektur yang berbeda, menganalisis pro dan kontra dan melalui langkah-langkah tentang cara mengatur replikasi dengan Oracle dan MySQL.
Arsitektur Penjaga Data Oracle – Cara Kerjanya
Oracle Data Guard menjamin ketersediaan tinggi, perlindungan data, dan pemulihan data dari bencana. Ini mungkin merupakan pilihan pertama Oracle DBA untuk mereplikasi data. Teknologi ini diperkenalkan pada tahun 1990 (versi 7.0) dengan penerapan penting dari arsip log pada database standby. Data Guard berkembang selama bertahun-tahun dan sekarang menyediakan serangkaian layanan komprehensif yang membuat, memelihara, mengelola, dan memantau database siaga.
Data Guard memelihara database siaga sebagai salinan dari database produksi. Jika database utama berhenti merespons, Data Guard dapat mengalihkan siaga apa pun ke peran produksi, sehingga waktu henti. Data Guard dapat digunakan untuk pencadangan, pemulihan, dan teknik cluster untuk memberikan perlindungan data dan ketersediaan data tingkat tinggi.
Data Guard adalah teknologi Ship Redo / Apply Redo, "redo" adalah informasi yang dibutuhkan untuk memulihkan transaksi. Basis data produksi yang disebut sebagai basis data primer, melakukan siaran ulang ke satu atau lebih replika yang disebut sebagai basis data siaga. Saat penyisipan atau pembaruan dibuat ke tabel, perubahan ini ditangkap oleh penulis log ke dalam log arsip, dan direplikasi ke sistem siaga. Basis data siaga berada dalam fase pemulihan berkelanjutan, memverifikasi, dan menerapkan redo untuk menjaga sinkronisasi dengan basis data utama. Basis data siaga juga akan secara otomatis melakukan sinkronisasi ulang jika terputus sementara ke basis data primer karena pemadaman listrik, masalah jaringan, dll.
Oracle Data Guard Net Services Data Guard Redo Transport Services mengatur transmisi redo dari database utama ke database standby. Proses LGWR (penulis log) mengirimkan data redo ke satu atau lebih proses server jaringan (LNS1, LSN2, LSN3, ...LSNn). LNS membaca dari redo buffer di SGA (Shared Global Area) dan meneruskan redo ke Oracle Net Services untuk mengirimkan ke database standby. Anda dapat memilih atribut LGWR:sinkron (LogXptMode ='SYNC') atau mode asinkron (LogXptMode ='ASYNC'). Dengan arsitektur seperti itu dimungkinkan untuk mengirimkan data redo ke beberapa database siaga atau menggunakannya dengan Oracle RAC (Real Application Cluster). Proses Remote File Server (RFS) menerima redo dari LNS dan menulisnya ke file biasa yang disebut file standby redo log (SRL).
Ada dua jenis utama dari Oracle Data Guard. Fisik dengan penerapan ulang dan basis data siaga logis dengan penerapan SQL.
Arsitektur Replikasi Logis Oracle Dataguard Penerapan SQL memerlukan lebih banyak pemrosesan daripada penerapan ulang, proses pertama membaca SRL dan "menambang" pengulangan dengan mengubahnya menjadi catatan perubahan logis, dan kemudian membangun transaksi SQL sebelum menerapkan SQL ke database siaga. Ada lebih banyak bagian yang bergerak sehingga membutuhkan lebih banyak CPU, memori, dan I/O, lalu ulangi penerapan.
Manfaat utama dari "SQL apply" adalah database terbuka untuk read-write, sedangkan proses apply aktif.
Anda bahkan dapat membuat tampilan dan indeks lokal. Ini membuatnya ideal untuk alat pelaporan. Basis data siaga tidak harus berupa salinan satu-ke-satu dari basis data utama Anda, dan oleh karena itu mungkin bukan kandidat terbaik untuk tujuan DR.
Fitur utama dari solusi ini adalah:
- Database standby yang dibuka untuk read-write saat SQL berlaku aktif
- Kemungkinan kunci modifikasi data yang dikelola oleh SQL berlaku
- Mampu menjalankan pemutakhiran basis data bergulir
Ada kekurangan. Oracle menggunakan kunci utama atau batasan unik/indeks tambahan logging untuk secara logis mengenali baris yang dimodifikasi dalam database siaga logis. Ketika logging tambahan kunci utama dan batasan unik/indeks di seluruh basis data diaktifkan, setiap pernyataan UPDATE juga menulis nilai kolom yang diperlukan dalam redo log untuk secara unik mengidentifikasi baris yang dimodifikasi dalam database siaga logis. Oracle Data Guard mendukung replikasi berantai, yang di sini disebut "cascade" namun tidak biasa karena kerumitan penyiapan.
Oracle menyarankan agar Anda menambahkan kunci utama atau indeks unik non-null ke tabel di database utama, bila memungkinkan, untuk memastikan bahwa SQL Apply dapat secara efisien menerapkan pembaruan data ulang ke database siaga logis. Artinya, ini tidak berfungsi pada penyiapan apa pun, Anda mungkin perlu memodifikasi aplikasi Anda.
Arsitektur Oracle Golden Gate – Cara Kerjanya
Dengan Data Guard, saat blok diubah dalam database, catatan ditambahkan ke redo log. Kemudian berdasarkan mode replikasi yang Anda jalankan, catatan log ini akan segera disalin ke standby atau ditambang untuk perintah SQL dan diterapkan. Golden Gate bekerja dengan cara yang berbeda.
Golden Gate hanya mereplikasi perubahan setelah transaksi dilakukan, jadi jika Anda memiliki transaksi yang berjalan lama, perlu beberapa saat untuk mereplikasi. “Proses ekstrak” Golden Gate menyimpan perubahan transaksional dalam memori.
Perbedaan besar lainnya adalah Oracle Golden Gate memungkinkan pertukaran dan manipulasi data pada tingkat transaksi di antara banyak platform yang heterogen. Anda tidak hanya terbatas pada database Oracle. Ini memberi Anda fleksibilitas untuk mengekstrak dan mereplikasi catatan data yang dipilih, perubahan transaksional, dan perubahan pada DDL (bahasa definisi data) di berbagai topologi.
Arsitektur Gerbang Emas Oracle Aliran Golden Gate yang khas menunjukkan data database baru dan yang diubah yang diambil dari database sumber. Data yang diambil ditulis ke file yang disebut jejak sumber. Jejak kemudian dibaca oleh pompa data, dikirim melalui jaringan, dan ditulis ke file jejak jarak jauh oleh proses Kolektor. Fungsi pengiriman membaca jejak jarak jauh dan memperbarui database target. Setiap komponen dikelola oleh proses Manajer.
Replikasi logika MySQL – Cara Kerjanya
Replikasi di MySQL telah ada sejak lama dan telah berkembang selama bertahun-tahun. Ada berbagai cara untuk mengaktifkan replikasi MySQL, termasuk Group Replication, Galera Clusters, "Master to Slave" asinkron. Untuk membandingkan arsitektur Oracle vs. MySQL, kami akan fokus pada format replikasi karena ini adalah dasar untuk semua jenis replikasi yang berbeda.
Pertama-tama, format replikasi yang berbeda sesuai dengan format logging biner yang ditentukan dalam file konfigurasi my.cnf. Terlepas dari formatnya, log selalu disimpan dengan cara biner, tidak dapat dilihat dengan editor biasa. Ada tiga jenis format:berbasis baris, berbasis pernyataan, dan campuran. Campuran adalah kombinasi dari dua yang pertama. Kami akan melihat pernyataan dan berdasarkan baris.
Berbasis pernyataan – dalam hal ini adalah pertanyaan tertulis. Tidak semua pernyataan yang mengubah data (seperti pernyataan INSERT DELETE, UPDATE, dan REPLACE) dapat direplikasi menggunakan replikasi berbasis pernyataan. LOAD_FILE(), UUID(), UUID_SHORT(), USER(), FOUND_ROWS() dll tidak akan direplikasi.
Berbasis baris – dalam hal ini, ini adalah perubahan pada catatan. Semua perubahan dapat direplikasi. Ini adalah bentuk replikasi yang paling aman. Sejak 5.7.7, ini adalah opsi default.
Sekarang mari kita lihat apa yang terjadi di balik layar saat replikasi diaktifkan.
Arsitektur replikasi MySQL Pertama-tama, database master menulis perubahan ke file yang disebut log biner atau binlog. Menulis ke log biner biasanya merupakan aktivitas yang ringan karena penulisan disangga dan berurutan. File log biner menyimpan data yang nantinya akan diproses oleh slave replikasi, aktivitas master tidak bergantung padanya. Saat replikasi dimulai, mysql akan memicu tiga utas. Satu di master, dua di budak. Master memiliki utas, yang disebut utas dump, yang membaca log biner master dan mengirimkannya ke budak.
Pada slave, sebuah proses yang disebut IO thread terhubung ke master, membaca peristiwa log biner dari master saat mereka masuk dan menyalinnya ke file log lokal yang disebut log relai. Proses slave kedua – SQL thread – membaca kejadian dari log relai yang disimpan secara lokal pada slave replikasi dan kemudian menggunakannya.
MySQL mendukung replikasi berantai, yang sangat mudah diatur. Slave yang juga master harus dijalankan dengan parameter --log-bin dan --log-slave-update.
Untuk memeriksa status replikasi dan mendapatkan informasi tentang utas, Anda menjalankan slave:
MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000005
Read_Master_Log_Pos: 339
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 635
Relay_Master_Log_File: binlog.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 339
Relay_Log_Space: 938
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Current_Pos
Gtid_IO_Pos: 0-1-8
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
1 row in set (0.00 sec)Mengatur Replikasi Logis Data Guard di Oracle
-
Membuat Basis Data Siaga Fisik
Untuk membuat database siaga logis, Anda terlebih dahulu membuat database siaga fisik, lalu mentransisikannya ke database siaga logis.
-
Stop Redo Apply pada Physical Standby Database
Menghentikan Ulangi Terapkan diperlukan untuk menghindari penerapan perubahan.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -
Siapkan Basis Data Utama untuk Mendukung Basis Data Siaga Logis
Ubah atribut VALID_FOR di LOG_ARCHIVE_DEST_1 asli dan tambahkan LOG_ARCHIVE_DEST_3 untuk basis data logis.
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_STATE_3=ENABLEMembangun Kamus di Redo Data
SQL> EXECUTE DBMS_LOGSTDBY.BUILD; -
Konversikan ke Basis Data Siaga Logis
Untuk melanjutkan penerapan redo data ke physical standby database hingga siap untuk dikonversi ke logical standby database, keluarkan pernyataan SQL berikut:
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name; -
Menyesuaikan Parameter Inisialisasi untuk Logical Standby Database
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines_remote/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_2= 'SERVICE=severalnines ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines_remote/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE -
Buka Database Logis Siaga
SQL> ALTER DATABASE OPEN RESETLOGS;Memverifikasi Logical Standby Database Berkinerja Benar
tampilan v$data_guard_stats
SQL> COL NAME FORMAT A20 SQL> COL VALUE FORMAT A12 SQL> COL UNIT FORMAT A30 SQL> SELECT NAME, VALUE, UNIT FROM V$Data_Guard_STATS; NAME VALUE UNIT -------------------- ------------ ------------------------------ apply finish time +00 00:00:00 day(2) to second(1) interval apply lag +00 00:00:00 day(2) to second(0) interval transport lag +00 00:00:00 day(2) to second(0) intervaltampilan v$logstdby_process
SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE HIGH_SCN ----- ------- ----------- ---------------- ---------- 48 6 11074 COORDINATOR 7178242899 56 56 10858 READER 7178243497 46 1 10860 BUILDER 7178242901 45 1 10862 PREPARER 7178243295 37 1 10864 ANALYZER 7178242900 36 1 10866 APPLIER 7178239467 35 3 10868 APPLIER 7178239463 34 7 10870 APPLIER 7178239461 33 1 10872 APPLIER 7178239472 9 rows selected.
Ini adalah langkah-langkah yang diperlukan untuk membuat replikasi logis Oracle Data Guard. Tindakan akan sedikit berbeda jika Anda melakukan operasi ini dengan set kompatibilitas non-default atau database yang berjalan di lingkungan Oracle RAC.
Menyiapkan replikasi MySQL
-
Konfigurasikan basis data induk. Setel server_id unik, tentukan log replikasi yang berbeda –log-basename (MariaDB), aktifkan log biner. Ubah file my.cnf dengan informasi di bawah ini.
log-bin server_id=1 log-basename=master1Masuk ke database master dan berikan pengguna replikasi untuk mengakses data master.
GRANT REPLICATION SLAVE ON *.* TO replication_user -
Mulai kedua server dengan GTID diaktifkan.
gtid_mode=ON enforce-gtid-consistency=true -
Konfigurasikan slave untuk menggunakan penentuan posisi otomatis berbasis GTID.
mysql> CHANGE MASTER TO > MASTER_HOST = host, > MASTER_PORT = port, > MASTER_USER = replication_user, > MASTER_PASSWORD = password, > MASTER_AUTO_POSITION = 1; -
Jika Anda ingin menambahkan slave ke master dengan data, maka Anda perlu mengambil cadangan dan memulihkannya di server slave.
mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --user=root --password=rootpassword > dump_replication.sqlMasuk ke database budak dan jalankan:
slave> tee dump_replication_insert.log slave> source dump_replication.sql slave> CHANGE MASTER TO MASTER_HOST="host", MASTER_USER=" replication_user ", MASTER_PASSWORD="password ", MASTER_PORT=port, MASTER_AUTO_POSITION = 1;
