mysql資料庫安全方案,MySQL資料庫安全

本文目錄一覽：

• 1、資料庫安全的概念是什麼？一般影響資料庫安全的因素有哪些
• 2、mysql資料庫可靠性分析
• 3、如何解決Mysql的帳戶安全問題
• 4、mysql如何備份最安全
• 5、如何保證數據安全性 MySQL資料庫設計優化技巧
• 6、五大常見的MySQL高可用方案(最全)

資料庫安全的概念是什麼？一般影響資料庫安全的因素有哪些

網站資料庫的安全問題主要是由哪些因素引起的呢？這一個問題其實和資料庫存的安全問題差不多， 據CVE的數據安全漏洞統計，Oracle、SQL Server、MySQL等主流資料庫的漏洞逐年上升，以Oracle為例，當前漏洞總數已經超過了1200多個。美國Verizon就「核心數據是如何丟失的」做過一次全面的市場調查，結果發現，75%的數據丟失情況是由於資料庫漏洞造成的，這說明資料庫的安全非常重要。

資料庫安全漏洞從來源上，大致可以分為四類：預設安裝漏洞、人為使用上的漏洞、資料庫設計缺陷、資料庫產品的bug。

1. 資料庫設計缺陷，在當前的主流資料庫中,

，數據以明文形式放置在存儲設備中，存儲設備的丟失將引起數據泄密風險。資料庫數據文件在操作系統中以明文形式存在，非法使用者可以通過網路、操作系統接觸到這些文件，從而導致數據泄密風險。

2. 預設安裝漏洞，資料庫安裝後的預設用戶名和密碼在主流資料庫中往往存在若干預設資料庫用戶，並且預設密碼都是公開的，攻擊者完全可以利用這些預設用戶登錄資料庫。在主流資料庫中預設埠號是固定的，如Oracle是1521、SQL Server是1433、MySQL是3306等。

3. 人為使用漏洞,

，在很多系統維護中，資料庫管理員並未細緻地按照最小授權原則給予資料庫用戶授權，而是根據最為方便的原則給予了較為寬泛的授權

mysql資料庫可靠性分析

mysql資料庫有undo空間

5種mysql做可靠性分析的方案：

1．MySQL Clustering(ndb-cluster stogare)

簡介：

MySQL公司以存儲引擎方式提供的高可靠性方案，是事務安全的，實時複製數據，可用於需要高可靠性及負載均衡的場合。該方案至少需要三個節點伺服器才能達到較好的效果。

成本：

節點伺服器對RAM的需求很大，與資料庫大小呈線性比例；

最好使用千兆乙太網絡；

還需要使用Dolphin公司提供的昂貴的SCI卡。

優點：

可用於負載均衡場合；

可用於高可靠性場合；

高伸縮性；

真正的資料庫冗餘；

容易維護。

缺點：

隨著資料庫的變大，對RAM的需求變得更大，因此成本很高；

速度：

幾乎 比典型的單獨伺服器（無千兆乙太網，無SCI卡，存儲引擎相關的限制少）慢10倍。

應用場合：

冗餘，高可靠性，負載均衡

2. MySQL / GFS-GNBD/ HA (Active/Passive)

簡介：

如果多個MySQL伺服器使用共享硬碟作為數據存儲，此方案如何？

GFS/GNBD可以提供所需的共享硬碟。

GFS是事務安全的文件系統。同一時刻你可以讓一個MySQL使用共享數據。

成本：

最多n台高性能伺服器的成本，其中一個激活的，其他作為備份伺服器。

優點：

高可靠性

某種程度的冗餘

按照高可靠性進行伸縮

缺點：

沒有負載均衡

沒有保證的冗餘

無法對寫操作進行伸縮

速度：

單獨伺服器的2倍。對讀操作支持得較好。

應用場合：

需要高可靠性的、讀操作密集型的應用

3. MySQL / DRBD / HA (Active/Passive)

簡介：

如果多個MySQL伺服器使用共享硬碟作為數據存儲，此方案如何？

DRBD可以提供這樣的共享硬碟。DRBD可以被設置成事務安全的。

同一時刻你可以讓一個MySQL使用共享數據。

成本：

最多n台高性能伺服器的成本，其中一個激活的，而其他則作為備份伺服器。

優點：

高可靠性；

一定程度的冗餘；

以高可靠性名義來看是可伸縮的。

缺點：

沒有負載均衡

沒有保證的冗餘

在寫負載方面沒有伸縮性

速度：

在讀寫方面相當於單獨伺服器

應用場合

需要高可靠性、讀操作密集型的應用

4. MySQL Write Master / Multiple MySQL Read Slaves (Active/Active)

