mysql雙主配置-雙主帶來的管理思考

mysql雙主配置很簡單，似乎大家都只關(guān)心他的安裝和部署，大家可以用他來做雙活的方案，并沒有深刻的思考過生產(chǎn)環(huán)境后續(xù)管理的風(fēng)險(xiǎn)和如何規(guī)避這些問題。

創(chuàng)新互聯(lián)是專業(yè)的蒲縣網(wǎng)站建設(shè)公司，蒲縣接單;提供做網(wǎng)站、成都做網(wǎng)站,網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行蒲縣網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!

log-slave-updates = true

auto_increment_offset = 1 #另外一個(gè)主B是2，其他一樣。

auto_increment_increment = 2

replicate-ignore-db = mysql

replicate-ignore-db = sys

replicate-ignore-db = information_schema

replicate-ignore-db = performance_schema

replicate-ignore-db = undolog

replicate_wild_ignore_table = mysql.%

replicate_wild_ignore_table = sys.%

replicate_wild_ignore_table = information_schema.%

replicate_wild_ignore_table = performance_schema.%

replicate_wild_ignore_table = undolog.%

雙主如果一邊更新表結(jié)構(gòu)，一邊在寫入，即使你認(rèn)為你的的sql沒有問題。但是mysqlbinlog的寫入日志不是這樣的，比如row格式，需要回放的日志如下下面，你修改表結(jié)構(gòu)之前是可以插入的，中間查多一列的話，你的列對(duì)不上了，導(dǎo)致1167錯(cuò)誤。目前有兩種辦法可以規(guī)避這個(gè)問題：

如果忽略了一些庫，比如mysql的庫，創(chuàng)建賬號(hào)的時(shí)候，就需要兩邊創(chuàng)建。

技術(shù)選型，mysql和pg怎么選

主要是數(shù)據(jù)中心的同步問題,一般雙活都要跨機(jī)房、跨城市。數(shù)據(jù)同步是大問題。 而且現(xiàn)在也沒有幾家公司的mysql集群是雙活架構(gòu)

3.雙活問題收集

2.問題列表

問題提出者進(jìn)度結(jié)論備注

問題提出者進(jìn)度結(jié)論備注

中臺(tái)只需要業(yè)務(wù)支持還是存儲(chǔ)也要部署HNC 汪曉明 待討論專項(xiàng)：核心鏈路梳理

兩輪車hnc雙活對(duì)成本的要求是如何的 王勇 已完成

兩輪車線上部署方案以及打包腳本改造 圓圓 待討論專項(xiàng)：核心鏈路梳理

兩輪車所有外部服務(wù)+接口依賴梳理 圓圓 待討論專項(xiàng)：核心鏈路梳理

備機(jī)房如果只保證主鏈路，如何降低業(yè)務(wù)開發(fā)人員的感知和復(fù)雜度 田玉磊 已完成業(yè)務(wù)無感知應(yīng)是基本原則。

Api Router目前如何工作已完成衛(wèi)民已做解答

TCP和IOT層是否要做雙機(jī)房 田玉磊 已完成至少第一階段不會(huì)雙活 彭帝 ?判斷

本機(jī)房優(yōu)先的路由策略(如何判斷是本機(jī)房服務(wù)，如何控制權(quán)重) 陳鵬志 需改造路由需要改造，

權(quán)重可以通過按照城市維度控制粒度

專項(xiàng)：dubbo雙活方案

跨機(jī)房部署是否有獨(dú)立的注冊中心，zk是否會(huì)成為服務(wù)規(guī)模瓶頸 陳鵬志 已完成僅僅用作服務(wù)發(fā)現(xiàn)，不會(huì)影響性能。專項(xiàng)：ZK雙活方案

KOP支持多注冊中心下 陳鵬志 需改造專項(xiàng)：dubbo雙活方案

DBProxy是否有現(xiàn)成的多機(jī)房方案 陳鵬志 需改造專項(xiàng)：DB雙活方案

