1. 程式人生 > >MySQL備份,恢復方案,mysqlbinlog,mysqldump,主從,主主復制

MySQL備份,恢復方案,mysqlbinlog,mysqldump,主從,主主復制

庫存 讀寫 sel erro l數據庫 reat 當前 password ima

DBMS數據庫管理系統的三層模型:物理層,邏輯層以及視圖層。

物理層:決定數據的存儲形式。

邏輯層:是一張有一張的表,一行行的數據記錄。

視圖層:讓用戶看起來更方便,可有可無。

存儲引擎:使邏輯層中sql語句轉換成能在磁盤上存儲的物理形式,連接邏輯層與物理層。

常用MySQL存儲引擎:

MyISAM:

最經典的MySQL存儲引擎,但如果數據庫一旦崩潰,再重啟時需要對表進行修復,但MyISAM

存儲引擎無法保證安全修復,且其不支持事務的進行。支持表級鎖。

Innodb:

Innodb存儲引擎,支持事務,數據庫的存儲,是以表空間的方式存儲,支持MVCC的高並發,

支持四種隔離級別,read-uncommitted讀未提交,read-committed讀提交,repeatable-read幻讀

serializable串行化。支持行級鎖,間隙鎖。

Aria:

Aria存儲引擎數據庫一旦崩潰,能夠對數據庫安全修復增強版MyISAM存儲引擎。

Memory:

內存級存儲引擎,支持自適應hash索引,查詢能力十分強大。

MRG_MyISAM:

將多張表邏輯層連接在一起,使用戶就像使用一張表一樣。

PERFORMANCE_SCHEMA:

展示數據庫運行時的狀態參數和統計數據。

CSV:

基於文件的文件存儲數據存儲引擎。

ARCHIVE:

歸檔存儲引擎,通常用於做數據倉庫。

MySQL的日誌:

①查詢日誌:

general_log {ON|OFF} :查詢日誌是否開啟關閉。

general_log_file hostname.log :該變量的生效,需要在log_output為FILE時才能生效。

log_output FILE:

FILE:表示將日誌記錄於文件系統中的文件;

TABLE:表示將日誌記錄於MySQL中指定的表;

NONE:表示不將日誌記錄輸出出去;

②慢查詢日誌:

運行時間超過某指定時長的操作。

定義查詢超時時長的變量:

long_query_time 10.000000

慢查詢日誌是否開啟:

log_slow_queries OFF

slow_query_log_file hostname.log :該變量的生效,需要在log_output為FILE時才能生效。

log_output FILE:

FILE:表示將日誌記錄於文件系統中的文件;

TABLE:表示將日誌記錄於MySQL中指定的表;

NONE:表示不將日誌記錄輸出出去;

③錯誤日誌

log_error:保存了錯誤日誌的文件路徑;

log_warnings {ON|OFF}:是否將mysqld運行過程中產生的"Warning"類的信息一並記錄到錯誤日誌中;

④二進制日誌

用於記錄引起數據庫改變的SQL語句,可以通過備份二進制日誌中的指定內容來達到數據庫備份,還原的目的

這一部分操作,在後邊有示例。

需要在/etc/my.cny配置文件中設置log_bin路徑。

mysql>show master|binary logs:顯示當前數據庫中所有二進制日誌列表。

mysql>show master status:顯示當前數據庫中正在使用的數據庫列表,可以對指定日誌的position,datetime進行備份還原。

mysql>show binlog events in '日誌path':顯示對應二進制日誌文件的內容。

數據庫備份方式:

數據庫備份作為一種重要的數據保存手段,需要根據不同環境采取不同的備份操作,最大限度保證數據的安全,畢竟數據

才是一個企業生存的根本

①LVM實現MYSQL物理備份,恢復

首先,在主機中加入一塊硬盤充當MYSQL的數據存放的邏輯卷,以及備份數據的存儲源

#fdisk /dev/sdb

因實驗需要,所以只配置了一個擴展分區,及一個邏輯分區,將邏輯分區類型更改為8e即可;

創建邏輯卷:

#pvcreate /dev/sdb5

#vgcreate myvg /dev/sdb5

