淺談Mysql高可用，DBA們將如何應(yīng)對(duì)？

demilich

好書(shū)，占樓先 ...

王楠w_n

這回復(fù)。。。。。回復(fù) 3# demilich


   

seesea2517

1. 如果是你，你怎么處理慢查詢引起的問(wèn)題，并且在以后避免這種情況發(fā)生？
  我們一般是這樣處理的：根據(jù)show出來(lái)的查詢語(yǔ)句內(nèi)容以及用戶名去找到相關(guān)的查詢發(fā)起者，詢問(wèn)使用目的以及是否可以殺掉，一般來(lái)說(shuō)同事都會(huì)理解同意殺掉的，不同意那就約定一下再等多久非殺不可；并請(qǐng)發(fā)起者優(yōu)化查詢，有需要找到開(kāi)發(fā)增加索引之類的，以及與發(fā)起者溝通把查詢時(shí)間放在服務(wù)器空閑的時(shí)候，或者使用從庫(kù)查詢，或是使用備份數(shù)據(jù)來(lái)查詢。

2. 除了慢查詢，還有哪些情況會(huì)導(dǎo)致MySQL卡頓，查詢較慢？
  有時(shí)候是由于磁盤(pán) IO 慢導(dǎo)致查詢慢了�？赡苓�有其它并發(fā)讀寫(xiě)磁盤(pán)、其它進(jìn)程搶占 CPU 等情況，但我們的數(shù)據(jù)庫(kù)是單獨(dú)運(yùn)行在一臺(tái)機(jī)器上的，所以沒(méi)有遇到其它的可能情況。

3. 針對(duì)于數(shù)據(jù)庫(kù)優(yōu)化，您有哪些比較實(shí)用的建議和想法？
  很多的方案都從書(shū)上讀來(lái)的，用得多的還是根據(jù)數(shù)據(jù)查詢、寫(xiě)入等的使用情況來(lái)設(shè)計(jì)合理的索引。

4. 結(jié)合生產(chǎn)環(huán)境，您覺(jué)得 MySQL，較于PG NOsql DB2 Sybase MongoDB Oracle等數(shù)據(jù)庫(kù)來(lái)，他的優(yōu)點(diǎn)在哪？在什么情況下你會(huì)使用其它類型的DB
  咱是因?yàn)槊赓M(fèi)而用的 MySQL，而且有很多不同的引擎可以根據(jù)應(yīng)用場(chǎng)景選用，挺靈活的。
  我們的應(yīng)用是 MySQL 與 SQLite 并且，當(dāng)遠(yuǎn)程的 MySQL 不能連接的時(shí)候?qū)⑿枰�保存的�?shù)據(jù)暫存在本地的 SQLite 里，等可以訪問(wèn)遠(yuǎn)程 MySQL 的時(shí)候再自動(dòng)把本地的數(shù)據(jù)傳上去。
  
5. 如果您是數(shù)據(jù)庫(kù)的設(shè)計(jì)者，您會(huì)去怎么設(shè)計(jì)數(shù)據(jù)庫(kù)的引擎和結(jié)構(gòu)？
  不在其位不謀其政，不是不想謀，而是經(jīng)驗(yàn)水平知識(shí)技能等不夠，咱就會(huì)幾句 select，所以這個(gè)問(wèn)題只能遠(yuǎn)觀啊，總的來(lái)說(shuō)底層設(shè)計(jì)都是為上層服務(wù)的，根據(jù)上層應(yīng)用的需求來(lái)考慮，比如主要以備份為目的只查詢的，用列存儲(chǔ)；隨機(jī)存取的用哈希；追求速度的用內(nèi)存等等。

xdsnet

占樓觀望高手們表演

skykiker

1. 如果是你，你怎么處理慢查詢引起的問(wèn)題，并且在以后避免這種情況發(fā)生？
  想看這條SQL本身慢是否合理，再看這條SQL的存在性是否合理，要和開(kāi)發(fā)確認(rèn)這條SQL的目的。

