trx主機

A. 怎麼判斷mysql是否是半同步復制

在談這個特性之前，我們先來看看mysql的復制架構衍生史。 MySQL的復制分為三種： 第一種，即普通的replication。 搭建簡單，使用非常廣泛，從mysql誕生之初，就產生了這種架構，性能非常好，可謂非常成熟。 但是這種架構數據是非同步的，所以有丟失資料庫的風險。 第二種，即mysql cluster。 搭建也簡單，本身也比較穩定，是mysql裡面對數據保護最最靠譜的架構，也是唯一一個數據完全同步的架構，絕對的零丟失。不過性能就差遠些了。 第三種，即semi-sync replication，半同步，性能，功能都介於以上兩者之間。從mysql5.5開始誕生，目的是為了折中上述兩種架構的性能以及優缺點。「我們今天談論第三種架構

我們知道，普通的replication，也即mysql的非同步復制，依靠mysql二進制日誌也即binary log進行數據復制。比如兩台機器，一台主機也即master，另外一台是從機，也即slave。

1. 正常的復制為：事務一（t1）寫入binlog buffer；mper 線程通知slave有新的事務t1；binlog buffer 進行checkpoint；slave的io線程接收到t1並寫入到自己的的relay log；slave的sql線程寫入到本地資料庫。 這時，master和slave都能看到這條新的事務，即使master掛了，slave可以提升為新的master。 2. 異常的復制為：事務一（t1）寫入binlog buffer；mper 線程通知slave有新的事務t1；binlog buffer 進行checkpoint；slave因為網路不穩定，一直沒有收到t1；master 掛掉，slave提升為新的master，t1丟失。

3. 很大的問題是：主機和從機事務更新的不同步，就算是沒有網路或者其他系統的異常，當業務並發上來時，slave因為要順序執行master批量事務，導致很大的延遲。

為了彌補以上幾種場景的不足，mysql從5.5開始推出了半同步。

即在master的mper線程通知slave後，增加了一個ack，即是否成功收到t1的標志碼。也就是mper線程除了發送t1到slave，還承擔了接收slave的ack工作。如果出現異常，沒有收到ack，那麼將自動降級為普通的復制，直到異常修復。

我們可以看到半同步帶來的新問題： 1. 如果異常發生，會降級為普通的復制。 那麼從機出現數據不一致的幾率會減少，並不是完全消失。 2. 主機mper線程承擔的工作變多了，這樣顯然會降低整個資料庫的性能。 3. 在MySQL 5.5和5.6使用after_commit的模式下, 即如果slave 沒有收到事務，也就是還沒有寫入到relay log 之前，網路出現異常或者不穩定，此時剛好master掛了，系統切換到從機，兩邊的數據就會出現不一致。 在此情況下，slave會少一個事務的數據。

隨著MySQL 5.7版本的發布，半同步復制技術升級為全新的Loss-less Semi-Synchronous Replication架構，其成熟度、數據一致性與執行效率得到顯著的提升。

MySQL 5.7對數據復制效率進行了改進1 主從一致性加強支持在事務commit前等待ACK

新版本的semi sync 增加了rpl_semi_sync_master_wait_point參數 來控制半同步模式下 主庫在返回給會話事務成功之前提交事務的方式。

該參數有兩個值：

• AFTER_COMMIT（5.6默認值）

master將每個事務寫入binlog ,傳遞到slave 刷新到磁碟(relay log)，同時主庫提交事務。master等待slave 反饋收到relay log，只有收到ACK後master才將commit OK結果反饋給客戶端。

• AFTER_SYNC（5.7默認值，但5.6中無此模式）

master 將每個事務寫入binlog , 傳遞到slave 刷新到磁碟(relay log)。master等待slave 反饋接收到relay log的ack之後，再提交事務並且返回commit OK結果給客戶端。即使主庫crash，所有在主庫上已經提交的事務都能保證已經同步到slave的relay log中。

因此5.7引入了after_sync模式，帶來的主要收益是解決after_commit導致的master crash主從間數據不一致問題，因此在引入after_sync模式後，所有提交的數據已經都被復制，故障切換時數據一致性將得到提升。