#lvcreate -L 5G -n mylv myvg

對邏輯卷進行格式化:

#mke2fs -t ext4 /dev/myvg/mylv

創建數據庫存放的路徑

#mkdir -pv /mysql/data

修改數據庫配置文件/etc/my.cnf

技術分享圖片

並在當前啟動mysql用戶家目錄下創建.my.cnf文件,否則無法正常啟動mysql

技術分享圖片

到這裏mysql服務就會在我們指定的邏輯卷中運行,lvm的備份方式主要是溫備份,但

也可以說是幾乎熱備份,只要對數據庫加鎖,解鎖的過程夠快,一般幾秒鐘即可,就

不會引起數據的錯亂;

對所有表進行加鎖操作:

MariaDB [hellodb]> flush tables with read lock;

緊接著拍攝快照,針對於該邏輯卷:

[root@zabbix-agent4 ~]# lvcreate -L 5G -s -n snap /dev/myvg/mylv


再對數據庫中的表進行解鎖操作:

MariaDB [hellodb]> unlock tables;

對二進制日誌進行備份操作,備份當前運行的位置

mysql -e "show master status" > /path

(這樣在需要還原數據時可以得知在備份那個時間段後我們執行了哪些操作,從二進制日誌文件可以看出,從而進行還原)


速度夠快的話就不會產生多大的數據損失,緊接著將快照卷掛載到指定目錄下,對數據進行打包壓縮,卸載快照卷即可將數據庫備份;

技術分享圖片

②select語句進行邏輯備份

創建一個同classes表中數據結構一樣的表;

技術分享圖片

使用select將數據保存在文件中,並導入到test表當中對數據庫進行備份

技術分享圖片

技術分享圖片


③使用mysqldump對數據庫進行備份

mysqldump -uroot -p password 數據庫名 --lock-tables --flush-logs --master-data=2 > /path.sql

使用上述方式對指定數據庫中的所有表進行加鎖,--flush-logs對二進制日誌文件僅刷新一次,而不是重復刷新

--master-data將二機制日誌文件名和其所用到的時間的位置標識,追加到備份文件中,1為不註釋,2為註釋;

保存在/path.sql路徑下後,只需要進入指定備份的數據庫,並使用source /path.sql即可還原備份數據;

註意:上述方式需要事先創建同名數據庫,然後進入該數據庫執行source操作;

可使用另一種musqldump格式,可將數據庫的數據格式也備份下來,這樣就無需創建數據庫進行還原

如:

mysqldump -uroot -p password --database 數據庫名 --lock-tables --flush-logs --master-data=2 > /path.sql


對二進制日誌進行備份操作,備份當前運行的位置

mysql -e "show master status" > /path

(這樣在需要還原數據時可以得知在備份那個時間段後我們執行了哪些操作,從二進制日誌文件可以看出,從而進行還原)


④percona xtrabackup實現數據庫備份

xtrabackup是一款由percona提供的世界上唯一一款開源實現innodb數據庫熱備份的工具

其備份過程快速可靠,不會打斷正在執行的事務,還原速度快,能夠實現自動檢驗;

MYISAM完全備份

MYISAM因為不不支持事務,所以只能實現溫備份,即在只讀不可寫的狀況下的數據庫備份,無法進行增量備份

只能進行完全備份

熱備份:可讀可寫;

溫備份:只讀不可寫;

冷備份:不可讀不可寫;

安裝xtrabackup,在阿裏雲中的epel源中

#yum install -y percona xtrabackup

使用innobackupex進行備份

--user:指定備份數據庫所用的用戶;

--password:備份數據庫用戶所用的密碼;

--host:備份數據庫所在的主機;

--socket:指定備份數據庫所用的socket路徑;

如:

技術分享圖片

因為之前有更改過數據庫文件的默認路徑,所以需要指定socket

最後的路徑為完全備份存儲的路徑,innobackex命令如果不特別指定格式的話,會以日期的形式將完全備份

存儲在該目錄下

#mkdir -pv /mysql/backup2

#chown mysql:mysql /mysql/backup2

技術分享圖片

