MySQL Connector/J 支援伺服器容錯移轉。當基礎作用中連線發生與連線相關的錯誤時,就會發生容錯移轉。預設情況下,連線錯誤會傳播至用戶端,用戶端必須處理這些錯誤,例如,重新建立工作物件 (Statement
、ResultSet
等),並重新啟動程序。有時,驅動程式可能會在用戶端應用程式繼續執行之前最終自動返回原始主機,在這種情況下,主機切換是透明的,用戶端應用程式甚至不會注意到它。
使用容錯移轉支援的連線就像標準連線一樣運作:用戶端在容錯移轉過程中不會遇到任何中斷。這表示即使兩個連續的陳述式可能在兩個不同的實體主機上執行,用戶端也可以依賴相同的連線執行個體。但是,這並不表示用戶端不必處理觸發伺服器切換的例外狀況。
容錯移轉是在伺服器連線的初始設定階段透過連線 URL 設定的 (請參閱此處的格式說明 here)
jdbc:mysql://[primary host][:port],[secondary host 1][:port][,[secondary host 2][:port]]...[/[database]]»
[?propertyName1=propertyValue1[&propertyName2=propertyValue2]...]
連線 URL 中的主機清單包含兩種主機類型,主要主機和次要主機。在開始新連線時,驅動程式會始終先嘗試連線至主要主機,如果需要,則在遇到通訊問題時,按順序容錯移轉至清單上的次要主機。即使初始連線至主要主機失敗,且驅動程式連線至次要主機,主要主機永遠不會失去其特殊狀態:例如,可以使用與次要主機不同的存取模式來設定主要主機,並且在容錯移轉過程中選擇主機時,可以將其置於較高的優先順序。
容錯移轉支援是透過下列連線屬性設定的 (其功能在以下段落中說明)
failOverReadOnly
secondsBeforeRetrySource
queriesBeforeRetrySource
retriesAllDown
autoReconnect
autoReconnectForPools
設定連線存取模式
與任何標準連線一樣,初始連線至主要主機是以讀寫模式進行的。但是,如果驅動程式無法建立與主要主機的初始連線,且自動切換至清單上的下一個主機,則存取模式現在取決於屬性 failOverReadOnly
的值,預設值為 「true」。如果驅動程式最初連線至主要主機,並且由於某些連線失敗而容錯移轉至次要主機,也會發生相同的情況。每次連線返回主要主機時,無論先前是否已連線至主要主機,其存取模式都將為讀寫。可以隨時透過呼叫方法 Connection.setReadOnly(boolean)
在執行階段變更連線存取模式,這會部分覆寫屬性 failOverReadOnly
。當 failOverReadOnly=false
且存取模式明確設定為 true 或 false 時,無論連線至哪種類型的主機,它都會成為主機切換後每個連線的模式;但是,如果 failOverReadOnly=true
,則只有在驅動程式連線至主要主機時,才有可能將存取模式變更為讀寫;但是,即使無法變更目前連線的存取模式,驅動程式也會記住用戶端的最後意圖,並且在返回主要主機時,會使用該模式。如需範例,請參閱具有雙主機連線的下列事件順序。
-
序列 A,
failOverReadOnly=true
以讀寫模式連線至主要主機
設定
Connection.setReadOnly(true)
;主要主機現在為唯讀模式容錯移轉事件;以唯讀模式連線至次要主機
設定
Connection.setReadOnly(false)
;次要主機保持為唯讀模式返回主要主機;連線現在為讀寫模式
-
序列 B,
failOverReadOnly=false
以讀寫模式連線至主要主機
設定
Connection.setReadOnly(true)
;主要主機現在為唯讀模式容錯移轉事件;以唯讀模式連線至次要主機
設定
Connection.setReadOnly(false)
;與次要主機的連線切換為讀寫模式返回主要主機;連線現在為讀寫模式
這兩種情境之間的差異在步驟 4:序列 A 中次要主機的存取模式在該步驟中不會變更,但驅動程式會記住並在返回主要主機時使用設定的模式,否則將為唯讀;但在序列 B 中,次要主機的存取模式會立即變更。
設定返回主要主機
如前所述,當涉及主機的存取模式時,主要主機在容錯移轉安排中很特殊。此外,驅動程式預設會盡快嘗試返回主要主機,即使未發生任何通訊例外狀況也是如此。兩個屬性 secondsBeforeRetrySource
和 queriesBeforeRetrySource
決定驅動程式何時準備好重試與主要主機的重新連線 (屬性名稱中的 Source
代表連線 URL 的主要主機,不一定是指複寫設定中的來源主機)
secondsBeforeRetrySource
決定驅動程式在嘗試返回主要主機之前等待的時間長度queriesBeforeRetrySource
決定在驅動程式嘗試返回主要主機之前執行的查詢數量。請注意,對於驅動程式,每次呼叫Statement.execute*()
方法都會遞增查詢執行計數器;因此,當呼叫Statement.executeBatch()
或啟用allowMultiQueries
或rewriteBatchStatements
時,驅動程式可能無法準確計算在伺服器上執行的實際查詢數量。此外,驅動程式會在多種情況下於內部呼叫Statement.execute*()
方法。這一切表示您只能將queriesBeforeRetrySource
用作返回主要主機的粗略規格。
一般而言,當至少滿足兩個屬性指定的其中一個條件時,就會嘗試返回主要主機,且嘗試始終在交易界限時進行。但是,如果關閉自動認可,則只有在呼叫方法 Connection.commit()
或 Connection.rollback()
時才會進行檢查。可以同時將 secondsBeforeRetrySource
和 queriesBeforeRetrySource
設定為 「0」 來關閉自動返回主要主機。僅將其中一個屬性設定為 「0」 只會停用一部分的檢查。
設定重新連線嘗試
當建立新的連線或發生容錯移轉事件時,驅動程式會嘗試依序連線到主機清單中的下一個候選主機。當到達清單末尾時,它會從清單開頭重新開始;但是,如果 (a) 並非所有次要主機都已至少測試過一次,且 (b) 尚未滿足由 secondsBeforeRetrySource
和 queriesBeforeRetrySource
定義的回退條件,則會跳過主要主機。整個主機清單的每次執行(不一定在主機清單末尾完成)都計為單次連線嘗試。驅動程式會嘗試的連線次數,由屬性 retriesAllDown
的值指定。
無縫重新連線
雖然不建議這麼做,但您可以將參數 autoReconnect
或 autoReconnectForPools
設定為 true
,讓驅動程式在執行容錯移轉時,不會使現有的 Statement
或 ResultSet
實例失效。這可讓用戶端在容錯移轉事件後繼續使用相同的物件實例,而無需採取任何例外措施。然而,這可能會導致意想不到的結果:例如,如果驅動程式連線到具有讀/寫存取模式的主要主機,而它容錯移轉到具有唯讀模式的次要主機,則進一步嘗試發出會變更資料的查詢將導致錯誤,且用戶端不會知道這一點。當使用資料串流時,此限制尤其重要:在容錯移轉之後,ResultSet
看起來沒問題,但底層連線可能已經變更,並且沒有可用的備份游標。
使用具有 DNS SRV 的 JDBC 設定伺服器容錯移轉
有關詳細資訊,請參閱第 6.14 節,「對 DNS SRV 記錄的支援」。