Sequoia 提供了基于log4j的日志服務。
它的日志系統(tǒng)允許你選擇，比如：
你安裝完之后，在Sequoia的安裝目錄會有一個名為log4j.properties 的配置文件。你可以在運行時通過修改這個配置文件來控制日志輸出。
你可以為每個組件指定具體的日志級別。如果日志級別為OFF ,那么這個Sequoia 組件的日志就被關掉了。
下面是5種可用的日志級別:
DEBUG INFO WARN ERROR FATAL . 日志級別決定了記錄事件的嚴重性級別。比如，如果日志級別為ERROR,那么只有ERROR 或 FATAL級別的事件才會被記錄。
Sequoia 提供了完全透明的故障處理。這意味著只要保證至少有一個后端處于enable狀態(tài)，客戶端應用就感覺不到故障的發(fā)生。因此，客戶端不需要針對集群的異常做任何處理。
下面將更詳細地說明不同情況的故障處理：
如果一個控制器實例連接失敗，Sequoia 連接器會根據預定義的規(guī)則透明地將客戶端連接重新連接到另一個控制器。參考在控制器之間分配客戶端連接。
如果是在一個事務內部發(fā)生故障，事務的上下文會在重新連接時自動保存。
如果一個控制器失敗，這個控制器上的后端會被disable掉。現有的客戶端連接也會自動的根據預定義的規(guī)則重新連接到另外一個控制器上。
正在執(zhí)行的查詢，按下面方法處理:
當控制器無法從錯誤中恢復時，Sequoia 會在log目錄自動生成一個名為sequoia.report的trace文件.
如果后端失敗了，它會從負載均衡器上自動去掉。失敗操作的處理則取決于查詢類型：
這樣，所有的失敗都可以對客戶端透明地處理。
當一個新的后端添加到集群中時，它下面的數據庫必須被初始化為跟其他活動節(jié)點下的數據庫相同的狀態(tài)。
在Sequoia中，當一個新的節(jié)點添加到集群中時，會用recovery log這個節(jié)點初始化為跟集群中其他節(jié)點相同的狀態(tài)。這個進程不會影響到集群的其他操作，這使得Sequoia可以不停機的進行故障恢復。
Sequoia 的控制器為每個虛擬數據庫保留一份recovery log,這個log記錄了所有更新過虛擬數據庫的查詢和事務。recovery log包含下面內容：:
當你disable掉一個后端，比如，執(zhí)行數據庫維護，Sequoia 將會:
當你重新enable這個后端時，系統(tǒng)將會播放recovery log中從指定checkpoint以后的所有來自客戶端的update請求，同步它下面的數據庫。
如果你在正在使用的集群中添加一個新的后端，或者恢復一個失敗的后端，你必須先考慮一下有沒有可以用來自動同步數據的數據庫快照。因此，數據庫并不是簡單地只用recovery log就可以同步的。
在這種情況下，你必須先從一個有效的數據庫dump中恢復數據庫。從有效的dump文件中恢復數據庫也為你想用的后端增加了一個干凈的checkpoint.
你應該定期備份你的數據庫，以獲得一個有效的數據庫dump.
使用備份管理器，你可以備份一個數據庫來創(chuàng)建一個dump;或者一個表結構和特定數據庫的數據作為一個dump。你可以使用這個dump來：
備份操作的過程是這樣的:
如果只有一個enable的后端可用，你對它執(zhí)行備份操作會導致它轉入disable狀態(tài)。因此，整個集群在備份期間將停止服務。
你應該定時進行數據庫備份以避免需要停止整個集群來備份的情況發(fā)生。
當客戶端程序連接虛擬服務器的時候，Sequoia 連接器使用Sequoia URL連接到控制器。Sequoia URL包含了一個所有要用到的控制器的IP列表。默認的，Sequoia 控制器監(jiān)聽25322 端口。
如果當前選擇的控制器失敗了，將會自動從Sequoia URL定義的列表中重新取一個新的出來。
新的連接，根據預定義的負載均衡策略（隨機，輪詢，順序），連接到一個控制器上。所有的屬于這個連接的請求都會被發(fā)送到同一個控制器，但是這個控制器會把這些請求在它下面的后端之間進行的負載均衡。
一旦連接建立，一個針對某個虛擬數據庫的用戶名和密碼的組合，會連同數據庫的名字一起被發(fā)送到控制器的驗證管理器中進行檢查。
在后端之間進行負載均衡，有下面幾種可選方案:
客戶端連接可以分為下面兩種:
AUTOCOMMIT模式）或者事件持續(xù)期間分配的，然后這個連接被放回后端連接池。 這兩種連接都是Sequoia 分配的：如果沒有連接可用，控制器會等待連接池提供可用的連接。
這里有一些持久化連接用法的典型例子:
AUTOCOMMIT 中）, 比如在MySQL中SELECT LAST_INSERT_ID.
因為下面的原因，不推薦使用Sequoia 的持久化連接。
減低系統(tǒng)性能；
打開和關閉持久化連接是在集群范圍內執(zhí)行的，因此會降低系統(tǒng)性能；
會導致禁止后端或關閉數據庫失敗；
后端只有在所有的持久化連接都關閉后才能被disable。
每個連接的打開/關閉都會被記錄到recovery log中。當一個checkpoint需要被添加到recoverylog中時（比如在數據庫庫備份期間要disable掉后端），Sequoia必須等當前打開的所有持久化連接都關閉完之后才能執(zhí)行，因為連接的上下文不會被記錄。
而且，虛擬數據庫也只能在所有的后端都被disable掉之后才能關閉。所以，如果應用無限期的保持打開連接池中的連接的話，虛擬數據庫將無法正常關閉。
那么在使用持久化連接時怎么防止這些情況發(fā)生呢。
上述失敗可能發(fā)生如果我們這么使用Sequoia 的話：
close () 關閉連接。 確保你的應用顯式的關閉了它們的連接。特別要檢查連接池和連接重用計劃。
如果你使用像Jboss那樣的應用服務器。你必須配置連接池，因此沒用的連接被續(xù)約并按照一定的規(guī)則關閉掉（idle-timeout 參數在虛擬數據庫的配置文件中）。
注意：
使用Sequoia時，不推薦同時使用持久化連接和連接池。因此，如果你沒用持久化連接，你應該把他們disable掉。
這章講解釋你可以使用的不同的部署模型和配置。
sequoia使用RAIDb的概念。
RAIDb的目標：
通過將多個廉價的數據庫實例組合到一個數據庫陣列，提供比單臺數據庫更好的性能和容錯性。
隱藏分布式數據庫的復雜性，提供給數據庫客戶端一個獨立的數據庫。
在RAIDb中，一個控制器在其他資源的前面。客戶發(fā)送他們的請求到RAIDb控制器，這個控制器將他們分發(fā)給一組RDBMS后端。
有不同的RAIDb級別或數據分發(fā)方案可用，它提供不同的費用，性能，或者容錯權衡。
RAIDb-0 分割數據庫表到一個數據庫后端節(jié)點集。
注意：
當前的實現不支持分布式join。也就是說如果你想在表t1和t2間進行join操作，你必須確保t1和t2在同一臺機器上。
擴展性的提升取決于表的數目和各個表的負載情況：
全復制
RAIDb-1的擴展能力取決于控制器廣播更新所有節(jié)點的能力。如果有大量后端數據庫，使用復合RAIDb可以獲得更好的擴展性。
RAIDb-1提供了對讀查詢的加速，因為他們可以被均衡到所有后端上。另一方面，它對寫操作沒有加速（update,insert,delete請求），因為他們必須廣播到所有節(jié)點。寫操作在所有的后端并行執(zhí)行。所以，在寫的角度來看，RAIDb-1可能比不上一個單獨的節(jié)點，但是從讀的角度來看，性能會隨著后端節(jié)點的增加而線性增長。
RAIDb-1有很好的容錯性，因為系統(tǒng)即使只有一個后端可用時也可以保持工作。
不像RAIDb-0，RAIDb-1控制器不需要知道數據庫的結構，因為所有的節(jié)點都有能力處理任何請求。然后，RAIDb-1提供了一個緩存，它需要數據庫結構來維護緩存的一致性。
RAIDb-2可以看作是RAIDb-0 和 RAIDb-1權衡下的一個中庸的解決方案。它支持調整每個數據庫表的部分復制程度，以獲得一個做好的讀寫性能。
RAIDb-2:
下面是RAIDb-2的典型應用：
沒有或者只有少數幾個節(jié)點運行整個數據庫，一組節(jié)點各自運行這數據庫的一部分。
下圖中的例子顯示了RAIDb-2的部分復制，數據庫包含3個表：x,y,和z.第一個后端包含整個數據庫，但是其他節(jié)點都只包含一個或兩個表。表x 和 y有3份拷貝,表z有兩份拷貝。任一節(jié)點失敗，仍然可以從其他的存活節(jié)點中找到數據。
RAIDb-2對于異構數據庫非常有用。一個已有的企業(yè)數據庫使用商業(yè)數據庫，但是要建立一個全拷貝無論是從存儲上還是從增加許可的費用上來說，都太貴了。有了RAIDb-2就好辦了，你可以增加幾個小型開源數據庫來各自運行整個數據庫中的某些部分來代替整個數據庫，這樣也可以獲得更好的容錯性。在下圖這個使用RAIDb-2進行部分復制的案例中，第一個后端節(jié)點可以是商業(yè)數據庫，其他4個節(jié)點是小型開源數據庫。
RAIDb-2容錯性沒有RAIDb-1好，但是它有效的改善了寫操作的效率。
跟RAIDb-0類似，RAIDb-2也要求控制器知道所有數據庫的結構，以便將請求定向到適當的節(jié)點。
警告：
在Sequoia中使用RAIDb-2仍然有一些限制。
當前，備份器不支持部分導出：當你要備份一個后端時，你將dump所有的表。類似的，當你restore一個后端時，你也將恢復所有的表。比如節(jié)點1有表x,y和z,你把他們全部dump了，如果你想用這個dump恢復節(jié)點2時，節(jié)點2將得到全部的表（x,y,z）.
當節(jié)點在恢復過程中，這就成問題了：recoverylog記錄了所有的請求（對所有表的），并且嘗試去把他們重新走一遍。如果在恢復過程需要的一個表不在當前這個節(jié)點上，那么這個節(jié)點就不能被重新同步了。因此，這是個需要修復的bug，應該允許只同步當前節(jié)點上有的那些表。
另外，RAIDb-2也不支持分布式的join,跟 RAIDb-0 相同。
除了數據復制以外，Sequoia 還支持控制器冗余。為了防止Sequoia 控制器成為單點故障，你不惜在Sequoia 的配置中包括兩個活更多的控制器節(jié)點。
注意：
在單個數據庫和RAIDb-0配置中，你只能使用一個單獨的控制器：這些控制不支持控制器復制。
Sequoia 包含兩個可選的配置來提供水平擴展：
注意：
每個控制器必須被分配給一組特定的后端：后端堅決不能在多個控制器間共享。
搭配控制器配置適用于高可用系統(tǒng)：
在一個搭配控制器配置中，Sequoia被安裝成兩個節(jié)點的配置，兩個節(jié)點都作為控制器和后端/數據庫服務器。
專用服務器適用于大型生產環(huán)境
在規(guī)模較大的環(huán)境中，Sequoia 控制器安裝在專用的服務器上來提升性能。
在控制器后面增加更多的后端，可以讓Sequoia為更多的客戶端應用請求服務。請求被后端的數據庫服務器以他們各自的速度執(zhí)行，但是控制器后面的服務器越多，可用的資源也就越多。
那么你系統(tǒng)后端需要多少臺后端才合適呢？這依賴于你的應用類型：
如果你有一個讀操作非常頻繁的應用，那么最好在每個控制器后面都放幾個后端。
另一方面，如果你的應用寫操作非常頻繁，那么控制器后面的后端最好稍微少一些。
注意：
寫操作不能和讀操作用相同的方法來衡量：
寫操作需要在每個節(jié)點上按照相同的順序同步執(zhí)行。
默認的，當所有的后端都執(zhí)行完這次請求后，寫操作的結果會返回給客戶端。（這個行為也可以在虛擬數據庫的配置文件中配置：你也可以當一臺后端執(zhí)行完這次查詢后就馬上返回結果，或者當多數后端完成這次請求后返回。）所以，對于寫操作來說，這意味著控制器后面增加幾個后端，就要多維護幾份數據庫的拷貝，但它也會增加查詢的處理能力。
你客戶端應用通過Sequoia訪問數據庫的配置方式，取決于你所使用的客戶端應用。
在配置你的客戶端應用時，你必須提供基本的配置信息。這些信息對于所有不同的客戶端應用都是一樣的。這些必需的信息包括：
你的Sequoia的URL或IP，虛擬數據庫的名字；
訪問虛擬數據庫的用戶名密碼。
下面講講Sequoia的組件和他們各自的功能。
下面這些術語在我們下面討論和描述Sequoia的架構時將會用到：
虛擬數據庫(virtual database) 是指在該集群中載入的不同的數據庫服務器上數據庫實例的分發(fā)視圖。
節(jié)點(node) 是指一臺物理機器，它可以是一個控制器(controller)，也可以是一個數據庫服務器，或者兩者都是。
數據庫服務器 是一個在虛擬數據庫(virtual database)中運行的數據庫引擎的實例。
后端(backend) 是一個Sequoia對象，用來管理一臺受管的數據庫服務器。
控制器(controller) 是運行在JVM中的一個Sequoia控制器(controller)實例。
Sequoia connector 連接著客戶端應用和控制器(controller)。Sequoia的基本安裝只包含一個用于java客戶端的jdbc驅動，但是Carob項目提供了用于其他客戶端應用的連接器。
Sequoia JDBC驅動是一個type 4 JDBC驅動,它轉發(fā)所有的數據庫請求到Sequoia控制器(controller).
如果你正在使用Sequoia和Java客戶端,那么你要用Sequoia驅動替換掉客戶端原來使用的特定數據庫的驅動,使客戶端應用通過Sequoia驅動連接到集群.Perl客戶端也可以通過DBD::JDBC Perl模塊和Sequoia驅動來訪問Sequoia.
Sequoia控制器(controller)是一個Java程序,它實際上是Sequoiaconnector和后端(backend)之間的一個代理.控制器(controller)enable受管的一組數據庫暴露給客戶端應用作為一個虛擬數據庫(virtual database).Sequoia控制器(controller)使用原生的數據庫JDBC驅動訪問數據庫.
后端(backend)是用來管理它下面數據庫服務器的一個Sequoia對象:
后端(backend)是指一個數據庫服務器實例的Sequoia視圖
后端(backend)對象可以使用集群管理應用來管理.
當后端(backend)被disable時,它下面的數據庫服務器的實例仍然是可操作的.比如要執(zhí)行一次數據庫備份操作,為了防止在備份過程中執(zhí)行請求,確保數據庫的一致性,這個時候就要把后端(backend)disable掉.
每個控制器(controller)對應專門的一組后端(backend):為了確保數據庫的一致性,數據庫在不同的控制器(controller)間不能共享.
控制器(controller)使用一個組播協議來交換信息,維護相互之間狀態(tài)信息的一致性.這種控制器(controller)之間的數據復制防止了單點故障的發(fā)生.
只有數據庫update和commit/rollback命令用組播協議廣播給所有節(jié)點,所有其他的命令都在控制器(controller)內本地執(zhí)行.
默認的,Sequoia控制器(controller)通訊是使用Appia實現的.
一個虛擬數據庫(virtualdatabase)虛擬了一個獨立的數據庫,但是Sequoia控制器(controller)虛擬了一個關系式數據庫管理系統(tǒng)(RDBMS).換句話來說,一個RDBMS可以支持多個數據庫，那么一個控制器(controller)也就可以提供多個虛擬數據庫(virtual database)。
一個虛擬數據庫(virtual database)由下面幾部分組成
驗證管理器(authentication manager)- 在建立連接時，驗證虛擬數據庫(virtualdatabase)的用戶名密碼和真實數據庫服務器的用戶名密碼的映射是否正確。關于這個更多的信息，請看Sequoia3.0安裝配置指南中配置Sequoia用戶名和密碼一節(jié)。
請求管理器(request manager)-處理Sequoia connector轉發(fā)來的客戶端請求。
備份管理器(backup manager)-執(zhí)行數據庫備份還原操作，在控制器(controller)之間傳送備份文件。
后端(backend)-后端(backend)用來管理它下面的數據庫服務器。
一個虛擬數據庫(virtual database)和它的組件被配置在一個特定控制器(controller)的虛擬數據庫(virtualdatabase)配置文件中。換句話說，要配置一個虛擬數據庫(virtualdatabase)，你必須有兩個對應這個虛擬數據庫(virtual database)特有的特定控制器(controller)的配置文件。
請求管理器(request manager)
請求管理器(request manager)包含了控制器(controller)的核心功能。當一個請求從Sequoia connector進來時，它首先被傳遞到這個虛擬服務器相關的請求管理器(request manager)中。
請求管理器(request manager)由下面幾部分組成，在后面我們會對它們進行詳細說明：
請求調度器(request scheduler)
負載均衡器(load balancer)(load balancer)
recovery log
緩存 三個可選的請求緩存：
- 元數據緩存，緩存結果集的元數據（比如列名，類型等），它通常在創(chuàng)建結果集時用到。
- 解析緩存，它緩存解析的結果。這種緩存尤其是對于prepared statements非常有用。
- 查詢結果緩存，它緩存了只讀查詢的結果：這個很容易理解，如果一個查詢要執(zhí)行多次，那么使用這種緩存時，只會請求數據庫一次，然后一直從緩存中讀取。
請求調度器(request scheduler)調度請求并確保查詢精確一致。
Sequoia使用一個傳遞調度方法，它給每個查詢分配一個唯一的標識，然后轉發(fā)到負載均衡器(load balancer。這個標識在后面被用來確保寫操作被以相同的順序發(fā)送到所有的后端(backend)。
每個數據庫服務器最終執(zhí)行這個計劃并鎖定。鎖定的時間依賴于數據庫引擎。
從請求調度器(request scheduler)出來，客戶端請求就到達了負載均衡器(load balancer)。
Sequoia的負載均衡機制提高了數據庫集群的整體性能。它在后端(backend)之間根據預先定義好的負載均衡方式來分配請求：用戶可以選擇一個最適合他們系統(tǒng)的方式。關于負載均衡方式的更多信息，請看 Sequoia的負載均衡 一章。
Recovery log是一個事件日志，它記錄了那些更新虛擬數據庫(virtual database)的所有請求和事件，可以用來進行數據庫的恢復和同步。
備份管理器(backup manager)和recover log一起，允許動態(tài)地向虛擬數據庫(virtualdatabase)中添加新的后端(backend)而不用重啟整個系統(tǒng)。類似的，當一個后端(backend)恢復要進行錯誤恢復時,你可以使用備份管理器(backup manager)和recovery log很容易的重新enable它，
Sequoia安裝包含了一個通用的和幾個特定的關系數據庫管理系統(tǒng)的備份器。你也可以使用你自己的備份管理器(backup manager)代碼。更詳細的可以看Sequoia 3.0 安裝配置指南中如何配置備份管理器(backup manager)。
sequoia是一個開源的數據庫集群中間件，它允許任何JAVA程序（獨立的JAVA應用程序，EJB容器，servlet等）通過JDBC驅動透明的訪問數據庫集群。
如果出現下面情況，可以考慮使用sequoia:
首先，你有一個java應用或基于java的應用服務器要訪問一個或幾個數據庫。并且數據庫已經成為你的應用的瓶頸或者單點故障，或者兩者都是。
注意：如果你使用的不是java,那么可以看看carbo這個項目，它提供了使用sequoia的C++和Perl的擴展。
sequoia可以幫你解決下面問題:
1. 高性能擴展：通過增加數據庫節(jié)點，在所有這些節(jié)點間進行負載均衡。
2. 數據庫層的高可用：sequoia允許數據庫崩潰，它采用數據復制技術來進行容錯。
3. 性能提升：sequoia通過細粒度的查詢緩存和透明連接池來提升性能。
4. sql通信日志：sequoia提供了sql通信日志來進行性能監(jiān)控和分析。
5. 提供了多種數據庫引擎的支持。
要使用sequoia,你不需要對你的客戶端程序，應用服務器或者數據庫服務器做任何修改。你只需要確保所有的數據庫訪問都是通過sequoia執(zhí)行就可以了。
sequoia實現了廉價冗余數據庫陣列(Redundant Array of Inexpensive Databases,RAIDb)的概念,這種數據庫是分布式的，sequoia在節(jié)點之間進行數據復制，并在這些節(jié)點間進行查詢時的負載均衡。
sequoia為客戶端提供了一個通用的jdbc驅動。這個驅動把客戶端的sql請求轉發(fā)到sequoia控制器上，然后控制器把請求發(fā)給數據庫集群（讀是負載均衡，寫是進行廣播）。
sequoia的架構是開放的，允許你定制自己的請求調度器、負載均衡器、連接管理器、緩存策略等等。
關于sequoia組件的更多信息，請參考 sequoia架構 一章。
sequoia可以被用于任何提供了jdbc驅動的關系數據庫。也就是說，幾乎所有的開源和商業(yè)數據庫都可以支持。sequoia可以創(chuàng)建任何配置的數據庫集群，在這個集群中你可以混合使用多種數據庫。
關于sequoia部署的更多信息，請參考 sequoia部署模型 一章。
簡單，強大，通用，用raid的思路來做集群，想法很獨特，但不知道哪些用戶在用。
Sequoia is the core technology providing database clustering capabilities. It is composed of a controller implementing the RAIDb (Redundant Array of Inexpensive Databases) technology.
Sequoiacontrollers are replicated for HA and scalability purposes. Controllersuse group communication to synchronize the cluster. Hedera∞ is a group communication wrapper that can be plugged to work with multiple group communication implementations such as Appia, JGroups or Spread.
Sequoia comes with a JDBC driver for Java application.
Additional drivers for PHP, Perl, ODBC, MySQL native API and C/C++ applications are also provided through the Carob project. with transparent failover capabilities.