• 2 性能提升支持發送binlog和接受ack的非同步化

舊版本的semi sync 受限於mp thread ，原因是mp thread 承擔了兩份不同且又十分頻繁的任務：傳送binlog 給slave ，還需要等待slave反饋信息，而且這兩個任務是串列的，mp thread 必須等待 slave 返回之後才會傳送下一個 events 事務。mp thread 已然成為整個半同步提高性能的瓶頸。在高並發業務場景下，這樣的機制會影響資料庫整體的TPS .

• 圖：Without ACK receiving thread

為了解決上述問題，在5.7版本的semi sync 框架中，獨立出一個 ack collector thread ，專門用於接收slave 的反饋信息。這樣master 上有兩個線程獨立工作，可以同時發送binlog 到slave ，和接收slave的反饋。

• 圖：With ACK receiving thread3 性能提升控制主庫接收slave 寫事務成功反饋數量

MySQL 5.7新增了rpl_semi_sync_master_wait_slave_count參數，可以用來控制主庫接受多少個slave寫事務成功反饋，給高可用架構切換提供了靈活性。

• 如圖所示，當count值為2時，master需等待兩個slave的ack

4 性能提升

• Binlog 互斥鎖改進

舊版本半同步復制在主提交binlog的寫會話和mp thread讀binlog的操作都會對binlog添加互斥鎖，導致binlog文件的讀寫是串列化的，存在並發度的問題。

• MySQL 5.7對binlog lock進行了以下兩方面優化

1.移除了mp thread對binlog的互斥鎖

2.加入了安全邊際保證binlog的讀安全

• 5 性能提升組提交

5.7引入了新的變數slave-parallel-type，其可以配置的值有：

• DATABASE （5.7之前默認值），基於庫的並行復制方式；LOGICAL_CLOCK （5.7新增值），基於組提交的並行復制方式；

MySQL 5.6版本也支持所謂的並行復制，但是其並行只是基於DATABASE的，也就是基於庫的。如果用戶的MySQL資料庫實例中存在多個DATABASE ，對於從機復制的速度的確可以有比較大的幫助，如果用戶實例僅有一個庫，那麼就無法實現並行回放，甚至性能會比原來的單線程更差。

MySQL5.7中增加了一種新的並行模式：為同時進入COMMIT階段的事務分配相同的序列號，這些擁有相同序列號的事務在備庫是可以並發執行的。

MySQL 5.7真正實現的並行復制，這其中最為主要的原因就是slave伺服器的回放與主機是一致的即master伺服器上是怎麼並行執行的slave上就怎樣進行並行回放。不再有庫的並行復制限制，對於二進制日誌格式也無特殊的要求（基於庫的並行復制也沒有要求）。

因此下面的序列中可以並發的序列為（其中前面一個數字為last_committed ，後面一個數字為sequence_number ）：

• trx1 1…..2trx2 1………….3trx3 1…………………….4trx4 2……………………….5trx5 3…………………………..6trx6 3………………………………7trx7 6………………………………..8

備庫並行規則：當分發一個事務時，其last_committed 序列號比當前正在執行的事務的最小sequence_number要小時，則允許執行。

• 因此，

a)trx1執行，last_commit<2的可並發，trx2, trx3可繼續分發執行

b)trx1執行完成後，last_commit < 3的可以執行， trx4可分發

c)trx2執行完成後，last_commit< 4的可以執行， trx5, trx6可分發

d)trx3、trx4、trx5完成後，last_commit < 7的可以執行，trx7可分發

• 綜上所述

我們認為MySQL 5.7版對Loss-Less半同步復制技術的優化，使得其成熟度和執行效率都得到了質的提高。我們建議在使用MySQL 5.7作為生產環境的部署時，可以使用半同步技術作為高可用與讀寫分離方案的數據復制方案。

B. AAC幣出了啥問題