多機(jī)房網(wǎng)絡(luò)是否經(jīng)過NAT映射 陳鵬志 已完成沒有

同城雙活目標(biāo)，原則 侯云飛 已完成穩(wěn)定性O(shè)KR（ 服務(wù)端 ）決定目標(biāo)

確定主鏈路，主鏈路和非主鏈路之間是否可以解耦降級(jí) 侯云飛 需改造

互聯(lián)網(wǎng)流量如何打到多個(gè)機(jī)房，支持哪些策略 侯云飛 已完成衛(wèi)民已解答

機(jī)房收到流量后，路由到LA上，LA采用什么技術(shù) 侯云飛 已完成衛(wèi)民已解答

zk集群每個(gè)機(jī)房一套，在部署時(shí)，如何保證服務(wù)配置在不同機(jī)房路由到不同zk集群 侯云飛 專項(xiàng)：打包部署方案

DDMQ同一名稱的隊(duì)列如果是多機(jī)房多實(shí)例，那么當(dāng)某一機(jī)房故障時(shí)，會(huì)損失一部分消息，是否可接受 侯云飛

mysql、gift、codis、mongo、kschedual雙活 侯云飛 需改造

有些服務(wù)甚至依賴hbase，是否需要雙活 侯云飛 需改造專項(xiàng)：核心鏈路梳理

請(qǐng)求路由sharding方案，并不是所有接口都有城市ID，是否有多套 吳文豪 需改造專項(xiàng)：路由策略

一旦鏈路上存在未雙活服務(wù)，存在跨機(jī)房調(diào)用，耗時(shí)不可控，也達(dá)不到同機(jī)房閉環(huán)的初衷 吳文豪 已完成同城雙活，跨機(jī)房調(diào)用RT增加1~2ms，不影響用戶體驗(yàn)

業(yè)務(wù)調(diào)用中臺(tái)，中臺(tái)回調(diào)業(yè)務(wù)地址是VIP，運(yùn)維層面能不能做到指定，還是需要改造 吳文豪 需改造專項(xiàng)：路由策略

MQ是否已經(jīng)存在跨機(jī)房，這部分如何處理 吳文豪 需改造專項(xiàng)：MQ雙活方案

業(yè)務(wù)方需要在切換機(jī)房時(shí)主動(dòng)切換dbproxy的vip 田玉磊 已完成不同機(jī)房會(huì)有不同配置

機(jī)房故障到切換主庫之間，會(huì)有短暫的服務(wù)無法寫入的情況，如何保證數(shù)據(jù)的強(qiáng)一致性？ 田玉磊 需改造專項(xiàng)：DB雙活方案

dubbo如果部署雙活注冊中心，需要使用多活服務(wù)的消費(fèi)者必須重新配置上線，

將來多活時(shí)還要調(diào)整，這雖然和我們的原則沖突，應(yīng)該可以接受

侯云飛 需改造專項(xiàng)：Dubbo雙活方案

分庫分表技術(shù)及技術(shù)方案

一、分庫分表的必要性

分庫分表技術(shù)的使用，主要是數(shù)據(jù)庫產(chǎn)生了瓶頸，如單庫的并發(fā)訪問或單表的查詢都超出了閾值。對(duì)系統(tǒng)使用造成一定的影響，不得已而產(chǎn)生的技術(shù)。

通過分庫分表技術(shù)來解決此類問題，但正因?yàn)槭褂么思夹g(shù)，會(huì)產(chǎn)生ACID一系列的問題，各類中間件解決此類問題各有各的優(yōu)勢。

提示：如場景無必要，千萬不要使用分庫分表。

二、分庫分表的思路

1、垂直區(qū)分

垂直分庫：從業(yè)務(wù)角度，一個(gè)庫分成多個(gè)庫，如把訂單和用戶信息分成兩個(gè)庫來存儲(chǔ)。這樣的好處就是可以微服務(wù)了。每塊的業(yè)務(wù)單獨(dú)部署，互不影響，通過接口去調(diào)用。

