Opsi disaster recovery untuk workload database Oracle
Panduan ini menjelaskan opsi disaster recovery yang tersedia bagi pengguna yang menjalankan beban kerja database Oracle yang sangat penting 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 Enterprise Edition. Beberapa fitur ini mencakup, tetapi tidak terbatas pada:
- Cluster Oracle Real Application
- Oracle Active Data Guard
- Oracle Advanced Compression
- Oracle GoldenGate
Lihat perjanjian lisensi Oracle Anda untuk menentukan fitur yang berhak Anda gunakan saat merencanakan disaster recovery dan ketersediaan tinggi.
RTO dan RPO Aplikasi
Disaster recovery untuk teknologi database Oracle harus ditentukan berdasarkan batas waktu pemulihan (RTO) dan toleransi durasi kehilangan data (RPO) aplikasi. Secara umum, RTO menjelaskan jumlah downtime yang dapat diterima untuk suatu sistem, dan RPO menjelaskan jumlah kehilangan data yang dapat diterima. Biaya dan kompleksitas sistem meningkat seiring penurunan setiap nilai ini. Untuk mengetahui informasi selengkapnya tentang RTO dan RPO, lihat Dasar-dasar perencanaan DR.
Arsitektur yang diberi label "RPO = 0" atau "zero data loss" mengharuskan data ditulis di beberapa lokasi sebelum dianggap "di-commit" ke database. Latensi menjadi masalah saat RPO semakin mendekati nol.
Kecuali jika diperhitungkan dengan benar selama fase desain, menerapkan 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 pelengkap saat mendesain arsitektur database yang andal. Dalam konteks panduan ini, ketersediaan tinggi mengacu pada kemampuan sistem untuk otomatis pulih dari kegagalan individual atau beruntun pada sistem. Di sisi lain, disaster recovery adalah bagian dari keseluruhan rencana kelangsungan bisnis dan berlaku untuk kegagalan yang lebih besar yang dapat membuat seluruh grup sistem tidak tersedia. Disaster recovery mencakup cakupan yang lebih besar karena jumlah komponen terintegrasi yang harus dipulihkan jika terjadi bencana.
Ketersediaan tinggi harus dianggap sebagai "garis pertahanan pertama" saat mendesain sistem yang andal. Arsitektur database yang sangat tersedia harus dapat mengatasi kegagalan individual dan terus berjalan tanpa menyebabkan periode nonaktif untuk aplikasi. Komponen ketersediaan tinggi dari suatu sistem harus mencakup, tetapi tidak terbatas pada hal berikut:
- Daya redundan ke hardware server, jaringan, atau penyimpanan
- Beberapa antarmuka jaringan, switch, dan kabel
- Fabric penyimpanan, pengontrol, dan perangkat disk redundan
- Partner Interconnect yang toleran terhadap error antara Google Cloud dan ekstensi region Solusi Bare Metal
- Oracle RAC untuk mencegah kegagalan server menonaktifkan database
Desain disaster recovery harus menyertakan 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 menyebabkan pemadaman total 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:
- Cluster Oracle Real Application
- Oracle Recovery Manager
- Oracle Data Guard
- Database flashback
- Oracle GoldenGate
Cluster Oracle Real Application
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 satu server. Karena pendekatan "semuanya bersama" (penyimpanan bersama dan jaringan bersama) untuk clustering, 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 disaster recovery.
Untuk mempelajari cara menyiapkan RAC untuk Solusi Bare Metal, lihat Menginstal Oracle RAC di Solusi Bare Metal.
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. File 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 instalasi database lainnya. Data Guard mendukung database standby dalam konfigurasi fisik atau logis.
Database standby fisik adalah salinan blok demi blok yang memungkinkan satu salinan database terbuka untuk ditulis; semua salinan lainnya di-mount (tetapi tidak terbuka) untuk menerapkan perubahan atau terbuka 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 disaster recovery, 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 redo dikirim sehingga
dapat menyinkronkan ulang sepenuhnya.
Oracle GoldenGate
Oracle GoldenGate adalah alat replikasi logis yang biasa digunakan untuk
memungkinkan deployment multi-situs aktif/aktif atau memindahkan data di seluruh platform
hardware. Saat menggunakan GoldenGate, proses extract di database sumber
akan merekam perubahan dalam log redo online dan menulisnya ke perubahan pada file
rekaman aktivitas, yang ditranspor ke database target. Proses replicat di 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 mengubah 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 jeda minimal untuk replikasi, GoldenGate saja tidak dapat menjamin RPO nol.
Model deployment pemulihan dari bencana (Khusus Database)
Oracle telah membuat framework Maximum Availability Architecture (MAA) untuk memberikan model disaster recovery yang direkomendasikan bagi Anda untuk men-deploy aplikasi dan database.
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 beban kerja database harus dievaluasi untuk persyaratan ketersediaannya dan dirancang 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 level yang lebih tinggi mencakup database standby yang berjalan di situs jarak jauh. Setiap model menggabungkan fungsi model level bawah. Misalnya, model Bronze menggunakan konsep pencadangan dan pemulihan yang harus tetap diikuti meskipun database standby di-deploy.
Model tembaga
Model tembaga 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 skripnya untuk menggunakan Google Cloud SDK guna mengotomatiskan transmisi pencadangan.
Penggunaan deployment ini juga meningkatkan RTO karena pemulihan dua tahap yang diperlukan. RMAN tidak dapat langsung mengakses cadangan, sehingga cadangan harus dipindahkan ke lokasi yang tersedia untuk RMAN sebelum pemulihan dapat dimulai.
| Penonaktifan, layanan nonaktif | Jenis pemadaman | RPO | RTO |
|---|---|---|---|
| Tidak terencana | Kegagalan instance atau node yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance |
| Bencana: korupsi | Pencadangan archivelog, inkremental, atau penuh terakhir yang ditransfer dari RE | Jam, bergantung pada ukuran database dan bandwidth yang ditetapkan ke Partner Interconnect | |
| Bencana: kegagalan ekstensi region | Pencadangan archivelog, inkremental, atau penuh terakhir yang ditransfer dari RE | Hari / minggu, bergantung pada waktu yang diperlukan untuk mengaktifkan kembali ekstensi region | |
| 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 penyimpanan native Google Cloud untuk mempertahankan 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 lebih disukai 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 dengan NFS dan Cloud Storage. Google Cloud Filestore, yang menampilkan berbagi NFS ke instance Solusi Bare Metal, juga dapat digunakan.
Diagram berikut menunjukkan contoh deployment.
| Penonaktifan, layanan nonaktif | Jenis pemadaman | RPO | RTO |
|---|---|---|---|
| Tidak terencana | Kegagalan instance atau node yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance |
| Bencana: korupsi | Pencadangan arsip, inkremental, atau penuh terakhir | Jam, bergantung pada ukuran database dan bandwidth yang ditetapkan ke Partner Interconnect | |
| Bencana: kegagalan ekstensi region | Pencadangan arsip, inkremental, atau penuh terakhir | Hari / minggu, bergantung pada waktu yang diperlukan untuk mengaktifkan kembali ekstensi region | |
| 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 Pencadangan dan DR
Dalam deployment ini, Layanan Pencadangan dan DR digunakan untuk menyimpan cadangan di Google Cloud. Pencadangan dan DR menawarkan pendekatan inkremental-selamanya untuk pencadangan, yang disimpan di media berperforma tinggi yang didukung oleh Cloud Storage untuk retensi jangka panjang.
Pencadangan dan DR juga menawarkan RTO yang lebih cepat daripada menyimpan cadangan di Filestore atau Cloud Storage, karena dapat langsung membuat image file database tersedia untuk instance Oracle. Fitur mount dan migrasi akan membuat database online dengan cepat sekaligus menyalin kembali ke media penyimpanan produksi, sehingga mengurangi RTO secara drastis.
Diagram berikut menunjukkan contoh deployment.
| Penonaktifan, layanan nonaktif | Jenis pemadaman | RPO | RTO |
|---|---|---|---|
| Tidak terencana | Kegagalan instance atau node yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance
Detik jika menggunakan RAC |
| Bencana: korupsi | Pencadangan arsip, inkremental, atau penuh terakhir | Menit hingga jam, bergantung pada persyaratan performa, ukuran database, dan bandwidth yang ditetapkan ke Partner Interconnect | |
| Bencana: kegagalan ekstensi region | Pencadangan arsip, inkremental, atau penuh terakhir | Hari / minggu, bergantung pada waktu yang diperlukan untuk mengaktifkan kembali ekstensi region atau kemampuan pelanggan untuk beralih ke ekstensi region 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 bergantung pada replikasi asinkron; menggunakan replikasi sinkron memastikan tidak ada kehilangan data, tetapi waktu yang diperlukan untuk mengirim data antar-region biasanya meningkatkan waktu respons aplikasi di luar 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 switchover dapat memengaruhi performa aplikasi karena latensi jaringan antara server aplikasi dan database meningkat. Sebaiknya jangan menjalankan aplikasi dan database pendukung di region yang berbeda. Meskipun RTO untuk database mungkin kurang dari 1 menit, kasus kegagalan aplikasi mungkin memerlukan waktu beberapa menit hingga beberapa jam sebelum layanan berfungsi sepenuhnya. Dalam sebagian besar kasus, menjalankan rencana penggantian kegagalan pemulihan bencana lintas regional biasanya melibatkan proses manual karena jumlah komponen yang dipindahkan.
Dalam model Silver, Anda mungkin masih mengalami periode nonaktif atau masa pemeliharaan selama aktivitas patching kuartalan. Memperkenalkan Oracle RAC dapat mengurangi periode nonaktif untuk 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
transit melalui Partner Interconnect dan traffic lintas region melintasi
backbone jaringan Google. Server aplikasi dikonfigurasi di setiap
region, tetapi biasanya dimatikan di region disaster recovery hingga
peristiwa failover dideklarasikan.
| Penonaktifan, layanan nonaktif | Jenis pemadaman | RPO | RTO |
|---|---|---|---|
| Tidak terencana | Kegagalan instance atau node yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance
Detik jika menggunakan RAC |
| Bencana: korupsi | < 60 dtk | Menit hingga jam, bergantung pada failover aplikasi. | |
| Bencana: kegagalan ekstensi region | < 60 dtk | Menit hingga 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 emas
Jika khawatir dengan kehilangan data dalam model Silver, Anda dapat memilih model Gold yang menggunakan instance sinkronisasi jarak jauh untuk menyediakan replikasi sinkron ke instance yang berjalan di Google Cloud Compute Engine.
Instance sinkronisasi jarak jauh mencakup file kontrol database dan kumpulan 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 jarak jauh kemudian meneruskan redo ke database standby di region jarak jauh untuk diterapkan secara asinkron.
Instance sinkronisasi jarak jauh bukan salinan lengkap database, sehingga tidak dapat melayani traffic aplikasi. Instance sinkronisasi jarak jauh digunakan untuk menyediakan lokasi fault-tolerant agar perubahan database 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 telah diterima dan di-commit di instance sinkronisasi jauh.
Instance Compute Engine biasanya dipilih sebagai kandidat untuk menghosting instance sinkronisasi jarak jauh. Menempatkan instance sinkronisasi jarak jauh di zona Compute Engine yang dekat dengan database utama akan menambahkan 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 jarak jauh, yang menerima redo
sinkron. Instance sinkronisasi jarak 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 terencana | Kegagalan instance atau node yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance
Detik jika menggunakan RAC |
| Bencana: korupsi | 0 | Menit hingga jam, bergantung pada failover regional aplikasi. | |
| Bencana: kegagalan ekstensi region | 0 | Menit hingga 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 fast-start
Deployment Platinum 1 dibuat 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, yang 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 baru tanpa memerlukan intervensi manual. Aplikasi yang dikonfigurasi dengan benar 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 mode standby dan diskalakan selama peristiwa failover, atau berjalan dengan kapasitas penuh sepanjang waktu. Mengubah ukuran instance selama peristiwa failover berdampak negatif pada RTO, karena instance harus dimulai ulang selama operasi pengubahan ukuran.
Failover mulai cepat dikonfigurasi di instance Compute Engine yang menjalankan broker Data Guard dengan observer. Pengamat menjalankan klien Oracle dasar dengan koneksi ke semua database utama dan standby. Jika 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 observer ditempatkan di region yang terpisah dari database utama dan standby. Hal ini memberikan perlindungan terbaik terhadap kegagalan regional dan peristiwa partisi jaringan. Jika region ketiga tidak memungkinkan, observer harus diinstal di region utama, yang berjalan di zona yang berbeda dari standby near-site.
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 region
us-west2. - Database standby near-site yang berjalan di instance Compute Engine di
region
us-west2. - Database standby jarak jauh yang berjalan di server Solusi Bare Metal di region
us-east4. - 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 switchover). 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 terencana | Kegagalan instance atau node yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance
Detik jika menggunakan RAC |
| Bencana: korupsi | 0 | < 60 dtk | |
| Bencana: kegagalan ekstensi region | 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. Replikasi ini melakukan perubahan secara dua arah, sehingga memungkinkan konfigurasi database aktif/aktif.
Aplikasi harus divalidasi secara menyeluruh sebelum melakukan deployment aktif/aktif, dan Anda harus memperhitungkan deteksi dan resolusi konflik.
Tidak seperti Data Guard, GoldenGate memerlukan penginstalan dan pemeliharaan software tambahan di server database Oracle. Deployment aktif/aktif biasanya memerlukan skema dan desain aplikasi yang canggih untuk memanfaatkan deployment database multi-situs. Banyak aplikasi yang dikemas sebelumnya tidak mendukung jenis arsitektur ini.
Deployment yang bergantung pada GoldenGate untuk semua replikasi tidak dapat mendukung RPO hilangnya data nol karena sifat asinkron replikasi logis. 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 terencana | Kegagalan instance atau node yang dapat dipulihkan | 0 | Waktu yang diperlukan untuk memulai ulang instance |
| Bencana: korupsi | Detik ke Menit
0 jika menggunakan Data Guard di setiap lokasi |
0 | |
| Bencana: kegagalan ekstensi region | 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 |