2. 除了慢查詢，還有哪些情況會(huì)導(dǎo)致MySQL卡頓，查詢較慢？         
可能到了系統(tǒng)資源瓶頸，CPU，IO，MEM，network。還有可能程序設(shè)計(jì)不當(dāng)，過(guò)于頻繁的查詢，1個(gè)操作執(zhí)行N個(gè)SQL。遇到過(guò)1個(gè)操作發(fā)行1w多個(gè)SQL的奇葩例子，那些SQL是ORM自動(dòng)生成的。還遇到過(guò)一個(gè)另一個(gè)奇葩的例子，應(yīng)用開(kāi)發(fā)人員為了減輕DB的壓力，想當(dāng)然的把本該在服務(wù)端做的復(fù)雜查詢放到了應(yīng)用端計(jì)算，結(jié)果引發(fā)了大量的網(wǎng)絡(luò)交互把系統(tǒng)拖死，后來(lái)這個(gè)問(wèn)題通過(guò)物化視圖解決了（那是Oracle的案例，MySQL不支持物化視圖）。

3. 針對(duì)于數(shù)據(jù)庫(kù)優(yōu)化，您有哪些比較實(shí)用的建議和想法？
  首先要結(jié)合應(yīng)用設(shè)計(jì)，數(shù)據(jù)表設(shè)計(jì)，緩存，索引在設(shè)計(jì)上優(yōu)化。其次才是數(shù)據(jù)庫(kù)層的參數(shù)調(diào)優(yōu)之類。

4. 結(jié)合生產(chǎn)環(huán)境，您覺(jué)得 MySQL，較于PG NOsql DB2 Sybase MongoDB Oracle等數(shù)據(jù)庫(kù)來(lái)，他的優(yōu)點(diǎn)在哪？在什么情況下你會(huì)使用其它類型的DB
  MySQL較PG的優(yōu)點(diǎn)是用的人多，DBA好找，除此以外我找不到任何MySQL明顯比PG強(qiáng)的地方！單純從數(shù)據(jù)庫(kù)本身選型，基本上任何適合MySQL的場(chǎng)景都適合用PG，而且很多時(shí)候是更適合用PG。因?yàn)镻G的功能特性，可靠性和綜合性能都遠(yuǎn)遠(yuǎn)強(qiáng)與MySQL。
  為什么這么說(shuō)？功能特性方面，對(duì)比一下PG手冊(cè)和MySQL手冊(cè)上的功能自然就會(huì)明白，另外PG對(duì)JSON的完美支持使之可以完全替代MongoDB(MySQL 5.7對(duì)JSON的支持是不完整的)�？煽啃苑矫妫琍G的對(duì)數(shù)據(jù)一致性有嚴(yán)格的保護(hù)，同步流復(fù)制可以輕松確保HA集群數(shù)據(jù)不丟，實(shí)際案例也證明，PG很少會(huì)宕機(jī)，而且宕機(jī)后也很少會(huì)起不來(lái)或丟數(shù)據(jù)(硬盤(pán)沒(méi)有壞掉的前提下)。而使用MySQL的復(fù)制技術(shù)做HA，要確保不丟數(shù)據(jù)需要在部署上花很大的功夫。至于性能，非常簡(jiǎn)單的查詢兩者相差不大，復(fù)雜一些的查詢PG會(huì)把MySQL遠(yuǎn)遠(yuǎn)甩在后面。PG還有非常豐富的索引，甚至可以定制索引以應(yīng)對(duì)以前沒(méi)人見(jiàn)過(guò)的場(chǎng)景。最后一點(diǎn)，有些公司不敢上PG是因?yàn)檎也坏接薪?jīng)驗(yàn)的PG DBA，實(shí)際上PG沒(méi)有MySQL那么多坑，不需要多少踩坑經(jīng)驗(yàn)，對(duì)著手冊(cè)就可以輕松部署，當(dāng)然也可以找提供PG第3方服務(wù)的公司協(xié)助。
  