18號上午，銳角雲要實施六條舉措來提振幣價，不過當天只放出兩條舉措，一是31000台三角形主機（1代）將作為銳角雲唯一創世節點；二是Super Network（酸奶計劃）激活碼銷售所回收AAC進行1年期鎖倉。被AAC套牢半年多了，以往AAC客服是「行情還是要交由市場滴balabala」，但這次不按常規出牌就忍不住想分析一下。
1、 為什麼好好的一個項目幣價跌成這樣？
很早之前看過一篇對如下代碼審計結果出來前後5天不同等級項目幣價漲幅分析的文章在良好等級的項目中選取了ETH、EOS、Qtum、AE和SNT，平均漲幅165.98%；一般項目中NEO、BTS、阿希（XAS）、天算（Delphy）、公信寶（GXS）的平均漲幅135.62%；等級為差以及未找到的的項目除去飛上天的波場（TRX），TNT、UIP、唯鏈（VEN）、PAY的平均漲幅為107%。看出等級越高的項目，幣價的漲幅也越大，從這一方面可以說幣價跟項目的好壞還是有一定關系的，畢竟幣價還受很多因素的綜合影響。
再來看AAC，一家區塊鏈研究和評級機構SharpRating之前對銳角雲項目做過一次評級，最終結果為86.45分A-級，暫且不說這家評級機構的權威性以及這篇評級是否含有水分，按照這個評級來看，AAC的幣價更是讓人不解。
2、三角形主機漲價，獲取收益少，回本無望？
三角形主機在最開始投放於市場時，平均每台三角形主機的收益超過100AAC，當時幣價6、7毛。但隨著三角形主機節點的不斷增多，目前每台三角形主機的收益大概在20AAC左右，而幣價為2毛浮動。三角形主機的價格不斷的上漲，但是幣價一直跌，這是要用戶們挖到地老天荒也回不了本的節奏嗎？雖然目前銳角雲推出Supper Network酸奶計劃能夠獲取SN獎勵，但是用戶在對項目產品、幣價都不看好的情況下，用戶對酸奶計劃的熱情也受打擊。
3、為什麼要提升幣價？增長用戶對項目的信心？
一個品牌想要建立自己的品牌效應，就要給用戶提供優質的產品和服務，這樣用戶自然會回饋給項目方相應的回報，才更容易建立起用戶對品牌的信任。在幣圈更是如此，想讓用戶信任項目，首先讓用戶感受到項目能帶給他的好處。在銳角雲整個生態完成之前，幣價是最能夠給用戶帶來直觀感受的，讓用戶感受到項目對他們的用心，讓用戶對項目產生好感而不是整天的謾罵，是能夠建立起用戶對項目的信心的基礎。

C. 如何計算愛立信開EDGE傳輸

EDGE的開通按照逐站逐小區進行開通，下面是細化的操作指令和流程：
1．停用小區，MO退服
RLSTC:CELL=cell,STATE=HALTED;
RXBLI:MO=RXOTG-tg,SUBORD,FORCE;
RXESE:MO=RXOTG-tg,SUBORD;

2．啟用EGPRS的小區需配置2個CHGR，一個CHGR（一般CHGR＝0）為原來的載波（不啟用EGPRS的TRU），另一個CHGR（一般CHGR＝1，）為支持及要開啟EGPRS的TRU。
RLDGI:CELL=cell,CHGR=1;
RXTCI：MO=RXOTG-tg,CELL＝cell，CHGR＝1；

3．分配EGPRS頻點
RLCFP:CELL=cell;
RLCFE:CELL=cell,CHGR=0,DCHNO=dchno;
RLCFI:CELL=cell,CHGR=1,DCHNO=dchno;

4．配置小區開啟EGPRS的BPC數量
RLBDC:CELL=cell,CHGR=1,NUMREQEGPRSBPC=8；
RLBDC:CELL=cell,CHGR=0,TN7BCCH=EGPRS;
(根據該小區數據業務流量，設置支持64K的EGPRS信道的數量，可以定義的范圍為0-128,主要是看連接做EDGE的載波數量，按綿陽當地情況一般是4到8);

5．給小區分配固定PDCH
RLGSC:CELL=cell,FPDCH=1,PSKONBCCH=ENABLED;