進行還原準備操作,因為數據庫在進行還原時,需要考慮在備份數據庫時是否有事務在進行卻尚未提交,是否有事務

已經提交,但尚未同步到數據庫當中,我們需要針對這類型的數據進行一致化操作,"準備"的主要作用正是通過回滾

未提交的事務及同步已經提交的事務至數據文件也使得數據文件處於一致性狀態。

技術分享圖片

備份存儲好之後,將數據全部刪除,驗證備份數據

使用--copy-back選項即可,不管是完全備份,還是完全備份+增量備份的還原都是該選項進行

技術分享圖片

註意:備份還原操作,需要在原數據庫文件全部刪除,mysqld進程不在運行的條件下執行

且備份後的數據庫文件權限均為root,需要更改為mysql

技術分享圖片

啟動服務,數據庫完好無損。


INNODB完全備份+增量備份

Innodb存儲引擎支持事務,其可支持溫備份以及熱備份;這也是innobackupex的一大特點;

增量備份是基於上一次備份後產生的數據差別進行的備份;

首先將數據庫進行幾次修改,並逐一進行完全備份,增量備份操作

首次完全備份

技術分享圖片

增量備份:

技術分享圖片

技術分享圖片

準備操作:

技術分享圖片

技術分享圖片

技術分享圖片

--redo-only:在最後一次增量備份時不使用

技術分享圖片

準備結束後就可執行還原操作,刪除原數據庫內容,關閉數據庫服務

技術分享圖片

技術分享圖片

采用增量備份的方式,分兩次添加了ClassID9,10數據

技術分享圖片

MySQL主從復制:

在MySQL中,支持單項,異步復制,而主從復制,則是由至少兩臺MySQL服務器實現,由一臺MySQL

作為主服務器,進行寫入操作,而由另一臺MySQL服務器作為從服務器進行讀操作,主數據庫中的數據

會自動備份到從服務器,可以進行讀寫分離操作,以增強數據庫的讀寫性能。而兩臺服務器之間使用不同

的硬盤,當主服務器的硬盤損壞時,從服務器的數據就保留下來,進行數據恢復。

主從服務器搭建的原理是,從服務器開啟數據庫線程sql_thread,io_thread並在/etc/my.cnf中構建中繼

日誌,用於存放從主服務器復制過來的數據,io_thread線程是向主服務器之間搭建數據復制的橋梁,當主

服務器中數據庫的數據改變時,會寫入二進制日誌當中,由io_thread讀取,並復制,需要由主服務器指定

執行復制操作的數據庫用戶,並授權,在從服務器配置相關master,指定主服務器IP,復制數據庫用戶的

賬號,密碼,由哪一個二進制日誌文件開始復制,從該二進制文件當中的哪個位置開始復制等。當io_thread

取回復制的數據庫內容後,就存放在從服務器的中繼日誌當中,由sql_thread線程將中繼日誌中的數據寫入

到執行存儲引擎,備份成功!

主服務器配置:IP,172.16.25.101

配置二進制文件,設置server_id

技術分享圖片

對用戶進行授權,設置用戶復制權限

技術分享圖片

主從復制需要將主服務器中的數據庫完全備份到從服務器,否則會報錯,無法進行主從復制

主服務器:

技術分享圖片

從服務器:

技術分享圖片

從服務器配置:

配置 relay_log中繼日誌,server_id在/etc/my.cnf中

技術分享圖片

配置從服務器中的master指向

技術分享圖片

master_host:主服務器IP.

master_user:主服務器上進行復制的數據庫用戶。

master_password:主服務器上進行復制的數據庫用戶密碼。

master_log_file:從主服務器上的哪個二進制日誌文件開始復制。這裏我選定的是最後一個二進制日誌。

master_log_pos:從主服務器上的指定二進制日誌文件的哪個位置開始復制。


這個時候可以使用show slave status\G查看

技術分享圖片

兩個線程均沒有開啟,現在開啟線程則主從復制啟用

技術分享圖片

在主服務器數據庫中插入一條數據,在查看從哪個服務器看是否進行了復制操作

主服務器:

技術分享圖片

從服務器:

查看數據是否復制:

技術分享圖片

