Linux系統(tǒng)，oracle 11g主從同步中，怎么區(qū)分主庫與從庫，可以在從庫上執(zhí)行增刪改操作嗎？你說的是甲骨文的DG技術(shù)嗎？您可以使用select open mode，database The ro

Linux系統(tǒng)，oracle 11g主從同步中，怎么區(qū)分主庫與從庫，可以在從庫上執(zhí)行增刪改操作嗎？

你說的是甲骨文的DG技術(shù)嗎？您可以使用select open mode，database The role from V$database語句查詢數(shù)據(jù)庫角色。Oracle從數(shù)據(jù)庫有三種角色：物理備份、邏輯備份和快照備份。物理備用數(shù)據(jù)庫只能處于只讀狀態(tài)，無法寫入。邏輯備用數(shù)據(jù)庫處于讀寫狀態(tài)，但寫入備用數(shù)據(jù)庫的數(shù)據(jù)不會同步到主數(shù)據(jù)庫的快照。備用數(shù)據(jù)庫處于讀寫狀態(tài)，這類似于為數(shù)據(jù)庫創(chuàng)建還原點。三者可以互換。

MySQL主從復(fù)制能完美解決數(shù)據(jù)庫的單點問題嗎？為什么？

使用主從時，實際上放棄了強一致性。由于受試者只問一個問題，我們不考慮訪問次數(shù)的問題。換句話說，假設(shè)主從復(fù)制可以完全支持當(dāng)前的系統(tǒng)訪問。)

通用數(shù)據(jù)庫主從設(shè)置：

主數(shù)據(jù)庫可以讀寫

即系統(tǒng)可以同時從主數(shù)據(jù)庫和從數(shù)據(jù)庫獲取數(shù)據(jù)。數(shù)據(jù)寫入主庫后，會自動同步到從庫。

這構(gòu)成了一個簡單的分布式系統(tǒng)。根據(jù)cap定理，三個中只能選擇一個。如果一致性很強，則不會提高系統(tǒng)的可用性，反而會降低系統(tǒng)的可用性。

讓我們看看上面的主從結(jié)構(gòu)中可能出現(xiàn)什么問題：

系統(tǒng)寫入主數(shù)據(jù)庫，然后從主數(shù)據(jù)庫進行查詢。這是一個單點數(shù)據(jù)庫，沒有影響。

-如果數(shù)據(jù)已同步，則沒有影響

-如果數(shù)據(jù)未同步，則會查詢舊數(shù)據(jù)

-如果同步有問題，則會斷開主設(shè)備和從設(shè)備的連接。如果系統(tǒng)無法感知它，那么查詢可能總是舊數(shù)據(jù)。這里我們需要監(jiān)視同步。當(dāng)同步出現(xiàn)問題時，我們應(yīng)該及時處理

掛斷庫。主數(shù)據(jù)不能與從數(shù)據(jù)同步。如果主從交換機是自動的，單點故障的概率只會降低50%（如果主數(shù)據(jù)庫或備用數(shù)據(jù)庫發(fā)生故障，并且沒有人恢復(fù)）。

什么情況會導(dǎo)致MySQL主從復(fù)制延遲？

主從復(fù)制有兩個線程，SQL和Io。前者負責(zé)SQL的復(fù)制，后者負責(zé)編寫。因此，從兩個方面來看，當(dāng)網(wǎng)絡(luò)較差，或者帶寬有限，或者主CPU太忙，跟不上binlog傳輸速度，或者從機IO性能較差時，很容易造成主從復(fù)制延遲。從show slave status的一些參數(shù)可以看出，大約在master后面XX個左右，實際上MySQL的主從問題很大，設(shè)計比較低。我至少三年沒有關(guān)注MySQL了。我不知道這方面有沒有改進。

數(shù)據(jù)庫的讀寫分離數(shù)據(jù)庫是怎么同步的？

數(shù)據(jù)不同，讀寫分離同步操作不同，以MySQL和Oracle為例：

讀寫分離：最常用的主從復(fù)制實現(xiàn)讀寫分離功能

當(dāng)數(shù)據(jù)被修改時，執(zhí)行內(nèi)容通過網(wǎng)絡(luò)傳輸?shù)綇膸?，添加到從庫的重放倉，然后通過重做日志恢復(fù)主庫的操作，達到同步效果；

讀/寫分離：常見的讀/寫分離方案是DG（備用數(shù)據(jù)庫可讀）

將操作寫入archivelog，然后通過網(wǎng)絡(luò)傳輸?shù)絺溆脭?shù)據(jù)庫。然后備用數(shù)據(jù)庫用archivelog恢復(fù)數(shù)據(jù)，達到同步的目的。