6．重新配置MO參數
A、 RXMOC：MO＝RXOTG－tg,SVWER=svwer;
基站類型 SVWER
RBS2202 B3991R004F
RBS2206 B1922R002U
RBS2308 B1922R002U

B、重新定義啟用EGPRS的sTRU/dTRUe數據
RXMOC:MO=RXOTRX-tg-trx,DCP1=dcp1,DCP2=dcp2,SIG=UNCONC;
RXMOC:MO=RXOTRX-tg-trx,CELL=cell,CHGR=1;
RXMOC:MO=RXOTX-tg-tx,CELL=cell,CHGR=1;
啟用EGPRS的RXOTRX所連接的DCP1、DCP2的對應關系如下：
TRX DCP1 DCP2
TRX-tg-0 178 179&&186
TRX-tg-1 187 188&&195
TRX-tg-2 196 197&&204
TRX-tg-3 205 206&&213
TRX-tg-4 214 215&&222
TRX-tg-5 223 224&&231
TRX-tg-6 232 233&&240
TRX-tg-7 241 242&&249
TRX-tg-8 250 251&&258
TRX-tg-9 259 260&&267
TRX-tg-10 268 269&&276
TRX-tg-11 277 278&&285

以主機架的第6個載波為例:
RXMOC:MO=RXOTRX-tg-5,DCP1=223,DCP2=224＆＆231,SIG=UNCONC;
RXMOC:MO=RXOTRX-tg-5,CELL=cell,CHGR=1;
RXMOC：MO＝RXOTX-tg-5,CELL=cell,CHGR=1;

C、重新定義ABIS介面
如：RXAPE:MO=RXOTG-tg,DCP=RBLT-rblt1&&-rblt8（1個載波8個，兩個載波就16個）;
RXAPI:MO=RXOTG-rxotg,DEV=RBLT-rblt1&&-rblt8,DCP=1&&8,RES64K;
注意：根據啟用EGPRS的NUMREQEGPRSBPC的數量，定義支持64K的RBLT的數量。如NUMREQEGPRSBPC＝8，表示定義8個支持64K RBLT的。

D、裝載MO軟體及解閉MO
RXESI:MO=RXOTG-tg,SUBORD;
RXBLE:MO=RXOTG-tg,SUBORD;

E、激活小區
RLSTC:CELL=cell,STATE=ACTIVE;

F、檢查小區狀態
RXCDP:MO=RXOTG-tg;
RLCRP:CELL=cell;
RLGRP:CELL=cell;

D. 本人想用2萬組裝一台主機（註：2萬都用在主機），用什麼配置好

CPU 酷睿i7 3930K 4399元
散熱器 酷冷至尊 海神 CPU水冷散熱器 399元
主板 微星 X79A-GD45 PLUS主板 2099元
內存 芝奇 DDR3 1600 4G*4 796元
顯卡 技嘉 GV-N780OC-3GD 5399元
固態硬碟 金士頓 HyperX 240G*2 3198元
硬碟 希捷 3TB ST3000DM001 899元
電源 安鈦克 NEO ECO 620 額定620W 459元
機箱與機箱散熱器 任選 1052元以內
總計 18700元

上面這套配置還只是個大概方向，具體配置仍然需要討論哦。

若還有疑問歡迎追問~

E. trx1320離心空壓機跳閘是什麼原因

您好，空氣壓縮機是工業現代化的基礎產品，常說的電氣與自動化里就有全氣動的含義；而空氣壓縮機就是提供氣源動力，是氣動系統的核心設備機電引氣源裝置中的主體，它是將原動（通常是電動機）的機械能轉換成氣體壓力能的裝置，是壓縮空氣的氣壓發生裝置。

發生跳閘的原因有以下幾點：
1 由於空壓機的啟動電流比較大，電源開關整定電流比較小，沒有躲開電機的啟動電流；
2 電動機有故障接地或者相間故障短路情況；
3.空壓機溫度過高，也會引起跳閘；
4.主機運轉不順暢（由於環境差保養不到位或軸承問題引起）；
6.檢查空壓機潤滑油位。
山東宏潤很高興為您解答。

F. mysql半同步復制適合哪些業務場景

