Opsi pemulihan dari bencana untuk workload database Oracle
Panduan ini menjelaskan opsi pemulihan dari bencana yang tersedia bagi pengguna yang menjalankan beban kerja database Oracle yang penting untuk misi di lingkungan Solusi Bare Metal.
Panduan ini mengasumsikan bahwa Anda menjalankan Oracle Enterprise Edition. Beberapa fitur yang dijelaskan dalam panduan ini dilisensikan secara terpisah di luar lisensi Edisi Enterprise. Beberapa fitur ini mencakup, tetapi tidak terbatas pada:
- Oracle Real Application Clusters
- Oracle Active Data Guard
- Oracle Advanced Compression
- Oracle GoldenGate
Lihat perjanjian lisensi Oracle Anda untuk menentukan fitur yang berhak Anda gunakan saat merencanakan pemulihan dari bencana dan ketersediaan tinggi.
RTO dan RPO Aplikasi
Pemulihan dari bencana untuk teknologi database Oracle harus ditentukan berdasarkan batas waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) aplikasi. Secara umum, RTO menjelaskan jumlah waktu non-operasional yang dapat diterima untuk suatu sistem, dan RPO menjelaskan jumlah kehilangan data yang dapat diterima. Biaya dan kompleksitas sistem meningkat seiring dengan penurunan setiap nilai ini. Untuk mengetahui informasi selengkapnya tentang RTO dan RPO, lihat Dasar-dasar perencanaan DR.
Arsitektur yang diberi label "RPO = 0" atau "tanpa kehilangan data" mengharuskan data ditulis di beberapa lokasi sebelum dianggap "di-commit" ke database. Latensi menjadi masalah saat RPO mendekati nol.
Jika tidak diperhitungkan dengan benar selama fase desain, penerapan arsitektur tanpa kehilangan data dapat berdampak buruk pada performa aplikasi secara keseluruhan.
Ketersediaan tinggi versus pemulihan dari bencana (disaster recovery)
Ketersediaan tinggi dan pemulihan dari bencana (disaster recovery) adalah konsep yang saling melengkapi saat merancang arsitektur database yang andal. Dalam konteks panduan ini, ketersediaan tinggi mengacu pada kemampuan sistem untuk otomatis pulih dari kegagalan individu atau kegagalan berjenjang pada sistem. Di sisi lain, pemulihan bencana adalah bagian dari rencana kelangsungan bisnis secara keseluruhan dan berlaku untuk kegagalan yang lebih besar yang dapat membuat seluruh grup sistem tidak tersedia. Pemulihan dari bencana (disaster recovery) mencakup cakupan yang lebih luas karena jumlah komponen terintegrasi yang harus dipulihkan jika terjadi bencana.
Ketersediaan tinggi harus dianggap sebagai "lini pertahanan pertama" saat mendesain sistem yang andal. Arsitektur database dengan ketersediaan tinggi harus dapat mempertahankan kegagalan individual dan terus berjalan tanpa menyebabkan periode nonaktif untuk aplikasi. Komponen ketersediaan tinggi suatu sistem harus mencakup, tetapi tidak terbatas pada hal berikut:
- Daya redundan ke hardware server, jaringan, atau penyimpanan
- Beberapa antarmuka jaringan, switch, dan kabel
- Kain penyimpanan, pengontrol, dan perangkat disk yang redundan
- Partner Interconnect yang toleran terhadap fault antara Google Cloud dan ekstensi region Solusi Bare Metal
- Oracle RAC untuk mencegah kegagalan server menonaktifkan database
Desain pemulihan bencana harus mencakup proses untuk memulihkan dari beberapa kegagalan beruntun yang membuat komponen tidak tersedia. Perencanaan pemulihan dari bencana harus mempertimbangkan hal-hal berikut:
- Pemadaman layanan regional
- Bencana alam
- Insiden yang mengakibatkan gangguan total pada satu atau beberapa komponen aplikasi
Alat pemulihan dari bencana dan ketersediaan tinggi Oracle
Berikut adalah beberapa alat pemulihan dari bencana (disaster recovery) dan ketersediaan tinggi Oracle:
- Oracle Real Application Clusters
- Oracle Recovery Manager
- Oracle Data Guard
- Database Flashback
- Oracle GoldenGate
Oracle Real Application Clusters
Oracle Real Application Clusters (RAC) digunakan untuk menskalakan beban kerja database secara horizontal agar dapat dilayani oleh beberapa server database. Database yang menggunakan RAC memungkinkan konfigurasi aktif/aktif antara server dalam ekstensi region.
RAC biasanya digunakan untuk memberikan ketersediaan tinggi bagi sistem yang perlu dilindungi dari kegagalan server tunggal. Karena pendekatan "semua bersama" (penyimpanan bersama dan jaringan bersama) untuk pengelompokan, cluster RAC yang berjalan di lingkungan Solusi Bare Metal harus ada dalam satu pod Solusi Bare Metal. Hal ini menjadikan RAC sebagai solusi untuk masalah ketersediaan tinggi, tetapi tidak menyelesaikan persyaratan pemulihan dari bencana.
Oracle Recovery Manager
Oracle Recovery Manager (RMAN) adalah alat utama untuk pencadangan dan pemulihan database Oracle karena kemampuannya untuk membaca format file data eksklusif Oracle. Alat ini dapat digunakan untuk melakukan clone database, pemulihan point-in-time, atau bahkan pemulihan satu tabel dalam database Oracle.
RMAN adalah satu-satunya alat yang dapat digunakan untuk membuat cadangan saat database terbuka. Folder ini juga digunakan untuk mengelola katalog file cadangan yang tersedia untuk digunakan dalam pemulihan.
Oracle Data Guard
Oracle Data Guard melakukan replikasi database ke cluster RAC jarak jauh atau penginstalan database lainnya. Data Guard mendukung database standby dalam konfigurasi fisik atau logis.
Database standby fisik adalah salinan per blok yang memungkinkan satu salinan database dibuka untuk penulisan; semua salinan lainnya dipasang (tetapi tidak dibuka) untuk menerapkan perubahan atau dibuka hanya baca untuk mendukung aplikasi pelaporan.
Untuk mempelajari cara menyiapkan Data Guard di Solusi Bare Metal, lihat Men-deploy Oracle Data Guard di Solusi Bare Metal.
FLASHBACK DATABASE
Fitur FLASHBACK DATABASE Oracle Enterprise Edition memungkinkan administrator
memutar mundur database dengan cepat ke titik waktu tertentu tanpa perlu
melakukan pemulihan database yang memakan waktu.
Dalam konteks pemulihan dari bencana, FLASHBACK DATABASE biasanya digunakan bersama dengan Data Guard selama operasi failover untuk pengaktifan kembali database yang lebih cepat. Database yang gagal di-flash kembali ke titik waktu tertentu yang konsisten dengan log di primer baru, dan pengulangan dikirim sehingga dapat disinkronkan ulang sepenuhnya.
Oracle GoldenGate
Oracle GoldenGate adalah alat replikasi logis yang umumnya digunakan untuk mengaktifkan deployment multi-situs aktif/aktif atau memindahkan data di seluruh platform hardware. Saat menggunakan GoldenGate, proses extract pada database sumber
mencatat perubahan dalam log redo online dan menulis perubahan ini ke file
jejak, yang ditransfer ke database target. Proses replicat pada database target mengonversi transaksi dari file tail ke SQL, dan menjalankan SQL di database target.
Arsitektur ini menjadikan GoldenGate sebagai alat yang efektif untuk memindahkan data di seluruh platform database atau mentransformasi data saat direplikasi. Tidak seperti Data Guard, GoldenGate memerlukan software terpisah untuk diinstal dan dikelola di sistem sumber dan target. GoldenGate tidak dapat digunakan untuk replikasi sinkron karena transaksi diterjemahkan dan diterapkan sebagai SQL di database target. Meskipun GoldenGate dapat memberikan latensi minimal untuk replikasi, GoldenGate saja tidak dapat menjamin RPO nol.
Model deployment pemulihan dari bencana (Khusus database)
Oracle telah membuat framework Arsitektur Ketersediaan Maksimum (MAA) untuk memberi Anda model pemulihan dari bencana (disaster recovery) yang direkomendasikan untuk men-deploy aplikasi dan database Anda.
Setiap model berikut memberikan target RTO dan RPO tertentu:
Model dipetakan ke pola deployment tertentu yang memenuhi RPO dan RTO dalam peristiwa pemadaman terencana dan tidak terencana. Setiap workload database harus dievaluasi persyaratan ketersediaannya dan didesain dengan model yang sesuai. Database pengembangan biasanya menggunakan model dengan tingkat perlindungan yang lebih rendah daripada database produksi dan QA.
Model Bronze ditujukan untuk database yang tidak memerlukan RTO yang diukur dalam menit. Model Silver dan tingkat yang lebih tinggi mencakup database standby yang berjalan di situs terpencil. Setiap model menggabungkan fungsi model tingkat yang lebih rendah. Misalnya, model Bronze menggunakan konsep pencadangan dan pemulihan yang harus tetap diikuti meskipun database standby di-deploy.
Model Copper
Model Copper menyediakan deployment minimal untuk mencadangkan database ke media penyimpanan lokal dan menyalin ke penyimpanan yang berada di luar ekstensi region. Deployment ini memerlukan pendekatan dua tahap, tetapi dapat dibuat skrip untuk menggunakan Google Cloud SDK guna mengotomatiskan transmisi cadangan.
Penggunaan deployment ini juga meningkatkan RTO karena pemulihan dua tahap yang diperlukan. RMAN tidak dapat mengakses cadangan secara langsung, sehingga cadangan harus dipindahkan ke lokasi yang tersedia untuk RMAN sebelum pemulihan dapat dimulai.
| Penonaktifan, layanan nonaktif | Jenis pemadaman | RPO | RTO |
|---|---|---|---|
| Tidak direncanakan | Kegagalan node atau instance yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance |
| Bencana: kerusakan | Pencadangan inkremental, penuh, atau archivelog terakhir yang ditransfer keluar dari RE | Jam, bergantung pada ukuran database dan bandwidth yang ditetapkan ke Partner Interconnect | |
| Bencana: kegagalan ekstensi wilayah | Pencadangan inkremental, penuh, atau archivelog terakhir yang ditransfer keluar dari RE | Hari / minggu, bergantung pada waktu yang diperlukan untuk mengaktifkan kembali ekstensi wilayah | |
| Direncanakan | Patch database, update OS / FW | 0 | Waktu yang diperlukan untuk mengupdate dan memulai ulang instance |
| Upgrade database utama | 0 | 1-2 jam |
Model perunggu
Model Bronze menawarkan dua opsi deployment. Keduanya menggunakan Google Cloud-native storage untuk menyimpan cadangan database.
Deployment Bronze 1: Pencadangan di penyimpanan regional
Dalam deployment ini, cadangan ditulis langsung ke media di luar lokasi. Dalam sebagian besar kasus, tujuan pencadangan yang disarankan adalah Cloud Storage dengan Cloud Storage FUSE, yang menampilkan bucket Cloud Storage sebagai sistem file.
Rekomendasi untuk menggunakan Cloud Storage FUSE dapat ditemukan di Oracle Backups with NFS and Cloud Storage. Google Cloud Filestore, yang menampilkan berbagi NFS ke instance Bare Metal Solution, juga dapat digunakan.
Diagram berikut menunjukkan contoh deployment.
| Penonaktifan, layanan nonaktif | Jenis pemadaman | RPO | RTO |
|---|---|---|---|
| Tidak direncanakan | Kegagalan node atau instance yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance |
| Bencana: kerusakan | Pencadangan inkremental, penuh, atau archivelog terakhir | Jam, bergantung pada ukuran database dan bandwidth yang ditetapkan ke Partner Interconnect | |
| Bencana: kegagalan ekstensi wilayah | Pencadangan inkremental, penuh, atau archivelog terakhir | Hari / minggu, bergantung pada waktu yang diperlukan untuk mengaktifkan kembali ekstensi wilayah | |
| Direncanakan | Patch database, update OS/FW | 0 | Waktu yang diperlukan untuk mengupdate dan memulai ulang instance |
| Upgrade database utama | 0 | 1-2 jam |
Deployment Bronze 2: Pencadangan menggunakan Backup and DR
Dalam deployment ini, Layanan Pencadangan dan DR digunakan untuk menyimpan cadangan di Google Cloud. Backup dan DR menawarkan pendekatan pencadangan inkremental selamanya, yang disimpan di media berperforma tinggi yang didukung oleh Cloud Storage untuk retensi jangka panjang.
Backup and DR juga menawarkan RTO yang lebih cepat daripada menyimpan cadangan di Filestore atau Cloud Storage, karena dapat langsung menyediakan image file database untuk instance Oracle. Fitur pasang dan migrasikan membuat database online dengan cepat saat menyalin kembali ke media penyimpanan produksi, sehingga mengurangi RTO secara drastis.
Diagram berikut menunjukkan contoh deployment.
| Penonaktifan, layanan nonaktif | Jenis pemadaman | RPO | RTO |
|---|---|---|---|
| Tidak direncanakan | Kegagalan node atau instance yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance
Detik jika menggunakan RAC |
| Bencana: kerusakan | Pencadangan inkremental, penuh, atau archivelog terakhir | Beberapa menit hingga beberapa jam, bergantung pada persyaratan performa, ukuran database, dan bandwidth yang ditetapkan ke Partner Interconnect | |
| Bencana: kegagalan ekstensi wilayah | Pencadangan inkremental, penuh, atau archivelog terakhir | Hari / minggu, bergantung pada waktu yang diperlukan untuk mengaktifkan kembali ekstensi wilayah atau kemampuan pelanggan untuk berpindah ke ekstensi wilayah lain. | |
| Direncanakan | Patch database, update OS / FW | 0 | Waktu yang diperlukan untuk mengupdate dan memulai ulang instance |
| Upgrade database utama | 0 | 1-2 jam |
Silver
Model Silver memperkenalkan replikasi database menggunakan Oracle Data Guard. Data Guard menyediakan replikasi database real-time dengan satu atau beberapa database yang bertindak sebagai database standby. Karena Data Guard mengandalkan pengiriman dan penerapan perubahan database saat terjadi, RPO dapat mendekati nol. Model Silver mengandalkan replikasi asinkron; menggunakan replikasi sinkron memastikan tidak ada kehilangan data, tetapi waktu yang diperlukan untuk mengirim data antar-region biasanya mendorong waktu respons aplikasi melampaui batas yang dapat diterima.
Fitur failover mulai cepat Data Guard memiliki kemampuan untuk melakukan operasi failover otomatis jika database utama tidak tersedia selama jangka waktu yang ditentukan pengguna. Konfigurasi dipantau oleh proses pengamat Data Guard, yang dapat berjalan.
Model Silver memiliki manfaat untuk memastikan bahwa database tersedia jika terjadi kegagalan regional total, tetapi operasi failover dan pengalihan mungkin memengaruhi performa aplikasi karena latensi jaringan antara server aplikasi dan database meningkat. Menjalankan aplikasi dan database pendukung di region yang berbeda jarang direkomendasikan. Meskipun RTO untuk database mungkin kurang dari 1 menit, kasus failover aplikasi mungkin memerlukan waktu beberapa menit hingga beberapa jam sebelum layanan berfungsi sepenuhnya. Dalam sebagian besar kasus, menjalankan rencana failover pemulihan bencana lintas region biasanya melibatkan proses manual karena jumlah komponen yang dipindahkan.
Pada model Silver, Anda mungkin masih mengalami periode nonaktif atau masa pemeliharaan selama aktivitas patch triwulanan. Memperkenalkan Oracle RAC dapat mengurangi waktu henti untuk penerapan patch atau kegagalan server.
Diagram berikut menunjukkan contoh konfigurasi.
Contoh konfigurasi dalam diagram menunjukkan database RAC yang berjalan di region
us-west2 dan us-east4. Replikasi dikonfigurasi menggunakan Data Guard asinkron. Semua traffic antara Solusi Bare Metal dan Google Cloud
melewati Partner Interconnect dan traffic lintas region berjalan
melalui backbone jaringan Google. Server aplikasi dikonfigurasi di setiap
region, tetapi biasanya dimatikan di region pemulihan dari bencana hingga
peristiwa failover dinyatakan terjadi.
| Penonaktifan, layanan nonaktif | Jenis pemadaman | RPO | RTO |
|---|---|---|---|
| Tidak direncanakan | Kegagalan node atau instance yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance
Detik jika menggunakan RAC |
| Bencana: korupsi | < 60 dtk | Beberapa menit hingga beberapa jam, bergantung pada failover aplikasi. | |
| Bencana: kegagalan ekstensi wilayah | < 60 dtk | Beberapa menit hingga beberapa jam, bergantung pada failover aplikasi. | |
| Direncanakan | Patch database, update OS / FW | 0 | Waktu yang diperlukan untuk mengupdate dan memulai ulang instance.
Detik jika menggunakan RAC |
| Upgrade database utama | 0 | 1-2 jam
Menit jika menggunakan |
Model Gold
Jika Anda khawatir tentang kehilangan data dalam model Silver, Anda dapat memilih model Gold yang menggunakan instance sinkronisasi jauh untuk menyediakan replikasi sinkron ke instance yang berjalan di Compute Engine Google Cloud.
Instance sinkronisasi jauh mencakup file kontrol database dan serangkaian log redo standby yang berjalan secara geografis di dekat database utama. Instance ini dikonfigurasi untuk menerima redo secara sinkron dengan latensi rendah sehingga semua perubahan dapat dicatat di luar ekstensi region database utama. Instance sinkronisasi jauh kemudian meneruskan redo ke database standby di region jarak jauh untuk diterapkan secara asinkron.
Instance sinkronisasi jauh bukanlah salinan lengkap database, sehingga tidak dapat melayani traffic aplikasi. Instance sinkronisasi jauh digunakan untuk menyediakan lokasi yang toleran terhadap kesalahan agar perubahan database dapat ditulis secara sinkron, sehingga memungkinkan solusi tanpa kehilangan data. Saat melakukan replikasi sinkron ke instance sinkronisasi jauh, transaksi tidak di-commit di database utama hingga perubahan diterima dan di-commit di instance sinkronisasi jauh.
Instance Compute Engine biasanya dipilih sebagai kandidat untuk menghosting instance sinkronisasi jauh. Menempatkan instance sinkronisasi jauh di zona Compute Engine yang berdekatan dengan database utama akan menambah latensi minimal (biasanya di bawah 1,5 md) dan melindungi dari kegagalan dalam ekstensi region.
Diagram berikut menunjukkan contoh deployment.
Contoh konfigurasi dalam diagram menunjukkan database RAC utama yang berjalan di
us-west2 dengan aplikasi yang berjalan di Compute Engine. Instance Compute Engine dalam us-west2 menjalankan instance sinkronisasi jauh, menerima pengulangan sinkron. Instance sinkronisasi jauh dikonfigurasi untuk mengirim ulang secara asinkron ke database RAC yang berjalan di region us-east4. Instance aplikasi dikonfigurasi
di region us-east4 di Compute Engine untuk menangani traffic aplikasi jika terjadi bencana.
| Penonaktifan, layanan nonaktif | Jenis pemadaman | RPO | RTO |
|---|---|---|---|
| Tidak direncanakan | Kegagalan node atau instance yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance
Detik jika menggunakan RAC |
| Bencana: kerusakan | 0 | Beberapa menit hingga beberapa jam, bergantung pada failover regional aplikasi. | |
| Bencana: kegagalan ekstensi wilayah | 0 | Beberapa menit hingga beberapa jam, bergantung pada failover regional aplikasi. | |
| Direncanakan | Patch database, update OS / FW | 0 | Waktu yang diperlukan untuk mengupdate dan memulai ulang instance.
Detik jika menggunakan RAC |
| Upgrade database utama | 0 | 1-2 jam
Menit jika menggunakan |
Model Platinum
Model Platinum menawarkan dua opsi deployment. Setiap opsi deployment memberikan perlindungan menggunakan teknologi yang berbeda, dan memiliki karakteristik RTO dan RPO yang berbeda.
Deployment Platinum 1: Data Guard dengan failover mulai cepat
Deployment Platinum 1 dibangun di atas deployment model Gold dengan menambahkan database standby Data Guard kedua di region lokal yang berjalan di instance Compute Engine. Konfigurasi ini menggunakan replikasi sinkron antara database utama dan standby yang berjalan di Compute Engine, sehingga memberikan jaminan tanpa kehilangan data dalam region utama.
Membuat database standby dalam region memungkinkan operasi failover dan pengalihan database terjadi tanpa memengaruhi aplikasi. Selama perubahan peran database, aplikasi yang dikonfigurasi sesuai dengan pertimbangan klien Oracle akan otomatis terhubung kembali ke database utama yang baru tanpa memerlukan intervensi manual. Aplikasi yang dikonfigurasi dengan benar akan mengalami periode nonaktif kurang dari 2 menit selama peristiwa failover.
Meskipun database standby di Compute Engine tidak menjalankan RAC, database tersebut harus disesuaikan ukurannya untuk mendukung traffic aplikasi normal saat berjalan sebagai database utama. Instance ini dapat berjalan dengan bentuk yang lebih kecil saat beroperasi sebagai standby dan di-scale up selama peristiwa failover, atau berjalan dengan kapasitas penuh setiap saat. Mengubah ukuran instance selama peristiwa failover akan berdampak negatif pada RTO, karena instance harus dimulai ulang selama operasi pengubahan ukuran.
Pengalihan saat terjadi kegagalan mulai cepat dikonfigurasi pada instance Compute Engine yang menjalankan broker Data Guard dengan pengamat. Observer menjalankan klien Oracle dasar dengan koneksi ke semua database primer dan standby. Jika pengamat mendeteksi kegagalan di database utama, pengamat akan memulai failover ke salah satu database standby. Database standby yang berjalan di Compute Engine harus dikonfigurasi sebagai target failover pilihan saat menggunakan deployment tingkat Gold.
Oracle merekomendasikan agar pengamat ditempatkan di region yang terpisah dari database utama dan standby. Tindakan ini memberikan perlindungan terbaik terhadap kegagalan regional dan peristiwa partisi jaringan. Jika region ketiga tidak memungkinkan, pengamat harus diinstal di region utama, berjalan di zona yang berbeda dari standby dekat situs.
Diagram berikut menunjukkan contoh deployment.
Contoh deployment yang ditampilkan dalam diagram terdiri dari hal berikut:
- Database utama yang menjalankan RAC di server Solusi Bare Metal di
us-west2region. - Database standby di dekat lokasi yang berjalan di instance Compute Engine di region
us-west2. - Database standby jarak jauh yang berjalan di server Solusi Bare Metal di
us-east4region. - Pengamat Data Guard yang berjalan di instance Compute Engine di region
us-central1.
Replikasi sinkron dikonfigurasi untuk database standby dalam region yang berjalan
di instance Compute Engine, dan replikasi asinkron dikonfigurasi ke
region jarak jauh. Dalam setiap kasus, redo dikirim dari database utama ke database standby; redo tidak diteruskan dari satu database standby ke database standby lainnya. Pengamat
dikonfigurasi di region ketiga dan mempertahankan konektivitas ke semua
database dalam konfigurasi. Instance aplikasi dikonfigurasi di region utama dan terhubung ke database utama di server Solusi Bare Metal (atau database di instance Compute Engine selama operasi failover dan pengalihan). Instance aplikasi dikonfigurasi di region us-east4 di Compute Engine untuk menangani traffic aplikasi jika terjadi bencana.
| Penonaktifan, layanan nonaktif | Jenis pemadaman | RPO | RTO |
|---|---|---|---|
| Tidak direncanakan | Kegagalan node atau instance yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance
Detik jika menggunakan RAC |
| Bencana: kerusakan | 0 | < 60 dtk | |
| Bencana: kegagalan ekstensi wilayah | 0 | < 60 dtk | |
| Direncanakan | Patch database, update OS / FW | 0 | Waktu yang diperlukan untuk mengupdate dan memulai ulang instance.
Detik jika menggunakan RAC |
| Upgrade database utama | 0 | 1-2 jam
Menit jika menggunakan |
Deployment Platinum 2: GoldenGate untuk replikasi
Deployment Platinum 2 mengandalkan penggunaan Oracle GoldenGate untuk replikasi. Karena GoldenGate tidak mereplikasi pada tingkat blok. Hal ini memungkinkan setiap database untuk melayani sesi aplikasi baca dan tulis secara independen. Hal ini mereplikasi perubahan secara dua arah, sehingga memungkinkan konfigurasi database aktif/aktif.
Aplikasi harus divalidasi secara menyeluruh sebelum melakukan penerapan aktif/aktif, dan Anda harus memperhitungkan deteksi dan penyelesaian konflik.
Tidak seperti Data Guard, GoldenGate memerlukan penginstalan dan pemeliharaan software tambahan di server database Oracle. Deployment aktif/aktif biasanya memerlukan desain skema dan aplikasi yang canggih untuk memanfaatkan deployment database multi-situs. Banyak aplikasi yang sudah dikemas sebelumnya tidak mendukung jenis arsitektur ini.
Deployment yang bergantung pada GoldenGate untuk semua replikasi tidak dapat mendukung RPO tanpa kehilangan data karena sifat replikasi logis yang asinkron. Database standby lokal yang berjalan di Compute Engine menggunakan Data Guard dapat di-deploy untuk memberikan RPO nol dengan replikasi sinkron.
Diagram berikut menunjukkan contoh deployment.
| Penonaktifan, layanan nonaktif | Jenis pemadaman | RPO | RTO |
|---|---|---|---|
| Tidak direncanakan | Kegagalan node atau instance yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance |
| Bencana: kerusakan | Detik ke Menit
0 jika menggunakan Data Guard di setiap lokasi |
0 | |
| Bencana: kegagalan ekstensi wilayah | Detik ke Menit
0 jika menggunakan Data Guard di setiap lokasi |
0 | |
| Direncanakan | Patch database, update OS / FW | 0 | Waktu yang diperlukan untuk mengupdate dan memulai ulang instance.
Detik jika menggunakan RAC |
| Upgrade database utama | 0 | 0 |