mysql集群和主從區(qū)別？mysql中集群和主從的區(qū)別：主從之間是是從mysql的replication來保證數(shù)據(jù)的一致性；相對于mysql集群的數(shù)據(jù)同步來講是異步模式的。是因?yàn)楫惒?，因?yàn)橹鲝闹g不能

mysql集群和主從區(qū)別？

mysql中集群和主從的區(qū)別：主從之間是是從mysql的replication來保證數(shù)據(jù)的一致性；相對于mysql集群的數(shù)據(jù)同步來講是異步模式的。是因?yàn)楫惒?，因?yàn)橹鲝闹g不能復(fù)制數(shù)據(jù)很可能會(huì)有一點(diǎn)微小的延時(shí)，是會(huì)直接出現(xiàn)不一致。

主從可以可以保證讀寫分離，即寫能操作在master，讀操作在slave，主從模式也有多個(gè)，這里只說一主多從。

.例如有兩個(gè)業(yè)務(wù)模塊，一個(gè)斷的寫入訂單記錄等，兩個(gè)模塊則是生成報(bào)表，這時(shí)如果沒有不采用讀寫分離，讀寫操作碰一起，可能會(huì)不可能發(fā)生，影響性能，如果沒有主從復(fù)制，則不用什么考慮讀寫同一張表最大限度地影響不大性能，不過多從可以不挺好的的分?jǐn)偡?wù)器的壓力，減低單臺(tái)機(jī)器的壓力。

集群大的的優(yōu)點(diǎn)應(yīng)該是同步數(shù)據(jù)，高可用，每個(gè)節(jié)點(diǎn)的數(shù)據(jù)都是歌詞同步不對的，不像主從，有時(shí)會(huì)再次出現(xiàn)數(shù)據(jù)不一致，而高可用，任何一個(gè)節(jié)點(diǎn)宕機(jī)都肯定不會(huì)影響大業(yè)務(wù)。

但缺點(diǎn)是性能，寫的性能，有時(shí)候?qū)懩懿僮鳎紩?huì)在所有節(jié)點(diǎn)之間通過同步，有失有得，死傷了一點(diǎn)性能，絕對的保證了高可用和數(shù)據(jù)相同。

主從同步一次需要多長時(shí)間？

基本都都是實(shí)時(shí)發(fā)送，主庫數(shù)據(jù)調(diào)整后立即再通知從庫陸續(xù)更新數(shù)據(jù)。

redis主從復(fù)制的延時(shí)怎么處理？

應(yīng)用Redis實(shí)現(xiàn)方法數(shù)據(jù)的讀寫，同樣的借用隊(duì)列處理器每隔幾小時(shí)將數(shù)據(jù)寫入到mysql。

同樣要特別注意避免，在redis起動(dòng)時(shí)去mysql加載所有表鍵值存進(jìn)redis中，往redis寫數(shù)據(jù)時(shí)，對redis主鍵自增并進(jìn)行讀取，若mysql自動(dòng)更新我失敗了，則不需要一定要及時(shí)清除干凈緩存及歌詞同步redis主鍵

mysql的主從復(fù)制會(huì)影響事務(wù)嗎？

絕對不會(huì)的。mysql的主從復(fù)制肯定不會(huì)影響事務(wù)。

而且，主從復(fù)制的原理是:

數(shù)據(jù)庫將用戶的請求通過工作線程來將數(shù)據(jù)中寫入到數(shù)據(jù)庫中后再在中寫入到binlog日志中。

binlog日志詳盡記錄了數(shù)據(jù)的操作信息。

主數(shù)據(jù)庫會(huì)有一個(gè)IO線程將binlog日志中的數(shù)據(jù)同步到從數(shù)據(jù)庫的relay日志中。

從數(shù)據(jù)庫再實(shí)際自己數(shù)據(jù)庫內(nèi)的SQL線程將relaylog日志中的數(shù)據(jù)寫入到到數(shù)據(jù)庫中。

同步JK觸發(fā)器和主從JK觸發(fā)器的區(qū)別，他們的真值表好像是一樣的吧？

邏輯功能全是一樣的,比較多體現(xiàn)在真值表上.兩者區(qū)別只在于觸發(fā)時(shí)時(shí)刻的不同,主從觸發(fā)器必然兩步,后來的輸出翻轉(zhuǎn)在脈沖波逐漸下降沿.但是未知主觸發(fā)器三次翻轉(zhuǎn)特性,同步不未知這個(gè)現(xiàn)象.