Mariadb master/slave -> primary/replica

在Master端所有資料庫的變更(包括DML和DDL)都會以Binlog Event 的方式寫入Binlog中。Slave會連上Master然後讀取Binlog Event,再重放這些操作到自身的資料中。一個DB Server可以既是Master同時又是Slave,做成雙向複製。也可以一級一級串聯,做成級聯複製,Binlog Event 中包含的server_id 可以識別產生Event 的DB Server,避免重複執行。

master/slave (replication)

graph TD Master[Master] Slave[Slave] Master --> Slave

master/master (galera cluster)

graph TD Master1[Master1] Master2[Master2] Master1 --> Master2 Master2 --> Master1

Slave會保存最後一次收到和應用的Binlog的位置,因此Slave重連Master時可以從中斷的位置繼續開始復制。也可以在暫停Slave後,將其整體拷貝到新的位置,然後作為一個新的Slave繼續複製。

GTID (Global transaction ID,GTID)

全局事務ID為每個Event Group (就是一系列Event 組成的一個原子單元,要麼一起提交要麼都無法提交)引入了一個標識,因此GTID 是標識“事務”的最佳方式(儘管Event 裡面還包含一些非事務的DML語句和DDL,它們可以作為一個單獨的Event Group )。每當一個Event Group 從Master複製到Slave時,它的GTID 也通過GTID Event 被傳到Slave。因為每個GTID 在整個複制拓撲結構中都是一個唯一標誌,所以這使得在不同的DB Server之間識別相同的Binlog Events 非常簡單,然而在有GTID 之前,想做到這點是很困難的。MariaDB 從10.0.2 開始提供GTID 支持,但是MariaDB 的GTID 與MySQL 的GTID 在實現原理上並不相同。


Mysql/Mariadb 同步原理簡述:

1.Master 所有資料庫變更寫進 Binary Log, 主庫執行緒 Binlog Dump 把 Binary Log 內容傳送到從庫 Slave 上(Slave 被動接受資料,不是主動去獲取)。

2.Slave I/O 執行緒讀取 Master 上 Binary Log 日誌資訊,把接受到的 Binary Log 日誌寫到本地中繼日誌 Relay Log

3.Slave Sql 執行緒讀取 Ralay Log 日誌內容寫入本地資料庫例項

Example

我的兩個兒子共享一個房間,並且我們對每個玩具屬於誰以及誰可以玩這些玩具採用顏色代碼系統。帶有黃色圓點的玩具屬於Darren,而帶有綠色圓點的玩具屬於Jimpop。當我派他們打掃房間時,他們會根據該玩具上唯一的顏色代碼知道負責清理哪些玩具。

就像I/O線程如何知道主二進制日誌中的各個條目中的哪個條目與其複制DB Server相關聯。二進制日誌條目可以是隨機的,即不是線性的,就像所有玩具在隱喻中分佈在整個臥室中一樣,但是I/O線程可以告訴哪個條目與其DB Server相關聯。

Mariadb: DomainID-ServerID-TransactionID

0-1-1

MySQL: Source_ID-Transaction_ID

0-1

MySQL 多源複製需要5.7版本在 my.conf 中設定

多源複製 是不同的DB Server複製到同一個DB Server

DDL (Data Definition Language)


CREATE - to create objects in the database

ALTER - alters the structure of the database

DROP - delete objects from the database

TRUNCATE - remove all records from a table, including all spaces allocated for the records are removed

COMMENT - add comments to the data dictionary

RENAME - rename an object

DML (Data Manipulation Language)


SELECT - retrieve data from the a database (也有說select是DRL: Data Retrieval Language)

INSERT - insert data into a table

UPDATE - updates existing data within a table

DELETE - deletes all records from a table, the space for the records remain

MERGE - UPSERT operation (insert or update)

CALL - call a PL/SQL or Java subprogram

EXPLAIN PLAN - explain access path to data

LOCK TABLE - control concurrency

DCL (Data Control Language)


GRANT - gives user’s access privileges to database

REVOKE - withdraw access privileges given with the GRANT command

TCL (Transaction Control Language)


COMMIT - save work done

SAVEPOINT - identify a point in a transaction to which you can later roll back

ROLLBACK - restore database to original since the last COMMIT

SET TRANSACTION - Change transaction options like isolation level and what rollback segment to use


