更加復雜，但是靈活的方法，用于路由報表查詢到一個專屬節點去使用標簽和讀偏好。

因為使用隱藏成員，設置一個成員為priority: 0，但是不設置它為隱藏。然而，分配一個標簽use: reporting：PRIMARY>?conf?=?rs.config()

{?"_id"?:?"test",?"version"?:?21,?"members"?:?[?{?"_id"?:?0,?"host"?:?"xucy.local:27017",?},?{?"_id"?:?1,?"host"?:?"xucy.local:28017",?},?{?"_id"?:?2,?"host"?:?"xucy.local:29017",?}?]?}?//?we'll?use?members[1],?the?instance?on?port?28017

PRIMARY>?conf.members[1].priority?=?0

PRIMARY>?conf.members[1].tags?=?{?"use":?"reporting"?}

PRIMARY>?conf.version?+=?1

PRIMARY>?rs.reconfig(conf)

[...]

像之前一樣，xucy.local:28017絕不會成為主；然而，在這種情況下其他兩個機器變得不可達，你的應用將能處理讀到報表服務器。它會繼續不用說你的報表應該在這樣一個事件期間暫停。

你的報表代碼將會像這樣(用Python，這次)：from?pymongo?import?MongoReplicaSetClient

from?pymongo.read_preferences?import?ReadPreference

rep_set?=?MongoReplicaSetClient(?'xucy.local:27017,xucy.local:28017,xucy.local:29017',?replicaSet?=?'test',?read_preference?=?ReadPreference.SECONDARY,?tag_sets?=?[{'use':'reporting'}]?)?#?check?to?ensure?we're?not?running?reporting?against?the?sole?remaining?secondary?if?rep_set.primary?is?not?None:?rep_set.my_application.users.aggregate(...)

以上只發送報表查詢到副本標記有use: reporting，并且如果沒有可用的主，它根本上避免運行。在實踐中，你會拋出異常并在你的擴展代碼中處理它們，如果你發現沒有主！更好的還是，你的監控可以設置運行時可用的值，你可以轉移，例如，reporting_system.ok()。

益處和考慮

使用標簽和讀偏好允許一些級別的靈活性，而那在隱藏成員中是不可能的。

報表實例可以容易添加

因為你的連接代碼是可定義的，而不是指定到一個專門的主機，添加更多節點為報表作業，只添加他們并標記他們，像這樣：PRIMARY>?rs.add({_id:3,?host:"xucy.local:30017",?priority:0,?tags:{'use':'reporting'}})

你存在的代碼將會利用新的容量，并且復制集將繼續運行，不用觸發選舉和從客戶端斷開連接。

報表實例可以被跳過或刪除

報表標記可以被移動，或者甚至移除，如果你需要提供讀帶寬給其他作業在必要時。像這樣的一個重新配置將會觸發選舉，并重連所有客戶端，但是這不會比其他選項更糟糕。注意：這是一個反模式的通過發布生產讀到副本成員來增加常用容量。這只是一個緊急方式。

一些驅動需要手工同步

Ruby驅動(像1.9.2)，例如，不會刷新副本集的視圖除非客戶端像這樣顯式初始化，使用refresh_mode: :sync。檢查你的驅動文檔。

結論

簡單的復制配置已經成為我喜歡MongoDB原因之一，它使得MySQL復制看起來像出自石器時代。它有些粗糙，但是已經在不斷提升性能。無論你使用標記集合或者隱藏成員，構建一個報表架構在MongoDB的復制屬性上，簡化操作，讓你專注于構建一個偉大的應用。

總結

以上是生活随笔為你收集整理的mysql反模式_MongoDB报表实例 -- 标签成员方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。