簡介：

考慮不同的讀、寫DB資料庫連接的情況。可以使用一台主伺服器用於寫操作，而採用n台從伺服器用於讀操作。

成本：

最多1台高性能寫伺服器，n台讀伺服器的成本

優點:

讀操作的高可靠性；

讀操作的負載均衡；

在讀操作負載均衡方面是可伸縮的。

缺點：

無寫操作的高可靠性；

無寫操作的負載均衡；

在寫操作方面無伸縮性；

速度：

同單獨伺服器；在讀操作方面支持得較好

應用場合

讀操作密集型的、需要高可靠性和負載均衡的應用。

5. Standalone MySQL Servers(Functionally separated) (Active)

多台功能分離的單獨伺服器，沒有高可靠性、負載均衡能力，明顯缺點太多，不予考慮。

如何解決Mysql的帳戶安全問題

在安裝完成MySQL 後，不僅改變root用戶的的密碼，也同時改變匿名用戶的密碼，方法類似改變root的密碼的方式：

QUOTE:

以下為引用的內容：

MySQL UPDATE user set password=PASSWORD(‘yournewpassword’) where user=”;

MySQLFLUSH PRIVILEGES;

2、如非必要，刪除這個匿名用戶，這樣所有人要使用MySQL 都必須提供用戶名，即便日後出了問題，也容易查找問題的源頭。

3、除了root用戶外，其他用戶包括匿名用戶（如果沒有刪除這個用戶）不應該擁有grant許可權，防止管理許可權不受控制的擴散出去。

4、賦予用戶update\delete\alert\create\drop許可權的時候，應該限定到特定的資料庫，尤其要避免普通客戶擁有對MySQL資料庫做操作的許可權，否則你的系統設置很可能被替換掉。

5、檢查MySQL.user表，取消不必要用戶的shutdown_priv,reload_priv,process_priv和File_priv許可權，這些許可權可能泄漏更多的伺服器信息包括非MySQL的其它信息出去。

6、如果不打算讓你的用戶使用MySQL資料庫，在提供諸如php這樣的腳本語言的時候，重新設置或編譯你的php,取消它們對MySQL的默認支持。

mysql如何備份最安全

Mysql資料庫備份的方法：

方法一：如果你使用的是虛擬主機，可以用使用phpmyadmin來備份資料庫。

1、登陸phpmyadmin。登陸後左邊會出現資料庫列表，單擊要備份的資料庫。

2、在彈出的頁面中，右側上部單擊「導出」按鈕，一般保持默認選項，最下面「另存為文件」，選擇「ZIP壓縮」，最後單擊執行按鈕。

3、彈出保存文件後，保存文件即可。

如何保證數據安全性 MySQL資料庫設計優化技巧

1、優化設計的技巧

(1) 如果一個欄位需要經常更改，則採用以空間換時間的設計方法

最常見的例子是用戶積分登錄次數的累加，按照範式設計，在users表中建立一個欄位us_scores,以後需要在用戶積分改變時採用update的語句進行修改。但是知道 update語句的執行速度是很慢的，為了避免大量重複使用它，優化的設計方案是建立us_scores表，存儲每次增加的積分，在查詢是採用SQL語句的sum方法來計算之。

(2) 關聯欄位類型儘可能定義為數字類型

(3) 表的序列欄位必須是數字類型

(4) 若資料庫有移植的可能性，不使用存儲過程及觸發器

(5) 建立恰當的索引

索引的建立是加快資料庫查詢的基本技巧之一，通常的建議是，只有百萬級的記錄的表格才應該建立索引。

，命名都應該作為非常重要的事情來看待，表、序列、欄位、索引的命名技巧可以歸結如下：

(1) 關聯欄位名稱必須相同，名稱以基礎表的欄位名稱為準

(2) 序列名字跟表欄位名字相同

(3) 關聯表的名稱應該是被關聯的表用「_」連接起來組成的

(4) 欄位定義的前兩位是表名的縮寫，第三位是下劃線

一，保證規範，序列名稱必須是唯一的，而且，一般的序列就是這個表的id欄位。如果不加前綴，那麼欄位都叫做id就會違背惟一性原則。

第二，為了將來關聯查詢語句的書寫方便。

(5) 索引的名字和表的名字相同

(6) 常用欄位採用固定定義

為了提高大數據量的表格的查詢速度，可以採用建立適當的索引方式。如果一個表只有一個索引，建議索引的名字跟表相同，如果有多個索引，則為表名稱加下劃線加索引列名稱。

最安全的設計方案是，Web資料庫和測試資料庫分離。Web資料庫許可權只被管理員一個人掌握。