垂直分表：把大表分成多個(gè)小表，如熱點(diǎn)數(shù)據(jù)和非熱點(diǎn)數(shù)據(jù)分開，提高查詢速度。

2、水平區(qū)分

水平分表：同一業(yè)務(wù)如數(shù)據(jù)量大了以后，根據(jù)一定的規(guī)則分為不同的表進(jìn)行存儲(chǔ)。

水平分庫：如訂單分成多個(gè)庫存儲(chǔ)，分解服務(wù)器壓力。

以上一般來說，垂直分庫和水平分表用的會(huì)多些。

三、分庫分表的原理分析

分庫分表常用的方案：Hash取模方案和range范圍方案；

路由算法為最主要的算法，指得是把路由的Key按照指定的算法進(jìn)行存放；

1、Hash取模方案

根據(jù)取余分配到不同的表里。要根據(jù)實(shí)際情況確認(rèn)模的大小。此方案由于平均分配，不存在熱點(diǎn)問題，但數(shù)據(jù)遷移很復(fù)雜。

2、Range范圍方案

range根據(jù)范圍進(jìn)行劃分，如日期，大小。此方案不存在數(shù)據(jù)遷移，但存在熱點(diǎn)問題。

四、分庫分表的技術(shù)選型

1、技術(shù)選型

解決方案主要分為4種：MySQL的分區(qū)技術(shù)、NoSql、NewSQL、MySQL的分庫分表。

（1）mysql分區(qū)技術(shù)：把一張表存放在不同存儲(chǔ)文件。由于無法負(fù)載，使用較少。

（2）NoSQL（如MongoDB）：如是訂單等比較重要數(shù)據(jù)，強(qiáng)關(guān)聯(lián)關(guān)系，需約束一致性，不太適應(yīng)。

（3）NewSql(具有NoSQL對(duì)海量數(shù)據(jù)的存儲(chǔ)管理能力，還保持了傳統(tǒng)數(shù)據(jù)庫支持ACID和SQL等特性):如TiDB可滿足需求。

（4）MySQL的分庫分表：如使用mysql,此種方案為主流方式。

2、中間件

解決此類問題的中間件主要為：Proxy模式、Client模式。

（1）Proxy模式

（2）Client模式

把分庫分表相關(guān)邏輯存放在客戶端，一版客戶端的應(yīng)用會(huì)引用一個(gè)jar，然后再jar中處理SQL組合、數(shù)據(jù)庫路由、執(zhí)行結(jié)果合并等相關(guān)功能。

（3）中間件的比較

由于Client模式少了一層，運(yùn)維方便，相對(duì)來說容易些。

五、分庫分表的實(shí)踐

根據(jù)容量（當(dāng)前容量和增長量）評(píng)估分庫或分表個(gè)數(shù) - 選key（均勻）- 分表規(guī)則（hash或range等）- 執(zhí)行（一般雙寫）- 擴(kuò)容問題（盡量減少數(shù)據(jù)的移動(dòng)）。

在這里我們選用中間件share-jdbc。

1、引入maven依賴

2、spring boot規(guī)則配置

行表達(dá)式標(biāo)識(shí)符可以使用${...}或$-{...}，但前者與Spring本身的屬性文件占位符沖突，因此在Spring環(huán)境中使用行表達(dá)式標(biāo)識(shí)符建議使用$-{...}。

3、創(chuàng)建DataSource

通過ShardingDataSourceFactory工廠和規(guī)則配置對(duì)象獲取ShardingDataSource，ShardingDataSource實(shí)現(xiàn)自JDBC的標(biāo)準(zhǔn)接口DataSource。然后即可通過DataSource選擇使用原生JDBC開發(fā)，或者使用JPA, MyBatis等ORM工具。