概念:採用了關係型模型來組織數據的數據庫。html
1)關係型數據庫在存儲數據時實際就是採用的一張二維表前端
2)市場佔有量較大的是MySQL和oracle數據庫,而互聯網場景最經常使用的是MySQL數據庫。mysql
3)它經過SQL結構化查詢語言來存取、管理關係型數據庫的數據。web
4)關係型數據庫在保持數據安全和數據一致性方面很強,遵循ACID理論算法
& 關係:能夠理解爲一張二維表,每一個關係都具備一個關係名,就是一般說的表名。sql
& 元組:能夠理解爲二維表中的一行,在數據庫中常常被稱爲記錄。數據庫
& 屬性:能夠理解爲二維表中的一列,在數據庫中常常被稱爲字段。vim
& 域:屬性的取值範圍,也就是數據庫中某一列的取值限制。windows
& 關鍵字:一組能夠惟一標識元組的屬性。數據庫中常稱爲主鍵,由一個或多個列組成。瀏覽器
& 關係模式:指對關係的描述,其格式爲,關係名(屬性1,屬性2,…,屬性N)。在數據庫中一般稱爲表結構。
主要特色:使用方便,易於維護,容易理解
Oracle數據庫:其產品支持最普遍的操做系統平臺。目前Oracle關係數據庫產品的市場佔有率首屈一指。
版本升級:Oracle8i,Oracle9i,Oracle1Og,Oracle11g,Oracle12c。
應用場景:傳統大企業,大公司,政府,金融,證券等等。
MySQL數據庫:是一箇中小型關係型數據庫管理系統
1)MySQL性能卓越,服務穩定,不多出現異常宕機。
2)MySQL開放源代碼且無版權制約,自主性及使用成本低。
3)MySQL歷史悠久,社區及用戶很是活躍,遇到問題,能夠尋求幫助。
4)MySQL軟件體積小,安裝使用簡單,而且易於維護,安裝及維護成本低。
5)MySQL品牌口碑效應,使得企業無需考慮就直接用之,LAMP, LEMP流行架構。
6)MySQL支持多種操做系統,提供多種API接口,支持多種開發語言,特別對流行的PHP語言有很好的支持。
其發佈的MySQL版本採用雙受權政策,和大多數開源產品的路線同樣,分爲社區版和商業版,而這兩個版本又各自分四個版本依次發佈,這四個版本爲:Alpha版、Beta版、RC版和GA版本。
MySQL在發展到5.1系列版本以後,從新規劃爲三條產品線。
應用場景:互聯網領域,大中小型網站,遊戲公司,電商平臺等等。
MariaDB數據庫:MySQL數據庫的一支分支,MariaDB基於事務的Maria存儲引擎,替換了MySQL的MylSAM存儲引擎,它使用了Percona的XtraDB(InnoDB的變體)。
Microsoft SQL Server:是微軟公司開發的大型關係型數據庫系統,SQL Server的功能比較全面,效率高,能夠做爲中型企業或單位的數據庫平臺。SQL Server能夠與Windows操 做系統緊密集成,不管是應用程序開發速度仍是系統事務處理運行速度,都能獲得較大的 提高。對於在Windows平臺上開發的各類企業級信息管理系統來講,不管是C/S(客戶機/ 服務器)架構仍是B/S(瀏覽器/服務器)架構,SQL Server都是一個很好的選擇。SQL Server的缺點是隻能在Windows系統下運行。
主要應用範圍:部分企業電商(央視購物),使用windows服務器平臺的企業。
Access 數據庫:
主要特色 以下:
1)完善地管理各類數據庫對象,具備強大的數據組織、用戶管理、安全檢查等功能。
2)強大的數據處理功能,在一個工做組級別的網絡環境中,使用Access開發的多用戶數據庫管理系統具備傳統的XBASE(DBASE、FoxBASE的統稱)數據庫系統所沒法實現的客戶服務器(Cient/Server)結構和相應的數據庫安全機制,Access具有了許多先進的大型數據庫管理系統所具有的特徵,如事務處理/出錯回滾能力等。
3)能夠方便地生成各類數據對象,利用存儲的數據創建窗體和報表,可視性好。
4)做爲Office套件的一部分,能夠與Office集成,實現無縫鏈接。
5)可以利用Web檢索和發佈數據,實現與Internet的鏈接。Acess主要適用於中小型應用系統,或做爲客戶機/服務器系統中的客戶端數據庫。
早期應用領域:小型程序系統asp+access系統,留言板,校友錄等。
1)NOSQL數據庫不是否認關係型數據庫,而是做爲關係數據庫的一個重要補充。
2)NOSQL數據庫爲了靈活及高性能、高併發而生,忽略影響高性能、高併發的功能。
3)在NOSQL數據庫領域,當今的最典型產品爲Redis(持久化緩存)、Mongodb、Memcached純內存等。
4)NOSQL數據庫沒有標準的查詢語言(SQL),一般使用REST式的數據接口或者查詢API。
NoSQL數據庫的分類:
分類 |
數據模型 |
優勢 |
缺點 |
典型應用場景 |
鍵值(key-value)存儲數據庫 |
key指向Value的鍵值對,一般用hash表來實現 |
查找速度快 |
數據無結構化(一般只被看成字符串或者二進制數據) |
內容緩存,主要用於處理數據的高訪問負載,也用於一些日誌系統 |
列存儲數據庫 |
以列簇式存儲,將同一列數據存在一塊兒 |
查找速度快,可擴展性強,更容易進行分佈式擴展 |
功能相對侷限 |
分佈式的文件系統 |
文檔性數據庫 |
key-value對應的鍵值對,value爲結構化數據 |
數據結構要求不嚴格,表結構可變(不須要像關係型數據庫同樣預先定義表結構) |
查詢性能不高,並且缺少統一的查詢語法 |
web應用 |
圖形(Graph)數據庫 |
圖結構 |
利用圖結構相關算法(如最短路徑尋址,N度關係查找等) |
不少時候須要對整個圖作計算才能得出須要的信息,並且這種結構不太好作分佈式的集羣方案 |
社交網絡,推薦系統等 |
這一類數據庫主要會使用到哈希表,在這個表中有一個特定的鍵和一個指針指向特定的數據。Key/value模型對於IT系統來講優點在於簡單、易部署。可是若是DBA只對部分值進行查詢或更新的時候,Key/value就顯得效率低下了。
TokyoCabinet/Tyrant Redis Voldemort OracleBDB
這部分數據庫一般是用來應對分佈式存儲的海量數據。鍵仍然存在,可是它們的特色是指向了多個列。這些列是由列家族來安排的。
Cassandra HBase Riak
文檔型數據庫的靈感來自於Lotus Notes辦公軟件,它同第一種鍵值存儲相相似。該類型的數據模型是版本化的文檔,半結構化的文檔以特定的格式存儲,好比JSON。文檔型數據庫能夠看做是鍵值數據庫的升級版,容許之間嵌套鍵值。並且文檔型數據庫比鍵值數據庫的查詢效率更高。
CouchDB MongoDB SequoiaDB
圖形結構的數據庫同其它行列以及剛性結構的SQL數據庫不一樣,它是使用靈活的圖形模型,而且可以擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語言(SQL),所以進行數據庫查詢須要制定數據模型。許多NoSQL數據庫都有REST式的數據接口或者查詢API。
Neo4J InfoGrid InfiniteGraph
適用場景:
Redis:
& 數據變化較少,執行預約義查詢,進行數據統計的應用程序
& 須要提供數據版本支持的應用程序
& 例如:股票價格、數據分析、實時數據蒐集、實時通信、分佈式緩存
MongoDB:
& 須要動態查詢支持
& 須要使用索引而不是 map/reduce功能
& 須要對大數據庫有性能要求
& 須要使用 CouchDB但由於數據改變太頻繁而佔滿內存
Neo4j:
& 適用於圖形一類數據
& 社會關係,公共交通網絡,地圖及網絡拓譜
DDL 數據定義語言 管理庫和表 create,drop,alter等.
DCL 數據控制語言 用戶管理受權 grant,revoke,commit;rollback.
DMC 數據操做語言 針對表裏的數據 insert,delete,update,select
char:定長字符串類型,當存儲時,老是用空格填滿右邊到指定的長度,最大可存儲 1<=M字節<=255
varchar:變長字符串類型,最大可存儲1<=M字節<=255
char(4)讀取的速度要比varchar(4)較快 ,由於它不須要進行計算
create database oldboy character set utf8 collate utf8_general_ci;
grant all on *.* to oldboy@'172.16.1.0/255.255.255.0' identified by 'oldboy123';
1) mysql多實例,簡單理解就是在一臺服務器上,mysql服務開啓多個不一樣的端口(如330六、3307),運行多個服務進程。這些 mysql 服務進程經過不一樣的 socket來監聽不一樣的數據端口,進而互不干涉的提供各自的服務
2) 配置mysql多實例
3) 在一臺服務器上安裝一套MySQL程序,起多個不一樣的端口,經過不一樣的端口來提供服務,這就是MySQL多實例。多實例有兩種配置方法,按照官方的說法,是用一個配置文件,mysqld_multi模塊進行配置,我在工做中喜歡用多個配置文件,多個啓動文件進行配置,主要的區別就是在配置文件裏server_id的區別,端口的區別,路徑的區別(sock路徑的不一樣、數據文件的不一樣),而後初始化的時候指定不一樣的配置文件初始化不一樣的數據庫文件,而後經過不一樣的啓動程序就能夠啓動MySQL了
查看系統環境:
[root@db01 ~]# cat /etc/redhat-release CentOS release 6.8 (Final)
安裝依賴包
yum install ncurses-devel libaio-devel -y rpm -qa ncurses-devel libaio-devel
安裝cmake
yum install cmake -y rpm -qa cmake
設置用戶
useradd -s /sbin/nologin -M mysql id mysql
編譯安裝完mysql以後,以端口爲區分建立多實例庫目錄,編寫實例文件及啓動腳本
基本配置以下:
[root@db02 /]# tree /data /data ├── 3306 │?? ├── my.cnf │?? └── mysql └── 3307 ├── my.cnf └── mysql 2 directories, 4 files mkdir /data/{3306,3307}/data -p chown -R mysql.mysql /data/ find /data -name mysql|xargs chmod 700 find /data -name mysql|xargs ls -l cd /application/mysql/scripts ./mysql_install_db --defaults-file=/data/3306/my.cnf --basedir=/application/mysql/ --datadir=/data/3306/data --user=mysql ./mysql_install_db --defaults-file=/data/3307/my.cnf --basedir=/application/mysql/ --datadir=/data/3307/data --user=mysql echo 'export PATH=/application/mysql/bin:$PATH' >>/etc/profile source /etc/profile /data/3306/mysql start /data/3307/mysql start netstat -lntup|grep 330
& 不設置外網ip
& 爲root用戶設置比較複製的密碼
& 刪除無用的mysql庫內的用戶帳號,只保留root@localhost以及root@127.0.0.1
& 刪除默認的test數據庫
& 增長用戶的時候,受權的權限盡可能最小,容許訪問的主機範圍最小化
& 登陸命令行操做不攜帶密碼,而是回車後輸入密碼
單實例找回密碼:
中止已啓動的mysql服務,而後--skip-grant-tables跳過受權表信息,修改密碼
mysqld_safe --skip-grant-tables --user=mysql & mysql 登陸 update 修改密碼 flush privileges; 多實例找回密碼: /data/3306/mysql stop mysql_safe --defaults-file=/data/3306/my.cnf --skip-grant-tables & myaql -S /data/3306/mysql.sock update mysql.user set password=PASSWORD('oldboy123') where user='root' and host='localhost'; flush privileges; 退出 cd /data/3306 vim mysql mysql_pwd="oldboy123" /data/3306/mysql start mysql -uroot -poldboy123 -S
delete from test:邏輯刪除 語句刪除 一行一行的刪
truncate table test 直接刪物理文件
前者慢後者快
一、配置文件裏修改:
[mysqld]
interactive_timeout = 120 此參數設置後wait_timeout自動生效。
wait_timeout = 120
二、其餘方法:
1.PHP程序中,不使用持久連接,即便用mysql_connect而不是pconnect(JAVA調整鏈接池)。
2.PHP程序執行完畢,應該顯式調用mysql_close。
3.逐步分析MySQL的SQL查詢及慢查詢日誌,找到查詢過慢的SQL,優化之。
mysql -e "show full processlist"|egrep -vi "sleep"
而後多執行幾回看看一樣的語句是否存在,若是存在的話,我會認爲他會有慢的嫌疑,這個是抓慢查詢的方法之一,就是臨時緊急狀況下去抓,第二種狀況下 咱們會在配置文件裏配置三個參數,超過若干秒的查詢,不走索引的查詢,增長慢查詢日誌,天天把慢查詢日誌進行收集,而後經過寫腳本的命令來進行切割,mysqladmin來進行切割,切割完了使用mysqlsla工具進行分析,分析完天天早晨8點,經過定時任務的方式,分析,分析完發給DBA或領導,
http://www.cnblogs.com/zengkefu/p/5600185.html
須要排序 會話 的緩存大小,是針對每個connection的,這個值也不會越大越好,默認大小是256kb,過大的配置會消耗更多的內存
set global sort_buffer_size = 256;
1、沒有主從同步的狀況下清理日誌
mysql -uroot -p123456 -e 'PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ),INTERVAL 5 DAY)';
#mysql 定時清理5天前的binlog
mysql -u root -p #進入mysql 控制檯
reset master; #重置binlog
2、MySQL主從同步下安全清理binlog日誌
一、mysql -u root -p #進入從服務器mysql控制檯
show slave status\G; #檢查從服務器正在讀取哪一個日誌,有多個從服務器,選擇時間最先的一個作爲目標日誌。
二、進入主服務器mysql控制檯
show master log; #得到主服務器上的一系列日誌
PURGE MASTER LOGS TO 'binlog.000058'; #刪除binlog.000005以前的,不包括binlog.000058
PURGE MASTER LOGS BEFORE '2016-06-22 13:00:00'; #清除2016-06-22 13:00:00前binlog日誌
PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY); #清除3天前binlog日誌
3、設置自動清理MySQL binlog日誌
vi /etc/my.cnf #編輯配置
expire_logs_days = 15 #自動刪除15天前的日誌。默認值爲0,表示從不刪除。
log-bin=mysql-bin #註釋掉以後,會關閉binlog日誌
binlog_format=mixed #註釋掉以後,會關閉binlog日誌
:wq! #保存退出
一,模式1 Row Level:日誌中會記錄成每一行數據被修改的形式,而後在slave端再對相同的數據進行修改。
優勢:
row level模式下,bin-log中能夠不記錄執行的sql語句的上下文相關的信息,僅僅只須要記錄那一條記錄被修改了,修改爲什麼樣了。因此row level的日誌內容會很是清楚的記錄下每一行數據修改的細節。且不會出現某些特定狀況下的存儲過程,或function,以及 trigger的調用和觸發沒法被正確複製的問題。
缺點:
row level模式下,全部的執行的語句當記錄到日誌中的時候,都將以每行記錄的修改來記錄,這樣可能會產生大量的日誌內容,好比有這樣一條update語句:update product set owner_member_id = ‘b’ where owner_member_id = ‘a’,執行以後,日誌中記錄的不是這條update語句所對應額事件(MySQL以事件的形式來記錄bin-log日誌),而是這條語句所更新的每一條記錄的變化狀況,這樣就記錄成不少條記錄被更新的不少個事件。天然,bin-log日誌的量就會很大。尤爲是當執行alter table之類的語句的時候,產生的日誌量是驚人的。由於MySQL對於alter table之類的表結構變動語句的處理方式是整個表的每一條記錄都須要變更,實際上就是重建了整個表。那麼該表的每一條記錄都會被記錄到日誌中
二,模式2 Statement Level:每一條會修改數據的sql都會記錄到 master的bin-log中。slave在複製的時候sql進程會解析成和原來master端執行過的相同的sql來再次執行。
優勢:
statement level下的優勢首先就是解決了row level下的缺點,不須要記錄每一行數據的變化,減小bin-log日誌量,節約IO,提升性能。由於他只須要記錄在Master上所執行的語句的細節,以及執行語句時候的上下文的信息。
缺點:
因爲他是記錄的執行語句,因此,爲了讓這些語句在slave端也能正確執行,那麼他還必須記錄每條語句在執行的時候的一些相關信息,也就是上下文信息,以保證全部語句在slave端杯執行的時候可以獲得和在master端執行時候相同的結果。另外就是,因爲MySQL如今發展比較快,不少的新功能不斷的加入,使MySQL得複製遇到了不小的挑戰,天然複製的時候涉及到越複雜的內容,bug也就越容易出現。在statement level下,目前已經發現的就有很多狀況會形成MySQL的複製出現問題,主要是修改數據的時候使用了某些特定的函數或者功能的時候會出現,好比:sleep()函數在有些版本中就不能真確複製,在存儲過程當中使用了last_insert_id()函數,可能會使slave和master上獲得不一致的id等等。因爲row level是基於每一行來記錄的變化,因此不會出現相似的問題。
三,模式3 Mixed
Mixed模式,能夠理解爲是前兩種模式的結合。
Mixed模式下,MySQL會根據執行的每一條具體的sql語句來區分對待記錄的日誌形式,也就是在Statement和Row之間選擇一種。
新版本中的Statment level仍是和之前同樣,僅僅記錄執行的語句。而新版本的MySQL中隊row level模式也被作了優化,並非全部的修改都會以row level來記錄,像遇到表結構變動的時候就會以statement模式來記錄,若是sql語句確實就是update或者delete等修改數據的語句,那麼仍是會記錄全部行的變動。
企業選擇:
一、互聯網公司,使用MySQL的功能相對少(存儲過程、觸發器、函數)。
選擇默認的語句模式,Statement Level(默認)。
二、公司若是用到使用MySQL的特殊功能(存儲過程、觸發器、函數)。
則選擇Mixed模式。
三、公司若是用到使用MySQL的特殊功能(存儲過程、觸發器、函數),又但願數據最大化一致,此時最好Row level模式。
1)首先前提工做要準備充分了(提早備份了)
解壓以後
sed -n "22p" 包名 查看binlog的位置
2)在利用binlog
grep -i drop bin.sql sed -i '/^drop.*/d' bin.sql
(我的理解)
一、使用source命令(工做量感受巨大)
#進入mysql數據庫控制檯,
mysql -u root -p
mysql>use 數據庫
mysql>set names utf8; (先確認編碼,若是不設置可能會出現亂碼,注意不是UTF-8)
#而後使用source命令,後面參數爲腳本文件(如這裏用到的.sql)
mysql>source d:\wcnc_db.sql
二、找一臺測試服務器,把備份好的數據,進行導入,而後進行調整,獲得本身想要的數據,再次備份,最後進行數據恢復;
(正確答案)這就是有經驗與沒經驗的區別
使用mysqlbinlog -d導出要恢復的單表,而後使用導入到數據庫便可
原理:
MySQL 複製基於主服務器在二進制日誌中跟蹤全部對數據庫的更改(更新、刪除等等)。每一個從服務器從主服務器接收主服務器已經記錄到其二進制日誌的保存的更新,以便從服務器能夠對其數據拷貝執行相同的更新。
MySQL 使用3個線程來執行復制功能,其中1個在主服務器上,另兩個在從服務器上。當發出START SLAVE時,從服務器建立一個I/O線程,以鏈接主服務器並讓它發送記錄在其二進制日誌中的語句。
主服務器建立一個線程將二進制日誌中的內容發送到從服務器。該線程能夠識別爲主服務器上SHOW PROCESSLIST的輸出中的Binlog Dump線程。
從服務器I/O線程讀取主服務器Binlog Dump線程發送的內容並將該數據拷貝到從服務器數據目錄中的本地文件中,即中繼日誌。
第3個線程是SQL線程,是從服務器建立用於讀取中繼日誌並執行日誌中包含的更新。
有多個從服務器的主服務器建立爲每一個當前鏈接的從服務器建立一個線程;每一個從服務器有本身的I/O和SQL線程。
1. 複製主線程的狀態
Sending binlog event to slave
二進制日誌由各類事件組成,一個事件一般爲一個更新加一些其它信息。線程已經從二進制日誌讀取了一個事件而且正將它發送到從服務器。
Finished reading one binlog; switching to next binlog
線程已經讀完二進制日誌文件而且正打開下一個要發送到從服務器的日誌文件。
Has sent all binlog to slave; waiting for binlog to be updated
線程已經從二進制日誌讀取全部主要的更新並已經發送到了從服務器。線程如今正空閒,等待由主服務器上新的更新致使的出如今二進制日誌中的新事件。
Waiting to finalize termination
線程中止時發生的一個很簡單的狀態。
2. 複製從I/O線程狀態
Connecting to master
線程正試圖鏈接主服務器。
Checking master version
創建同主服務器之間的鏈接後當即臨時出現的狀態。
Registering slave on master
創建同主服務器之間的鏈接後當即臨時出現的狀態。
Requesting binlog dump
創建同主服務器之間的鏈接後當即臨時出現的狀態。線程向主服務器發送一條請求,索取從請求的二進制日誌文件名和位置開始的二進制日誌的內容。
Waiting to reconnect after a failed binlog dump request
若是二進制日誌轉儲請求失敗(因爲沒有鏈接),線程進入睡眠狀態,而後按期嘗試從新鏈接。可使用–master-connect-retry選項指定重試之間的間隔。
Reconnecting after a failed binlog dump request
線程正嘗試從新鏈接主服務器。
Waiting for master to send event
線程已經鏈接上主服務器,正等待二進制日誌事件到達。若是主服務器正空閒,會持續較長的時間。若是等待持續slave_read_timeout秒,則發生超時。此時,線程認爲鏈接被中斷並企圖從新鏈接。
Queueing master event to the relay log
線程已經讀取一個事件,正將它複製到中繼日誌供SQL線程來處理。
Waiting to reconnect after a failed master event read
讀取時(因爲沒有鏈接)出現錯誤。線程企圖從新鏈接前將睡眠master-connect-retry秒。
Reconnecting after a failed master event read
線程正嘗試從新鏈接主服務器。當鏈接從新創建後,狀態變爲Waiting for master to send event。
Waiting for the slave SQL thread to free enough relay log space
正使用一個非零relay_log_space_limit值,中繼日誌已經增加到其組合大小超過該值。I/O線程正等待直到SQL線程處理中繼日誌內容並刪除部分中繼日誌文件來釋放足夠的空間。
Waiting for slave mutex on exit
線程中止時發生的一個很簡單的狀態。
3. 複製從SQL線程狀態
Reading event from the relay log
線程已經從中繼日誌讀取一個事件,能夠對事件進行處理了。
Has read all relay log; waiting for the slave I/O thread to update it
線程已經處理了中繼日誌文件中的全部事件,如今正等待I/O線程將新事件寫入中繼日誌。
Waiting for slave mutex on exit
線程中止時發生的一個很簡單的狀態。
在my.cnf中加入
[mysqld]
log-slave-updates = 1
log-bin(5.6版本)
優勢:
1. mysql的主從複製的主要優勢是同步"備份", 在從機上的數據庫就至關於一個(基本實時)備份庫.
2. 在主從複製基礎上, 經過mysqlproxy能夠作到讀寫分離, 由從機分擔一些查詢壓力.
3. 作一個雙向的主從複製, 兩臺機器互相爲主機從機, 這樣, 在任何一個機器的庫中寫入, 都會"實時"同步到另外一臺機器, 雙向的優勢在於當一臺主機發生故障時, 另外一臺主機能夠快速的切換過來繼續服務.
步驟:
B同步A,C同步B
A←B←C
在[mysqld]下面加入下面這行
binlog_format=mixed
http://storysky.blog.51cto.com/628458/259280/
必要條件:
& Slave_IO_Running: Yes,這個是I/O線程狀態,I/O線程負責從庫去主庫讀取binlog日誌,並寫入從庫的中繼日誌中,狀態爲Yes表示I/O線程工做正常。
& Slave_SQL_Running: Yes,這個是SQL線程狀態,SQL線程負責讀取中繼日誌(relay-log)中的數據並轉換爲SQL語句應用到從數據庫中,狀態爲Yes表示I/O線程工做正常。
& Seconds_Behind_Master: 0,這個是在複製過程當中,從庫比主庫延遲的秒數,這個參數很重要,但企業裏更準確地判斷主從延遲的方法爲:在主庫時間戳,而後從庫讀取時間戳和當前數據庫時間的進行比較,從而認定是否延遲。
其餘略
1)程序修改mysql操做
2)amoeda
3)mysqlproxy
把備份好的數據導入
利用從庫的備份進行全量恢復,利用本地的binlog進行增量恢復
1)受權不規範
gei用戶受權了all權限,致使開發經過該用戶自行更改了表結構 解決:對比表結構(生產數據和備份的數據)把字段改回去
2)工做中MySQL從庫中止複製故障
stop slave; #<==臨時中止同步開關。
set global sql_slave_skip_counter =1 ; #<==將同步指針向下移動一個,若是屢次不一樣步,能夠重複操做。
start slave;
問題一:一個主庫的從庫太多,致使複製延遲。
建議從庫數量3~5個爲宜,要複製的從節點數量過多,會致使複製延遲。
問題二:從庫硬件比主庫差,致使複製延遲。
查看master和slave的系統配置,可能會由於機器配置的問題,包括磁盤IO、CPU、內存等各方面因素形成複製的延遲,通常發生在高併發大數據量寫入場景。
問題三:慢SQL語句過多。
假如一條SQL語句,執行時間是20秒,那麼從執行完畢,到從庫上能查到數據也至少是20秒,這樣就延遲20秒了。
SQL語句的優化通常要做爲常規工做不斷的監控和優化,若是是單個SQL的寫入時間長,能夠修改後分屢次寫入。經過查看慢查詢日誌或show full processlist命令找出執行時間長的查詢語句或者大的事務。
問題四:主從複製的設計問題。
例如,主從複製單線程,若是主庫寫併發太大,來不及傳送到從庫就會致使延遲。更高版本的MySQL能夠支持多線程複製,門戶網站則會本身開發多線程同步功能。
問題五:主從庫之間的網絡延遲。
主從庫的網卡、網線、鏈接的交換機等網絡設備均可能成爲複製的瓶頸,致使複製延遲,另外,跨公司主從複製很容易致使主從複製延遲。
問題六:主庫讀寫壓力大,致使複製延遲。
主庫硬件要搞好一點,架構的前端要加buffer以及緩存層。
M(VIP)------------------S1 對外提供服務
--------------------S2 對外提供服務
--------------------S3 對外提供服務
--------------------S4 #內網、開發、財務
--------------------S5 #備份
--------------------S6 #延遲複製
M(S1)(VIP)
--------------------S2 對外提供服務
--------------------S3 對外提供服務
--------------------S4 #內網、開發、財務
--------------------S5 #備份
--------------------S6 #延遲複製
M宕機以前要儘量先選好哪臺機器作主:
(一)事先選主
n 首選半同步的S1(S1和M是實時同步的),啥都不幹,乾等。
u 同步:
u 半同步:S1是半同步數據庫,當前的數據庫S1是同步的。
u 異步:主從複製是異步的。
n 事先指定好一個S1,什麼都不幹(百度某個部門)。
n 主庫宕機現選(數據接近主庫的),比對binlog日誌(master.info),文件對應數字最大,pos位置點最大。
& 不選主的危害:還得作角色轉換的工做
& 每一臺從庫都不能設置read-only=1,不能受權鏈接用戶select了。
& 每臺機器都必須開啓binlog。
& 如何提早配好選好的主?
解答:能夠雙主,實現角色對等,方便接管。
(二)主庫宕機角色切換:
主庫宕機,切換從庫,確保爲主的從庫要儘可能和主的數據保持一致。
二、主庫宕機要對數據庫進行數據保全
n 若是SSH連上宕機的主庫服務器
u 將宕機主庫的binlog補全到指定的要提高主庫的從庫S1以及全部的從庫。
u master.info和主庫最新的binlog位置比對。
u 其餘從庫也能夠比對relay-log。
n 若是不能SSH連上宕機的主庫服務器。
u 可能會丟失數據(從庫master.info和主庫宕機最新的binlog位置差值)。
n 臨時補救:
u 以最全的從庫S1爲主庫,而後把這個從庫的中繼日誌數據補全到其餘全部從庫。
n 企業裏補救措施:
一、半同步複製。
二、Web程序把數據同時雙寫到兩臺服務器(例如:1分鐘)*****
三、能夠把binlog實時發到binlog服務器解決主宕機binlog丟失問題。
四、主庫作UPS不間斷,RAID。保證不宕機。
(三)角色切換(角色切換以及主從複製)
先在S1配置好VIP
a.從庫S1提高主庫(主主直接切VIP)。
1)修改從庫配置文件(去掉read-only、開啓binlog、受權鏈接帳號增刪改查)
2)rm -f master.info relay_log*
3)登陸從庫S1,reset master。
4)重啓S1。
b.其它從庫和新的主庫(S1)實現主從複製
登陸新主庫show master status,master.info
在全部從庫上change master to ....
d.實現後的結果
(四)程序鏈接文件(VIP)
若是事先解析的就是VIP,就不用改
/etc/hosts
172.16.1.53 db01_w.etiantian.org
172.16.1.53 db01.etiantian.org
若是軟件實現了讀寫分離,須要改讀寫分離的軟件
寫就發給了S1,讀發給了其它的從庫。
(五)修復損壞的主庫,修好了作從庫,儘可能不要切回
條件:做爲太子的從庫要把主庫硬件要好,不能差。
數據庫事務就是指邏輯上的一組SQL語句操做,組成這組操做的各個SQL語句,執行時要麼全
成功要麼全失敗。
特性:
& 原子性(Atomicity)
事務是一個不可分割的單位,事務中的全部SQL等操做要麼都發生,要麼都不發生
& 一致性(Cinsistency)
事務發生前和發生後,數據的完整性必須保持一致
& 隔離性(Isolation)
當併發訪問數據庫是,一個正在執行的事務在執行完畢前,對於其它的回話是不可見的,多個併發事務之間的數據是相互隔離的。
& 持久性(Durability)
一個事務一旦被提交,它對數據庫中的數據改變就是永久性的,若是出現了錯誤,事務也不容許撤銷,只能經過「補償性事務」
全備:把數據庫中全部的數據(或某個庫的所有數據)進行備份 跟命令scp的原理相似(我的理解)
增備:在原有的數據的基礎上增長沒有的數據內容 跟raync的命令原理相似(我的理解)
冷備:備份時把服務停用(不可讀 不可寫)
熱備:備份時(可讀 可寫)
一、創建索引,包括條件列,鏈接列,外鍵列等
二、讓where中的列順序與符合索引的列順序一致
三、儘可能不要select *,而只列出本身須要的字段列表
四、減小子查詢的層數
五、在子查詢的過程當中進行數據篩選
六、對大數據表刪除時,用truncate table代替delete
1)邏輯備份的特色 應用場景:不大於30G
2)物理備份的特色
(我的理解)
1)開發以打包郵件的形式發送給DBA
2)DBA收到以後先解壓
3)大體查看SQL語句
4)執行時查看執行的過程
& 對於已有的數據庫想修改字符集不能直接用‘alter database character set *’或‘alter table tablename character set *’,這兩個命令都沒有更新已有記錄的字符集,而只是對新建立的表或者記錄生效。
& 生產線中須要調整MySQL數據庫的字符集:須要先將數據導出,通過修改字符集後從新導入後纔可完成
原理:字符集環境不統一致使中文亂碼。 (我的理解)
防止亂碼:
一、儘可能不在MySQL命令行直接插入數據
二、可在MySQL命令行中用source執行sql文件
三、命令方式導入數據mysql –uroot –poldboy123 oldboy <test.sql
四、Sql文件的格式用utf8沒有簽名
五、Sql文件裏set names utf8,或mysql –uroot –poldboy oldboy –default-character-set=utf8 <test.sql
六、建議中英文環境選擇utf8
經常使用客戶端工具,mysqlfront , navicat , sql yog ...
根據功能選擇表類型 innodb myisam
根據查詢需求 建立表索引
程序查詢 查詢須要的字段
數據量大 ,分庫分表,水平垂直拆分.
(我的理解)
優化sql語句,若是是數據庫慢了,咱們會登陸到數據庫上面去,show proact list;或者是show procter list;可是我習慣在web服務器mysql -e show procter list 去把skip進程給grep -v掉,而後多執行幾回看看一樣的語句是否存在,若是存在的話,我會認爲他會有慢的嫌疑,這個是抓慢查詢的方法之一,就是臨時緊急狀況下去抓,第二種狀況下 咱們會在配置文件裏配置三個參數,超過若干秒的查詢,不走索引的查詢,增長慢查詢日誌,天天把慢查詢日誌進行收集,而後經過寫腳本的命令來進行切割,mysqladmin flas來進行切割,切割完了使用mysql soa工具進行分析,分析完天天早晨8點,經過定時任務的方式,分析,分析完發給DBA或領導,臨時抓sql語句的方法sor,按期的分析記錄慢查詢日誌的方式,抓到慢查詢了,咱們要進行優化,優化最基本的就是建立索引,如何知道建立合適的索引,咱們會使用explain這個命令,加在慢查詢語句的前面,同時加上參數sqlnocash\G,看看它是否是走索引,其中有一個pospkey和key,key是真正的沒有走索引,沒有走索引的話,咱們會針對where和條件的列設置索引,alter create建立索引
mysqldump備份時加上-B參數,不全備,指定庫或表進行備份,恢復時指定可指定多個庫進行恢復
SET @DATABASE_NAME = 'name_of_your_db'; SELECT CONCAT('ALTER TABLE `', table_name, '` ENGINE=InnoDB;') AS sql_statements FROM information_schema.tables AS tb WHERE table_schema = @DATABASE_NAME AND `ENGINE` = 'MyISAM' AND `TABLE_TYPE` = 'BASE TABLE' ORDER BY table_name DESC;
(我的理解)
1) 把須要更改字符集的數據庫導出sed進行修改字符集
2) 再次導入
首先查詢sql語句,若是是數據庫慢了,咱們會登陸到數據庫上面去,show proact list;或者是show procter list;可是我習慣在web服務器mysql -e show procter list 去把skip進程給grep -v掉,而後多執行幾回看看一樣的語句是否存在,若是存在的話,我會認爲他會有慢的嫌疑,這個是抓慢查詢的方法之一,就是臨時緊急狀況下去抓,第二種狀況下 咱們會在配置文件裏配置三個參數,超過若干秒的查詢,不走索引的查詢,增長慢查詢日誌,天天把慢查詢日誌進行收集,而後經過寫腳本的命令來進行切割,mysqladmin flas來進行切割,切割完了使用mysqlsla工具進行分析,分析完天天早晨8點,經過定時任務的方式,分析,分析完發給DBA或領導,臨時抓sql語句的方法sor,按期的分析記錄慢查詢日誌的方式,抓到慢查詢了,咱們要進行優化,優化最基本的就是建立索引,如何知道建立合適的索引,咱們會使用explain這個命令,加在慢查詢語句的前面,同時加上參數sqlnocash\G,看看它是否是走索引,其中有一個pospkey和key,key是真正的沒有走索引,沒有走索引的話,咱們會針對where和條件的列設置索引,alter create建立索引
官方原理
在InnoDB內部會維護一個redo日誌文件,咱們也能夠叫作事務日誌文件。事務日誌會存儲每個InnoDB表數據的記錄修改。當InnoDB啓動時,InnoDB會檢查數據文件和事務日誌,並執行兩個步驟:它應用(前滾)已經提交的事務日誌到數據文件,並將修改過但沒有提交的數據進行回滾操做。
http://sofar.blog.51cto.com/353572/1313649
1 xtrabackup只能備份innodb和xtradb兩種引擎的表,而不能備份myisam引擎的表;
徹底備份集的恢復。
& 在InnoDB表的備份或者更直接的說ibd數據文件複製的過程當中,數據庫處於不一致的狀態,因此要將xtraback_logfile中還沒有提交的事務進行回滾,以及將已經提交的事務進行前滾,使各個數據文件處於一個一致性狀態,這個過程叫作「準備(prepare)」
& 若是你是在一個從庫上執行的備份,那說明你沒有東西須要回滾,只是簡單的apply redo log就能夠了。另外在prepare過程當中可使用參數--use-memory增大使用系統內存量從而提升恢復速度。
& 以後,咱們就能夠根據backup-my.cnf中的配置把數據文件複製回對應的目錄了,固然你也能夠本身複製回去,但innobackupex都會幫咱們完成。在這裏,對於InnoDB表來講是完成「後準備」動做,咱們稱之爲「恢復(recovery)」,而對於MyISAM表來講因爲備份時是採用鎖表方式複製的,因此此時只是簡單的複製回來,不須要apply log,這個咱們稱之爲「還原(restore)」。
增量備份的恢復過程:
& 恢復過程須要使用徹底備份集和各個增量備份集,各個備份集的恢復與前面說的同樣(前滾和回滾),以後各個增量備份集的redo log都會應用到徹底備份集中;
& 對於徹底備機集以後產生的新表,要有特殊處理方式,以便恢復後不丟表;
& 要以徹底備份集爲基礎,而後按順序應用各個增量備份集。
pt-table-checksum是一個在線驗證主從數據一致性的工具,主要用於如下場景:
1. 數據遷移先後,進行數據一致性檢查
2. 當主從複製出現問題,待修復完成後,對主從數據進行一致性檢查
3. 把從庫當成主庫,進行數據更新,產生了"髒數據"
4. 按期校驗
http://blog.chinaunix.net/uid-16844903-id-3360228.html
1、普通索引 這是最基本的索引,它沒有任何限制。 ...
2、惟一索引 它與前面的普通索引相似,不一樣的就是:索引列的值必須惟 一...
3、主鍵索引 它是一種特殊的惟一索引,不容許有空值。
mysqld_safe --defaults-file=/data/${port}/my.cnf --pid-file=$mysqld_pid_file_path
read mysqld_pid < "$mysqld_pid_file_path" #pid的文件 kill -HUP $mysqld_pid && log_success_msg "Reloading service MySQL" touch "$mysqld_pid_file_path"
1)單實例
/etc/init.d/mysqld start
3) 多實例
/data/端口/myql start
1、ps -ef|grep mysqld 2、lsof -i:3306
初始化設置密碼: mysqladmin -uroot password oldboy123 修改密碼: mysqladmin -uroot -poldboy123 password 123456
單實例:
mysql -uroot -poldboy123
多實例:
mysql -uroot –poldboy123 –S /data/3306/mysql.sock
mysql> show variables like "character_set_%";
mysql> create database oldboy character set gbk collate gbk_chinese_ci; mysql> show create database oldboy\G
mysql> grant all on oldboy.* to 'oldboy'@'localhost' identified by 'oldboy123'; 建立帶受權
mysql> show grants for oldboy@'localhost'\G *************************** 1. row *************************** Grants for oldboy@localhost: GRANT USAGE ON *.* TO 'oldboy'@'localhost' IDENTIFIED BY PASSWORD '*FE28814B4A8B3309DAC6ED7D3237ADED6DA1E515' *************************** 2. row *************************** Grants for oldboy@localhost: GRANT ALL PRIVILEGES ON `oldboy`.* TO 'oldboy'@'localhost' 2 rows in set (0.00 sec)
mysql> select user,host from mysql.user;
mysql> use oldboy;
Database changed
mysql> create table test( id int(4), name varchar(16) ) ENGINE=innodb default charset=gbk; gbk'字符集
mysql> desc test;
mysql> select * from test; Empty set (0.00 sec) mysql> insert into test values(1,'oldboy'); mysql> select * from test;
mysql> insert into test values(2,'老男孩'),(3,'oldboyedu');
mysql> select * from test where name='oldboy';
mysql> update test set name='oldgirl' where id=1;
mysql> alter table test add age tinyint(2) after id;
mysql> system mysqldump -uroot -poldboy123 -B oldboy >/opt/oldboy.sql
mysql> delete from test; mysql> truncate table test; mysql> select * from test;
(我的理解)刪除oldboy庫test表也就刪除了 但題目要求 就跟着題目要求來
mysql> drop table test; mysql> show tables; mysql> drop database oldboy; mysql> show databases;
mysql> system mysql </opt/oldboy.sql
mysql> alter table test add primary key(id); mysql> create index index_name on test(name); 或者 alter table test add index index_name(name)
mysql> alter table test add shouji char(11);
mysql> insert into test values(4,24,'xjc','18796965487'),(5,18,'oldboy','13556897512');
mysql> select * from test where name='oldboy' and shouji like "135%";
mysql> revoke select on oldboy.* from 'oldboy'@'localhost';
mysql> drop user 'oldboy'@'localhost';
mysql> drop database oldboy;
[root@db02 ~]# mysqladmin -uroot -poldboy123 shutdown
[root@db02 ~]# netstat -lntup|grep mysql
1)單實例找回密碼 [root@db02 ~]# mysqld_safe --skip-grant-tables --user=mysql & [root@db02 ~]# mysql mysql> update mysql.user set password=password('oldboy123') where user='root' and host='localhost'; [root@db02 ~]# /etc/init.d/mysqld restart [root@db02 ~]# mysql -uroot -poldboy123
2)多實例找回密碼
/data/3306/mysql stop mysql_safe --defaults-file=/data/3306/my.cnf --skip-grant-tables & myaql -S /data/3306/mysql.sock update mysql.user set password=PASSWORD('oldboy123') where user='root' and host='localhost'; flush privileges; 退出 cd /data/3306 vim mysql mysql_pwd="oldboy123" /data/3306/mysql start mysql -uroot -poldboy123 -S
mysql> system mysql </opt/oldboy.sql mysql> use oldboy; show index from test\G
explain select * from test where name='oldboy' and shouji like '135%'\G
show create table test\G alter table test ENGINE=MYISAM; show create table test\G
alter table test add index index_name_shouji(name(6),shouji(8)); show index from test\G