關於MySQL資料庫設計

的優化措施還需要經過資料庫設計人員的不斷發掘，從資料庫設計中不斷的發現問題，提出解決問題的方法，才能將資料庫的性能優化的更好更全面。

五大常見的MySQL高可用方案(最全)

1. 概述

我們在考慮MySQL資料庫的高可用的架構時，主要要考慮如下幾方面：

如果資料庫發生了宕機或者意外中斷等故障，能儘快恢復資料庫的可用性，儘可能的減少停機時間，保證業務不會因為資料庫的故障而中斷。

用作備份、只讀副本等功能的非主節點的數據應該和主節點的數據實時或者最終保持一致。

當業務發生資料庫切換時，切換前後的資料庫內容應當一致，不會因為數據缺失或者數據不一致而影響業務。

關於對高可用的分級在這裡我們不做詳細的討論，這裡只討論常用高可用方案的優缺點以及高可用方案的選型。

2. 高可用方案

2.1. 主從或主主半同步複製

使用雙節點資料庫，搭建單向或者雙向的半同步複製。在5.7以後的版本中，由於lossless replication、logical多線程複製等一些列新特性的引入，使得MySQL原生半同步複製更加可靠。

常見架構如下：

通常會和proxy、keepalived等第三方軟體同時使用，即可以用來監控資料庫的 健康 ，又可以執行一系列管理命令。如果主庫發生故障，切換到備庫後仍然可以繼續使用資料庫。

優點：

架構比較簡單，使用原生半同步複製作為數據同步的依據；

雙節點，沒有主機宕機後的選主問題，直接切換即可；

雙節點，需求資源少，部署簡單；

缺點：

完全依賴於半同步複製，如果半同步複製退化為非同步複製，數據一致性無法得到保證；

需要額外考慮haproxy、keepalived的高可用機制。

2.2. 半同步複製優化

半同步複製機制是可靠的。如果半同步複製一直是生效的，那麼便可以認為數據是一致的。但是由於網路波動等一些客觀原因，導致半同步複製發生超時而切換為非同步複製，那麼這時便不能保證數據的一致性。所以儘可能的保證半同步複製，便可提高數據的一致性。

該方案同樣使用雙節點架構，但是在原有半同複製的基礎上做了功能上的優化，使半同步複製的機制變得更加可靠。

可參考的優化方案如下：

2.2.1. 雙通道複製

半同步複製由於發生超時後，複製斷開，當再次建立起複制時，同時建立兩條通道，其中一條半同步複製通道從當前位置開始複製，保證從機知道當前主機執行的進度。另外一條非同步複製通道開始追補從機落後的數據。當非同步複製通道追趕到半同步複製的起始位置時，恢復半同步複製。

2.2.2. binlog文件伺服器

搭建兩條半同步複製通道，其中連接文件伺服器的半同步通道正常情況下不啟用，當主從的半同步複製發生網路問題退化後，啟動與文件伺服器的半同步複製通道。當主從半同步複製恢復後，關閉與文件伺服器的半同步複製通道。

優點：

雙節點，需求資源少，部署簡單；

架構簡單，沒有選主的問題，直接切換即可;

相比於原生複製，優化後的半同步複製更能保證數據的一致性。

缺點：

需要修改內核源碼或者使用mysql通信協議。需要對源碼有一定的了解，並能做一定程度的二次開發。

依舊依賴於半同步複製，沒有從根本上解決數據一致性問題。

2.3. 高可用架構優化

將雙節點資料庫擴展到多節點資料庫，或者多節點資料庫集群。可以根據自己的需要選擇一主兩從、一主多從或者多主多從的集群。

由於半同步複製，存在接收到一個從機的成功應答即認為半同步複製成功的特性，所以多從半同步複製的可靠性要優於單從半同步複製的可靠性。並且多節點同時宕機的幾率也要小於單節點宕機的幾率，所以多節點架構在一定程度上可以認為高可用性是好於雙節點架構。

但是由於資料庫數量較多，所以需要資料庫管理軟體來保證資料庫的可維護性。可以選擇MMM、MHA或者各個版本的proxy等等。常見方案如下：

2.3.1. MHA+多節點集群

MHA Manager會定時探測集群中的master節點，當master出現故障時，它可以自動將最新數據的slave提升為新的master，然後將所有其他的slave重新指向新的master，整個故障轉移過程對應用程序完全透明。

MHA Node運行在每台MySQL伺服器上，主要作用是切換時處理二進位日誌，確保切換盡量少丟數據。

MHA也可以擴展到如下的多節點集群：

優點：

可以進行故障的自動檢測和轉移;