The terms master and slave have historically been used in replication, but the terms terms primary and replica are now preferred.

Architecture

資料庫的主從複製 一開始是單純為了備份、讀寫分離等需求而來的 但在實際應用上還有更多不同面向的需求,所以有不同的設計架構

OLTP (On-Line Transaction Processing)

OLTP是事件驅動、面向應用的,也稱為面向交易的處理過程。其基本特徵是前臺接收的用戶數據可以立即傳送到計算中心進行處理,並在很短的時間內給出處理結果,是對用戶操作的快速響應

例如銀行類、電子商務類的交易系統就是典型的OLTP系統

OLAP (On-Line Analytical Processing)

OLAP是面向數據分析的,也稱為面向信息分析處理過程。它使分析人員能夠迅速、一致、交互地從各個方面觀察信息,以達到深入理解數據的目的。其特徵是應對海量數據,支持複雜的分析操作,側重決策支持,並且提供直觀易懂的查詢結果

例如數據倉庫是其典型的OLAP系統

HTAP (Hybrid Transaction and Analytical Process)

2014年Gartner的一份報告中使用混合事務分析處理(HTAP)一詞描述新型的應用程序框架,以打破OLTP和OLAP之間的隔閡,既可以應用於事務型數據庫場景,亦可以應用於分析型數據庫場景,實現實時業務決策

這種架構具有顯而易見的優勢:不但避免了繁瑣且昂貴的ETL(Extract Transform Load)操作,而且可以更快地對最新數據進行分析

Row and Column Storage

Row: db1

Name City Age
Frank Taipai 33

Row: db2

Name City Age
Jimpop Kaohsiung 32

Row: db3

Name City Age
Darren Kaohsiung 27

Column: db1

Name
Frank
Jimpop
Darren

Column: db2

City
Taipai
Kaohsiung
Kaohsiung

Column: db2

Age
33
32
27

LB (Loading balance)

BinlogServer

graph TD Master[Master] BinlogServer[BinlogServer] Slave1[Slave1] Slave2[Slave2] Master --> BinlogServer BinlogServer --> Slave1 BinlogServer --> Slave2
Ex: MaxScale, Mysql-ripple, KingBus….

QueryProxy

graph TD Master[Master] QueryProxy[QueryProxy] Slave1[Slave1] Slave2[Slave2] QueryProxy --> |Read&Write| Master QueryProxy --> |Read| Slave1 QueryProxy --> |Read| Slave2
Ex: MaxScale, HAProxy. ProxySQL, Sharding-Proxy….

HTAP

Other

SMP (Symmetric Multiprocessing)

對稱多處理

MPP (Massively Parallel Processing)

即大規模並行處理,在數據庫非共享集群中,每個節點都有獨立的磁盤存儲系統和內存系統,業務數據根據數據庫模型和應用特點劃分到各個節點上,每臺數據節點通過專用網絡或者商業通用網絡互相連接,彼此協同計算,作為整體提供數據庫服務。非共享數據庫集群有完全的可伸縮性、高可用、高性能、優秀的性價比、資源共享等優勢

簡單來說,MPP是將任務並行的分散到多個服務器和節點上,在每個節點上計算完成後,將各自部分的結果彙總在一起得到最終的結果

EPP (Elastic Parallel Processing)

與MPP解決方案相似,在該解決方案中,許多獨立運行的無共享節點並行存儲和處理查詢,EPP(彈性並行處理)體系結構提供了令人印象深刻的可伸縮性

但是,與將數據存儲直接附加到每個節點的MPP群集不同,EPP體系結構將計算和存儲分開,這意味著每個都可以獨立擴展或彈性縮減

在上圖中,長期存儲由存儲服務提供, 從群集中的每個節點都可以看到。查詢將提交給服務層,該服務層 負責總體查詢協調,查詢調整和事務管理,並且實際工作在計算層上 有效執行,即有效的MPP集群。

儘管計算層通常具有直接連接的磁盤或快速SSD用於本地存儲,但是使用獨立的存儲服務層意味著可以獨立於計算容量來擴展數據存儲。這意味著可以彈性調整計算群集的大小,在提供MPP體系結構所有優點的同時,還可以消除許多缺點。

Reference

Mariadb platfrom X3

混合事務分析處理“HTAP”的技術要點分析

Database Architectures Compared