說實話 這個問題 很難回答

同步復制，犧牲很多性能。slave 需要等待master處理結束 不阻塞情況。
非同步性能好，但是不等待master處理結束，不保證數據完整
半同步介於兩者之間。數據可靠性很好，但是略微犧牲性能。

業務場景。。。。 看你資料庫伺服器多屌咯。都能廣泛運用於各種場景。

如果硬要說的話，半同步復制，個人認為不適合大流量高失敗請求的網路游戲數據儲存。更適合流量一般的 非持續性的數據更替吧。比如，網商，網路訂單？

PS:絕不是安利。以前我自己搭建資料庫伺服器。後來維護麻煩，直接用了阿x雲的rds。再無煩惱。用少量金錢解決的大問題。。。。 何必自己辛苦

G. 主板有必要買貴的嗎

主板是電腦整機中能中最核心的位置，CPU、內存、顯卡等都是直接安插在主板上的，都通過主板來進行數據交互，主板就是一台電腦主機的承載體，但是主板到底有什麼作用呢，影響電腦主機什麼？
首主板是一個電腦的基礎，主板的用料和核心技術將影響電腦的穩定發揮、兼容性、游戲的流暢性，一塊好的主板能夠擁有更強悍的超頻能力以及穩定的運行能力。例如，主板就好比一條公路，而CPU等硬體就好比是一台汽車系統，好主板提供平坦的高速公路，如果一輛帕拉梅拉選擇在山路上開，也是不能發揮出全部性能，車是好車，但是路不行，所以要選好車，走好路，速度才能快，主板也是這個道理。
為了保障CPU的基本頻率，所以好的主板才夠更好的駕馭。現在非常火爆的32核64線程的AMD銳龍Threadripper 3970X處理器，採用了7nm工藝以及Zen 2架構，性能也是強悍，但是這么一顆強大的CPU需要什麼樣的主板才能駕馭呢？
華碩ROG STRIX TRX40-EGAMING主板

一款好的主板有哪些特點？主板的做工以及用料很扎實，為主板提供強有力的基礎，還能夠提供優秀的供電設計，加持高效率的散熱方案，除此之外，就是在介面方面非常的豐富，具有強大的擴展性。

AMD銳龍Threadripper 3970X處理器作為一顆高端的處理器，需要強大的供電輸入，需要主板要有非常好的表現，華碩在3970X處理器發布後的第一時間上新了TRX40系列主板，TRX40系列的三款主板產品，分別是ZENITH II EXTREME主板、ROG STRIX TRX40-E GAMING主板、Prime TRX40-Pro主板，華碩TRX40系列主板都都支持8條DDR4內存和PCIe 4.0和Wi-Fi 6技術以及16相伺服器級供電。

H. 求高手給個8000左右的主機配置！只要主機！要求多開3d網游不卡！速度快穩定！

樓主：8K以下配置供參考，CPU如是喜愛i7 換上取代i5便是：
CPU: 英特爾(Intel)22納米 酷睿i5 3450盒裝 ￥1299
(散熱器 ：超頻三 黃海豪華版 S90F ￥98)
主板：華碩(ASUS)P8H77-V 主板 ￥799
或：微星（msi）ZH77A-G43主板 ￥699
內存：芝奇 DDR3 1600 8G 套裝（2×4GB) ￥269
硬碟：希捷（Seagate）1TB ST1000DM003 7200轉64M SATA 6Gb/秒 ￥559
固態硬碟：美光（Crucial）M4系列 64G SATA-3 ￥499
顯卡：技嘉 GV-N670OC-2GD 980MHz/6008MHz 2048MB/256bit GDDR5 ￥3299
（或: 微星（MSI）N660Ti OC 1019/6008MHz 2G/192bits GDDR5 ￥2399）
電源：台達 NX450 電源 額定450W/80Plus銅牌 ￥349
或：全漢 黑騎士RA450 額定450W/80Plus銅牌 ￥299
機箱：先馬 刺客1 中塔游戲機箱（電源下置/支持SSD/背板走線） ￥169
整機大約7300元左右。（配置報價參考10月8日京東）