可擴展性較好，可以根據需要擴展MySQL的節點數量和結構;

相比於雙節點的MySQL複製，三節點/多節點的MySQL發生不可用的概率更低

缺點：

至少需要三節點，相對於雙節點需要更多的資源;

邏輯較為複雜，發生故障後排查問題，定位問題更加困難;

數據一致性仍然靠原生半同步複製保證，仍然存在數據不一致的風險;

可能因為網路分區發生腦裂現象;

2.3.2. zookeeper+proxy

Zookeeper使用分散式演算法保證集群數據的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網路分區現象的產生。

優點：

較好的保證了整個系統的高可用性，包括proxy、MySQL;

擴展性較好，可以擴展為大規模集群;

缺點：

數據一致性仍然依賴於原生的mysql半同步複製;

引入zk，整個系統的邏輯變得更加複雜;

2.4. 共享存儲

共享存儲實現了資料庫伺服器和存儲設備的解耦，不同資料庫之間的數據同步不再依賴於MySQL的原生複製功能，而是通過磁碟數據同步的手段，來保證數據的一致性。

2.4.1. SAN共享儲存

SAN的概念是允許存儲設備和處理器（伺服器）之間建立直接的高速網路（與LAN相比）連接，通過這種連接實現數據的集中式存儲。常用架構如下：

使用共享存儲時，MySQL伺服器能夠正常掛載文件系統並操作，如果主庫發生宕機，備庫可以掛載相同的文件系統，保證主庫和備庫使用相同的數據。

優點：

兩節點即可，部署簡單，切換邏輯簡單；

很好的保證數據的強一致性；

不會因為MySQL的邏輯錯誤發生數據不一致的情況；

缺點：

需要考慮共享存儲的高可用；

價格昂貴；

2.4.2. DRBD磁碟複製

DRBD是一種基於軟體、基於網路的塊複製存儲解決方案，主要用於對伺服器之間的磁碟、分區、邏輯卷等進行數據鏡像，當用戶將數據寫入本地磁碟時，還會將數據發送到網路中另一台主機的磁碟上，這樣的本地主機(主節點)與遠程主機(備節點)的數據就可以保證實時同步。常用架構如下：

當本地主機出現問題，遠程主機上還保留著一份相同的數據，可以繼續使用，保證了數據的安全。

DRBD是linux內核模塊實現的快級別的同步複製技術，可以與SAN達到相同的共享存儲效果。

優點：

兩節點即可，部署簡單，切換邏輯簡單；

相比於SAN儲存網路，價格低廉；

保證數據的強一致性；

缺點：

對io性能影響較大；

從庫不提供讀操作；

2.5. 分散式協議

分散式協議可以很好解決數據一致性問題。比較常見的方案如下：

2.5.1. MySQL cluster

MySQL cluster是官方集群的部署方案，通過使用NDB存儲引擎實時備份冗餘數據，實現資料庫的高可用性和數據一致性。

優點：

全部使用官方組件，不依賴於第三方軟體；

可以實現數據的強一致性；

缺點：

國內使用的較少；

配置較複雜，需要使用NDB儲存引擎，與MySQL常規引擎存在一定差異；

至少三節點；

2.5.2. Galera

基於Galera的MySQL高可用集群， 是多主數據同步的MySQL集群解決方案，使用簡單，沒有單點故障，可用性高。常見架構如下：

優點：

多主寫入，無延遲複製，能保證數據強一致性；

有成熟的社區，有互聯網公司在大規模的使用；

自動故障轉移，自動添加、剔除節點；

缺點：

需要為原生MySQL節點打wsrep補丁

只支持innodb儲存引擎

至少三節點；

2.5.3. POAXS

Paxos 演算法解決的問題是一個分散式系統如何就某個值（決議）達成一致。這個演算法被認為是同類演算法中最有效的。Paxos與MySQL相結合可以實現在分散式的MySQL數據的強一致性。常見架構如下：

優點：

多主寫入，無延遲複製，能保證數據強一致性；

有成熟理論基礎；

自動故障轉移，自動添加、剔除節點；

缺點：

只支持innodb儲存引擎

至少三節點；

3. 總結

隨著人們對數據一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分散式數據一致性的問題，如MySQL自身的優化、MySQL集群架構的優化、Paxos、Raft、2PC演算法的引入等等。

而使用分散式演算法用來解決MySQL資料庫數據一致性的問題的方法，也越來越被人們所接受，一系列成熟的產品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規模使用。

隨著官方MySQL Group Replication的GA，使用分散式協議來解決數據一致性問題已經成為了主流的方向。期望越來越多優秀的解決方案被提出，MySQL高可用問題可以被更好的解決。