MySQL主從復制之半同步:

半同步復制,在對主從復制的基礎上進行延伸,如主從復制時,主服務器在向從服務器傳輸數據時,從服務器

突然宕機,則數據的傳輸會有兩種情況,

1.事務還未發送到從服務器上。

2.事務已發到從服務器上,但客戶端會接受到事務傳送失敗的消息,重新發送事務。

所以針對於以上情況,MySQL數據庫推出了全新的半同步機制,在從服務器宕機後,會有一段延遲時間讓主服

務器去聯系從服務器,若沒有聯系上就寫入主服務器自身,待從服務器聯系上了再寫入從服務器,這種異步加同

步的操作就稱之為半同步。

半同步需要對主從服務器加載特殊的插件,插件保存在/usr/lib64/mysql/plugin中

技術分享圖片

主服務器/etc/my.cnf

技術分享圖片

從服務器/etc/my.cnf

技術分享圖片

半同步復制則需要semisync_master.so,semisync_slave.so兩種插件,分別加載到主從服務器

主:

技術分享圖片

從:

技術分享圖片

將主從服務器的同步機制開啟:

技術分享圖片

技術分享圖片

將從服務器進行授權,指定master

技術分享圖片

在從服務器上設置只讀,read_only開啟,並開啟另一個MySQL會話並執行

mysql>flush tables with read lock;

只要該會話不關閉則讀鎖一直存在。

如何查看半同步是否成功:

rpl_semi_sync_master_clients為1

技術分享圖片

看nakahcehur在主服務器處進行寫操作查看是否同步到從服務器上

技術分享圖片

從服務器:

技術分享圖片

當關閉從服務器線程時

主服務器再次寫入數據,延遲十秒

技術分享圖片

這是因為主服務器上的同步延遲設置為十秒,當十秒內無法聯系上從服務器,就寫入自身,如:

技術分享圖片

timeout設置為10000毫秒,即為10s

MySQL主主復制:

主主復制,至少兩臺的數據庫服務器 ,都作為主服務器,每一臺服務器既是主服務器,也是對面主服務器

的從服務器,實現原理同上,不同的是每一臺服務器都需要有中繼日誌和二進制日誌,因為每一臺服務器都

作為主服務器以及從服務器。主主復制相較於主從復制來說,多了一個mysql入口,相當於mysql的高可用

但卻需要考慮ID增長的問題。

主主復制相對於主從復制,需要註意的是

1.數據不一致,比如,一臺服務器在進行更新操作,將35歲包括以上人的工資上調3000元,當數據庫復制

到另一臺服務器,數據進行重寫,寫入到這臺服務器時,如果這臺服務器執行了給每一個員工增加1歲時

這樣剛巧有些人從34歲到了35歲的年齡的話,該數據就會不一致。目前只能使用一些數據恢復軟件來進

行排錯.

2.主鍵,當兩臺服務器同時都插入數據時,一些自動增長的如ID的屬性可能會重合,這樣會導致沖突,數

據插入刪除修改也將會失敗。所以需要設置auto_incremental_incremental以及auto_incremental_offset

用於設置每次自動增長的量,以及初次增長的基數。一般設置為奇數偶數相對應,這樣就不會重合。

主主服務器配置:

主服務器1:IP 172.16.25.101

/etc/my.cnf

技術分享圖片

設置為奇數增長,針對於那些auto_increment的字段


授權,指定master為172.16.25.102

技術分享圖片

技術分享圖片

主服務器2:IP 172.16.25.102

/etc/my.cnf

技術分享圖片

授權,指定master為172.16.25.101

技術分享圖片

技術分享圖片

分別為兩臺服務器開啟線程

mysql>start slave;

分別從兩臺服務器進行讀寫操作:

主服務器1插入一條數據到classes中

技術分享圖片

因為設置的是奇數增長所以由11增長到13

到主服務器2進行查看,並插入一條數據:

技術分享圖片

由圖可知復制成功,再在主服務器2中插入一條數據,並在主服務器1中可見。

主主復制成功!







MySQL備份,恢復方案,mysqlbinlog,mysqldump,主從,主主復制