I. 哪位老哥能給我配一套最牛逼的組裝機，不要外設，不要顯示屏，就只要一台最牛逼的組裝主機

cpu：3990x 29999

主板：敗家眼trx40 ROG ZENITH EXTREME ALPHA 7000

散熱：定製分體水 10000

內存：海盜船統治者4800 16gx8 20000
硬碟：三星970 EVO Plus 2t10個 30000 加pcix8轉8個m.2介面 英特爾p4600 6. 4t4個加pcie拓展一轉4 120000 sata3.0一轉12 郎存960gb12個 2400000
顯卡 rtx8000兩個 150000 交火線1500
網卡 華三企業級萬兆 8800
音效卡 華碩老虎 2000
機箱 迎廣z-Tower 40000
電源 振華2000w 水冷白金全模 分開供電 10000 銀芯的定製線 2000
總價：2831299
只要你敢問，我就敢說，奧利給造他就完了。

J. 強同步復制模式半同步復制模式哪個好

從mysql5.5開始，支持半同步模式復制(semisynchronous replication)，比之前的非同步模式復制增強了安全性。
半同步復制模式可以確保至少有一個備節點伺服器在接受完主伺服器發送的binlog日誌文件並寫入到中繼日誌後，返回給主節點一個ack信號，告訴主節點已經接收完日誌，這時主節點線程才返回給當前session提交信息。
當主節點因為超時未接收到任一個備節點的ack信號時會切換會非同步復制模式，從而防止堵塞應用。
當至少有一個備節點返回給主節點ack信號時，主節點切換回半同步復制模式。
主備節點必須全部配置成半同步復制模式，否則不支持該模式。
mysql 的半同步復制是通過安裝插件來實現的，主備節點安裝相應的插件，否則無法實現半同步復制。
已安裝二進制包的默認插件目錄在/usr/lib/mysql/plugin中。開啟半同步復制模式如下：

1.在主節點中運行
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
2.在每個備節點中運行
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
3.在主節點中運行
mysql> SET GLOBAL rpl_semi_sync_master_enabled = 1;
mysql> SET GLOBAL rpl_semi_sync_master_timeout = 10000;
4.在備節點中運行
mysql> SET GLOBAL rpl_semi_sync_slave_enabled = 1;
mysql> STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
5.在主節點中配置文件/etc/my.cnf添加
rpl_semi_sync_master_enabled=1
rpl_semi_sync_master_timeout =10000 (默認為10000毫秒，可不更改)
6.在備節點中配置文件/etc/my.cnf添加
rpl_semi_sync_slave_enabled=1
7.查看主節點狀態確認半同步復制模式打開

Rpl_semi_sync_master_clients 大於0表示有備機以半同步模式連接到主節點。

備注(單位微秒)：
Rpl_semi_sync_master_clients
半同步連接的slave數目
Rpl_semi_sync_master_net_avg_wait_time
主節點等待備節點同步的平均時間
Rpl_semi_sync_master_net_wait_time
主節點等待備節點同步的總時間
Rpl_semi_sync_master_net_waits
主節點等待次數
Rpl_semi_sync_master_no_times
主節點關閉半同步的次數
Rpl_semi_sync_master_no_tx
主節點未收到ack返回信號的次數
Rpl_semi_sync_master_status
半同步主節點狀態(當為主節點的時候為ON)
Rpl_semi_sync_master_timefunc_failures
半同步由於調用時間函數錯誤的次數
Rpl_semi_sync_master_tx_avg_wait_time
半同步主節點等待一個事務的平均等待時間
Rpl_semi_sync_master_tx_wait_time
主節點等待事務完成的總等待時間
Rpl_semi_sync_master_tx_waits
主節點等待事務完成的總次數
Rpl_semi_sync_master_wait_pos_backtraverse
等待備節點事務應用的順序同主節點日誌寫入順序不一致
Rpl_semi_sync_master_wait_sessions
主節點等待的回話次數
Rpl_semi_sync_master_yes_tx
成功完成半同步的事務總次數
Rpl_semi_sync_slave_status
半同步備節點狀態(當為備節點的時候為ON)