Dalam “State of the Open-Source DBMS Market, 2018”, Gartner memprediksi bahwa pada tahun 2022, 70 persen aplikasi internal baru akan dikembangkan pada database open-source. Dan 50% dari database komersial yang ada akan dikonversi. Jadi, Oracle DBA, bersiaplah untuk mulai menerapkan dan mengelola database open source baru - bersama dengan instance Oracle lama Anda. Kecuali Anda sudah melakukannya.
Jadi bagaimana replikasi MySQL atau MariaDB menumpuk terhadap Oracle Data Guard? Di blog ini, kami akan membandingkan keduanya dari sudut pandang solusi database ketersediaan tinggi.
Yang Harus Dicari
Arsitektur replikasi data modern dibangun di atas desain fleksibel yang memungkinkan replikasi data satu arah dan dua arah, serta failover otomatis yang cepat ke database sekunder jika terjadi pemutusan layanan yang tidak direncanakan. Failover juga harus mudah dijalankan dan dapat diandalkan sehingga tidak ada transaksi yang dilakukan yang hilang. Selain itu, peralihan atau pengalihan idealnya harus transparan untuk aplikasi.
Solusi replikasi data harus mampu menyalin data dengan latensi sangat rendah untuk menghindari kemacetan pemrosesan dan menjamin akses waktu nyata ke data. Salinan waktu nyata dapat digunakan pada database berbeda yang berjalan pada perangkat keras berbiaya rendah.
Saat digunakan untuk pemulihan bencana, sistem harus divalidasi untuk memastikan akses aplikasi ke sistem sekunder dengan gangguan layanan minimal. Solusi ideal harus memungkinkan pengujian reguler proses pemulihan bencana.
Topik Utama Perbandingan
- Ketersediaan dan konsistensi data
- Gtid, scm
- Sebutkan Replikasi ke beberapa model siaga, asinkron + sinkronisasi
- Isolasi standby dari kesalahan produksi (mis. replikasi tertunda untuk mysql)
- Hindari kehilangan data (replikasi sinkronisasi)
- Pemanfaatan sistem siaga
- Penggunaan standby
- Kegagalan, Peralihan, dan pemulihan otomatis
- Kegagalan basis data
- Kegagalan aplikasi transparan (TAF vs ProxySQL, MaxScale)
- Keamanan
- Kemudahan penggunaan dan pengelolaan (pengelolaan terpadu komponen pra-integrasi)
Ketersediaan dan Konsistensi Data
MySQL GTID
Replikasi MySQL 5.5 didasarkan pada peristiwa log biner, di mana semua budak tahu adalah peristiwa yang tepat dan posisi yang tepat yang baru saja dibaca dari master. Setiap transaksi tunggal dari master mungkin telah berakhir di berbagai log biner dari budak yang berbeda, dan transaksi biasanya memiliki posisi yang berbeda dalam log ini. Itu adalah solusi sederhana yang datang dengan keterbatasan, perubahan topologi dapat mengharuskan admin untuk menghentikan replikasi pada instance yang terlibat. Perubahan ini dapat menyebabkan beberapa masalah lain, misalnya, slave tidak dapat dipindahkan ke rantai replikasi tanpa pembangunan kembali yang memakan waktu. Memperbaiki tautan replikasi yang rusak akan membutuhkan penentuan secara manual file log biner baru dan posisi transaksi terakhir yang dijalankan pada slave dan melanjutkan dari sana, atau pembangunan kembali total. Kita semua harus mengatasi keterbatasan ini sambil bermimpi tentang pengenal transaksi global.
MySQL versi 5.6 (dan MariaDB versi 10.0.2) memperkenalkan mekanisme untuk memecahkan masalah ini. GTID (Global Transaction Identifier) menyediakan pemetaan transaksi yang lebih baik di seluruh node.
Dengan GTID, slave dapat melihat transaksi unik yang masuk dari beberapa master dan ini dapat dengan mudah dipetakan ke dalam daftar eksekusi slave jika perlu memulai ulang atau melanjutkan replikasi. Jadi, sarannya adalah untuk selalu menggunakan GTID. Perhatikan bahwa MySQL dan MariaDB memiliki implementasi GTID yang berbeda.
Oracle SCN
Pada tahun 1992 dengan rilis 7.3 Oracle memperkenalkan solusi untuk menyimpan salinan database yang disinkronkan sebagai siaga, yang dikenal sebagai Data Guard dari rilis versi 9i 2. Konfigurasi Data Guard terdiri dari dua komponen utama, satu database utama, dan database siaga (sampai 30). Perubahan pada database utama diteruskan melalui database siaga, dan perubahan ini diterapkan ke database siaga agar tetap sinkron.
Oracle Data Guard awalnya dibuat dari cadangan database utama. Data Guard secara otomatis menyinkronkan database utama dan semua database siaga dengan mengirimkan redo database utama - informasi yang digunakan oleh setiap Oracle Database untuk melindungi transaksi - dan menerapkannya ke database siaga. Oracle menggunakan mekanisme internal yang disebut SCN (System Change Number). Nomor perubahan sistem (SCN) adalah jam Oracle, setiap kali kami melakukan, jam bertambah. SCN menandai titik waktu yang konsisten dalam database yang merupakan pos pemeriksaan yang merupakan tindakan menulis blok kotor (blok yang dimodifikasi dari cache buffer ke disk). Kita bisa membandingkannya dengan GTID di MySQL.
Layanan transportasi Data Guard menangani semua aspek pengiriman ulang dari database utama ke database siaga. Saat pengguna melakukan transaksi pada primer, catatan ulang dibuat dan ditulis ke file log online lokal. Layanan transport Data Guard secara bersamaan mengirimkan redo yang sama langsung dari buffer log basis data utama (memori yang dialokasikan dalam area global sistem) ke basis data siaga di mana ia ditulis ke file log redo siaga.
Ada beberapa perbedaan utama antara replikasi MySQL dan Data Guard. Transmisi langsung Data Guard dari memori menghindari overhead I/O disk pada database utama. Ini berbeda dengan cara kerja MySQL - membaca data dari memori menurunkan I/O pada database utama.
Data Guard hanya mengirimkan redo database. Ini sangat kontras dengan penyimpanan cermin jarak jauh yang harus mengirimkan setiap blok yang diubah di setiap file untuk mempertahankan sinkronisasi waktu nyata.
Model Asinkron + Sinkronisasi
Oracle Data Guard menawarkan tiga model berbeda untuk redo apply. Model adaptif bergantung pada perangkat keras yang tersedia, proses, dan pada akhirnya kebutuhan bisnis.
- Kinerja Maksimum - mode operasi default, memungkinkan transaksi untuk dilakukan segera setelah data redo yang diperlukan untuk memulihkan transaksi tersebut ditulis ke log redo lokal pada master.
- Perlindungan Maksimum - tidak ada kehilangan data dan tingkat perlindungan maksimum. Data redo yang diperlukan untuk meningkatkan setiap operasi harus ditulis ke redo log online lokal pada master dan standby redo log pada setidaknya satu database standby sebelum transaksi dilakukan (Oracle merekomendasikan setidaknya dua standby). Basis data utama akan dimatikan jika kesalahan menghalanginya untuk menulis aliran ulang ke setidaknya satu basis data siaga yang disinkronkan.
- Ketersediaan Maksimum - mirip dengan Perlindungan Maksimum tetapi database utama tidak akan dimatikan jika ada kesalahan yang mencegahnya menulis aliran ulang.
Saat memilih penyiapan replikasi MySQL, Anda memiliki pilihan antara replikasi Asinkron atau replikasi Semi-Sinkron.
- Terapkan binlog asinkron adalah metode default untuk replikasi MySQL. Master menulis event ke log binernya dan slave memintanya saat sudah siap. Tidak ada jaminan bahwa peristiwa apa pun akan mencapai budak mana pun.
- Komit semi-sinkron pada primer ditunda sampai master menerima pengakuan dari budak semi-sinkron bahwa data diterima dan ditulis oleh budak. Harap perhatikan bahwa replikasi semi-sinkron memerlukan plugin tambahan untuk diinstal.
Penggunaan Sistem Siaga
MySQL terkenal dengan kesederhanaan dan fleksibilitas replikasinya. Secara default, Anda dapat membaca atau bahkan menulis ke server standby/slave Anda. Untungnya, MySQL 5.6 dan 5.7 membawa banyak peningkatan signifikan pada Replication, termasuk Global Transaction ID, event checksum, multi-threaded slaves dan crash-safe slaves/masters untuk menjadikannya lebih baik. DBA yang terbiasa dengan membaca dan menulis replikasi MySQL akan mengharapkan solusi serupa atau bahkan lebih sederhana dari kakaknya, Oracle. Sayangnya tidak secara default.
Implementasi siaga fisik standar untuk Oracle ditutup untuk operasi baca-tulis apa pun. Faktanya, Oracle menawarkan variasi logis tetapi memiliki banyak keterbatasan, dan tidak dirancang untuk HA. Solusi untuk masalah ini adalah fitur berbayar tambahan yang disebut Active Data Guard, yang dapat Anda gunakan untuk membaca data dari standby saat Anda menerapkan redo log.
Active Data Guard adalah solusi tambahan berbayar untuk perangkat lunak pemulihan bencana Data Guard gratis dari Oracle yang hanya tersedia untuk Oracle Database Enterprise Edition (lisensi dengan biaya tertinggi). Ini memberikan akses hanya baca, sambil terus menerapkan perubahan yang dikirim dari database utama. Sebagai database siaga aktif, ini membantu menurunkan permintaan baca, pelaporan, dan pencadangan tambahan dari database utama. Arsitektur produk dirancang untuk memungkinkan database siaga diisolasi dari kegagalan yang mungkin terjadi pada database utama.
Fitur menarik dari database Oracle 12c dan sesuatu yang akan dilewatkan oleh Oracle DBA adalah validasi korupsi data. Pemeriksaan korupsi Oracle Data Guard dilakukan untuk memastikan bahwa data berada dalam keselarasan yang tepat sebelum data disalin ke database standby. Mekanisme ini juga dapat digunakan untuk memulihkan blok data pada primer langsung dari database siaga.
Failover, Switchover, dan Pemulihan Otomatis
Untuk menjaga agar pengaturan replikasi Anda tetap stabil dan berjalan, sangat penting bagi sistem untuk tahan terhadap kegagalan. Kegagalan disebabkan oleh bug perangkat lunak, masalah konfigurasi, atau masalah perangkat keras, dan dapat terjadi kapan saja. Jika server mati, Anda memerlukan pemberitahuan alarm tentang pengaturan yang terdegradasi. Failover (promosi dari budak ke master) dapat dilakukan oleh admin, yang perlu memutuskan budak mana yang akan dipromosikan.
Admin membutuhkan informasi tentang kegagalan, status sinkronisasi jika ada data yang hilang, dan terakhir, langkah-langkah untuk melakukan tindakan. Idealnya, semua harus otomatis dan terlihat dari satu konsol.
Ada dua pendekatan utama untuk failover MySQL, otomatis dan manual. Kedua opsi memiliki penggemarnya sendiri, kami menjelaskan konsepnya di artikel lain.
Dengan GTID, failover manual menjadi lebih mudah. Ini terdiri dari langkah-langkah seperti:
- Hentikan modul penerima (STOP SLAVE IO_THREAD)
- Ganti master (UBAH MASTER KE
) - Mulai modul penerima (MULAI SLAVE IO_THREAD)
Oracle Data Guard hadir dengan solusi failover/switchover khusus - Data Guard Broker. Pialang adalah kerangka kerja manajemen terdistribusi yang mengotomatisasi dan memusatkan pembuatan, pemeliharaan, dan pemantauan konfigurasi Oracle Data Guard. Dengan akses ke alat broker DG, Anda dapat melakukan perubahan konfigurasi, peralihan, failover, dan bahkan uji kering dari penyiapan ketersediaan tinggi Anda. Dua tindakan utama adalah:
- Perintah SWITCHOVER TO
digunakan untuk melakukan operasi peralihan. Setelah operasi peralihan berhasil, instans database berpindah tempat dan replikasi berlanjut. Tidak dapat beralih saat standby tidak merespons atau mati. - FAILOVER TO
digunakan untuk melakukan failover. Setelah operasi failover, server utama sebelumnya memerlukan rekreasi tetapi server utama baru dapat mengambil beban kerja database.
Berbicara tentang failover, kita perlu mempertimbangkan seberapa mulus failover aplikasi Anda. Jika terjadi pemadaman terencana/tidak terencana, seberapa efisien sesi pengguna dapat diarahkan ke situs sekunder, dengan gangguan bisnis yang minimal.
Pendekatan standar untuk MySQL adalah menggunakan salah satu Load Balancer yang tersedia. Mulai dari HAProxy yang banyak digunakan untuk failover HTTP atau TCP/IP hingga Maxscale atau ProxySQL yang sadar basis data.
Di Oracle, masalah ini diatasi oleh TAF (Transparent Application Failover). Setelah peralihan atau kegagalan terjadi, aplikasi secara otomatis diarahkan ke primer baru. TAF memungkinkan aplikasi untuk terhubung kembali secara otomatis dan transparan ke database baru, jika instance database yang membuat koneksi gagal.
Keamanan
Keamanan data adalah masalah panas bagi banyak organisasi saat ini. Bagi mereka yang perlu menerapkan standar seperti PCI DSS atau HIPAA, keamanan database adalah suatu keharusan. Lingkungan lintas WAN dapat menimbulkan kekhawatiran tentang privasi dan keamanan data terutama karena semakin banyak bisnis yang harus mematuhi peraturan nasional dan internasional. Log biner MySQL yang digunakan untuk replikasi mungkin berisi data sensitif yang mudah dibaca. Dengan konfigurasi standar, mencuri data adalah proses yang sangat mudah. MySQL mendukung SSL sebagai mekanisme untuk mengenkripsi lalu lintas baik antara server MySQL (replikasi) maupun antara server MySQL dan klien. Cara umum untuk menerapkan enkripsi SSL adalah dengan menggunakan sertifikat yang ditandatangani sendiri. Sebagian besar waktu, tidak diperlukan untuk mendapatkan sertifikat SSL yang dikeluarkan oleh Otoritas Sertifikat. Anda dapat menggunakan openssl untuk membuat sertifikat, contoh di bawah ini:
$ openssl genrsa 2048 > ca-key.pem
$ openssl req -new -x509 -nodes -days 3600 -key ca-key.pem > ca-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl rsa -in client-key.pem -out client-key.pem
$ openssl rsa -in server-key.pem -out server-key.pemKemudian ubah replikasi dengan parameter untuk SSL.
….MASTER_SSL=1, MASTER_SSL_CA = '/etc/security/ca.pem', MASTER_SSL_CERT = '/etc/security/client-cert.pem', MASTER_SSL_KEY = '/etc/security/client-key.pem';Untuk opsi yang lebih otomatis, Anda dapat menggunakan ClusterControl untuk mengaktifkan enkripsi dan mengelola kunci SSL.
Di Oracle 12c, redo transport Data Guard dapat diintegrasikan dengan serangkaian fitur keamanan khusus yang disebut Oracle Advanced Security (OAS). Keamanan Lanjutan dapat digunakan untuk mengaktifkan layanan enkripsi dan otentikasi antara sistem utama dan sistem siaga. Misalnya, mengaktifkan algoritma enkripsi Advanced Encryption Standard (AES) hanya membutuhkan beberapa perubahan parameter dalam file sqlnet.ora untuk membuat redo (mirip dengan MySQL binlog) terenkripsi. Tidak diperlukan penyiapan sertifikat eksternal dan hanya memerlukan restart database siaga. Modifikasi di sqlnet.ora dan wallet sederhana seperti:
Buat direktori dompet
mkdir /u01/app/walletEdit sqlnet.ora
ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=file)
(METHOD_DATA=
(DIRECTORY=/u01/app/wallet)))Buat penyimpanan kunci
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/wallet' identified by root ;Buka toko
ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;Buat kunci master
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;Siaga
salin file p12 dan .sso di direktori dompet dan untuk memperbarui file sqlnet.ora mirip dengan node utama.
Untuk informasi lebih lanjut, ikuti buku putih TDE Oracle, Anda dapat mempelajari dari buku putih cara mengenkripsi file data dan membuat dompet selalu terbuka.
Kemudahan Penggunaan dan Pengelolaan
Saat Anda mengelola atau menerapkan konfigurasi Oracle Data Guard, Anda mungkin menemukan bahwa ada banyak langkah dan parameter yang harus dicari. Untuk menjawabnya, Oracle membuat DG Broker.
Anda tentu dapat membuat konfigurasi Data Guard tanpa mengimplementasikan DG Broker tetapi dapat membuat hidup Anda jauh lebih nyaman. Ketika diimplementasikan, utilitas baris perintah Broker - DGMGRL mungkin merupakan pilihan utama untuk DBA. Bagi mereka yang lebih menyukai GUI, Cloud Control 13c memiliki opsi untuk mengakses DG Broker melalui antarmuka web.
Tugas yang dapat dibantu oleh Broker adalah memulai pemulihan terkelola secara otomatis, satu perintah untuk failover/switchover, pemantauan replikasi DG, verifikasi konfigurasi, dan banyak lainnya.
DGMGRL> show configuration
Configuration - orcl_s9s_config
Protection Mode: MaxPerformance
Members:
s9sp - Primary database
s9ss - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS (status updated 12 seconds agoMySQL tidak menawarkan solusi serupa dengan Oracle DG Broker. Namun Anda dapat memperluas fungsinya dengan menggunakan alat seperti Orchestrator, MHA, dan penyeimbang beban (ProxySQL, HAProxy, atau Maxscale). Solusi untuk mengelola database dan load balancer adalah ClusterControl. ClusterControl Enterprise Edition memberi Anda serangkaian fitur manajemen dan penskalaan lengkap selain fungsi penerapan dan pemantauan yang ditawarkan sebagai bagian dari Edisi Komunitas gratis.