5. 如果您是數(shù)據(jù)庫(kù)的設(shè)計(jì)者，您會(huì)去怎么設(shè)計(jì)數(shù)據(jù)庫(kù)的引擎和結(jié)構(gòu)？
  極少有業(yè)務(wù)已經(jīng)到了現(xiàn)有的任何一個(gè)數(shù)據(jù)庫(kù)無(wú)法滿足需求，要重新設(shè)計(jì)一個(gè)數(shù)據(jù)庫(kù)的地步。真有的話看業(yè)務(wù)場(chǎng)景吧！

jieforest

1.如果是你，你怎么處理慢查詢引起的問(wèn)題，并且在以后避免這種情況發(fā)生？
對(duì)于MySQL的慢查詢問(wèn)題，通常我們是這么干的：
1）開(kāi)啟MySQL服務(wù)器的慢查詢記錄功能
mysql> set global slow_query_log=ON;
mysql> show variables like "slow%";
+---------------------+------------------------------------+
| Variable_name       | Value                              |
+---------------------+------------------------------------+
| slow_launch_time    | 2                                  |
| slow_query_log      | ON                                 |
| slow_query_log_file | /opt/mysql/data/sql-slow.log |
+---------------------+------------------------------------+
3 rows in set (0.00 sec)
2）出現(xiàn)慢查詢問(wèn)題后，查看慢查詢?nèi)罩?opt/mysql/data/sql-slow.log
3）分析具體的問(wèn)題，進(jìn)行相應(yīng)的處理。

2.除了慢查詢，還有哪些情況會(huì)導(dǎo)致MySQL卡頓，查詢較慢？
導(dǎo)致MySQL緩慢的因素有很多。比如：
1）DB數(shù)據(jù)模型設(shè)計(jì)不佳，長(zhǎng)期運(yùn)行后緩慢；
2）MySQL未做優(yōu)化
比如默認(rèn)的max_connections是150，可根據(jù)實(shí)際情況調(diào)整
又比如innodb_buffer_pool_size的設(shè)置，MySQL的優(yōu)化點(diǎn)有很多
3）Linux服務(wù)器OS未做優(yōu)化：內(nèi)核參數(shù)、網(wǎng)絡(luò)參數(shù)都需要根據(jù)實(shí)際情況調(diào)優(yōu)
比如打開(kāi)文件數(shù)，默認(rèn)是1024，不能不優(yōu)化
4）MySQL服務(wù)器的硬件可作優(yōu)化：存儲(chǔ)采用SSD等
5）網(wǎng)絡(luò)帶寬因素等

3.針對(duì)于數(shù)據(jù)庫(kù)優(yōu)化，您有哪些比較實(shí)用的建議和想法？
對(duì)于MySQL數(shù)據(jù)庫(kù)的優(yōu)化，可以跟隨Percona的腳步，他們的優(yōu)化做得非常好。
MariaDB也可以考慮。

4.結(jié)合生產(chǎn)環(huán)境，您覺(jué)得MySQL，較于PG NOsql DB2 Sybase MongoDB Oracle等數(shù)據(jù)庫(kù)來(lái)，他的優(yōu)點(diǎn)在哪？在什么情況下你會(huì)使用其它類型的DB
相比PG NOsql DB2 Sybase MongoDB Oracle等數(shù)據(jù)庫(kù)，MySQL穩(wěn)定、免費(fèi)、易用，使用它可以減少開(kāi)發(fā)時(shí)間，而且它也靠得住。

5.如果您是數(shù)據(jù)庫(kù)的設(shè)計(jì)者，您會(huì)去怎么設(shè)計(jì)數(shù)據(jù)庫(kù)的引擎和結(jié)構(gòu)？
這方面沒(méi)做過(guò)。對(duì)于MySQL引擎，一般我選擇InnoDB引擎或者是XtraDB引擎，并做好優(yōu)化即可。
未做深入。

xpk

看起啦是本好書(shū)，占個(gè)樓留個(gè)名就OK了 ， 準(zhǔn)備自己買一本靠譜點(diǎn)！坐觀各位看官點(diǎn)評(píng)！

   

rtm009

一直不喜歡mysql的路過(guò)