創(chuàng)建主備的環(huán)境變量文件, 因為是在同一臺機上起兩個PG實例, 環(huán)境變量要各自設置。
公司主營業(yè)務：成都網(wǎng)站建設、成都網(wǎng)站制作、移動網(wǎng)站開發(fā)等業(yè)務。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出紹興免費做網(wǎng)站回饋大家。
vi master.env
vi slave.env
新開一個shell終端(后續(xù)稱為 terminal_master )
新開一個shell終端(后續(xù)稱為 terminal_slave )
經(jīng)過上面幾步, 一個一主一備的集群就搭建好了, 下面開始驗證流復制是否工作正常。
切換到 terminal_master 終端
切換到 terminal_slave 終端
一個false一個tree, 證明目前主備狀態(tài)正常。
切換到 terminal_slave 終端
切換到 terminal_master 終端
切換到 terminal_slave 終端
DDL能順利同步。
切換到 terminal_slave 終端
切換到 terminal_master 終端
切換到 terminal_slave 終端
切換到 terminal_master 終端
切換到 terminal_slave 終端
切換到 terminal_master 終端
主備切換完成, 且數(shù)據(jù)同步工作正常。
目前雖然工作正常, 但是角色是互換了的, 后續(xù)可以停掉 slave ,再做一次主備切換, 恢復成原始狀態(tài)。
這個就作為練習了, 不再貼出操作步驟。
目前是靠手工切換主備的, 線上系統(tǒng)一般都要配置成自動切換, 這個時候就需要引入一些其他手段了, 譬如 patroni 之類的HA工具。
很長時間以來，關系型數(shù)據(jù)庫一直是大公司的專利，市場被Oracle/DB2等企業(yè)數(shù)據(jù)庫牢牢把持。
但是隨著互聯(lián)網(wǎng)的崛起、開源社區(qū)的發(fā)展，上世紀九十年代MySQL1.0的發(fā)布，標志著關系型數(shù)據(jù)庫的領域社區(qū)終于有可選擇的方案。
MySQL第一個介紹的單機RDBMS就是MySQL。
相信大多數(shù)朋友都已經(jīng)對MySQL非常熟悉，基本上MySQL的成長史就是互聯(lián)網(wǎng)的成長史。
我接觸的第一個MySQL版本是MySQL4.0，到后來的MySQL5.5更是經(jīng)典——基本所有的互聯(lián)網(wǎng)公司都在使用。
MySQL也普及了「可插拔」引擎這一概念，針對不同的業(yè)務場景選用不同的存儲引擎是MySQLtuning的一個重要的方式。
比如對于有事務需求的場景使用InnoDB;對于并發(fā)讀取的場景MyISAM可能比較合適;但是現(xiàn)在我推薦絕大多數(shù)情況還是使用InnoDB，畢竟5.6后已經(jīng)成為了官方的默認引擎。
大多數(shù)朋友都基本知道什么場景適用MySQL(幾乎所有需要持久化結構化數(shù)據(jù)的場景)，我就不贅述了。
另外值得一提的是MySQL5.6中引入了多線程復制和GTID，使得故障恢復和主從的運維變得比較方便。
另外，5.7(目前處于GA版本)是MySQL的一個重大更新，主要是讀寫性能和復制性能上有了長足的進步(在5.6版本中實現(xiàn)了SCHEMA級別的并行復制，不過意義不大，倒是MariaDB的多線程并行復制大放異彩，有不少人因為這個特性選擇MariaDB。
MySQL5.7MTS支持兩種模式，一種是和5.6一樣，另一種則是基于binloggroupcommit實現(xiàn)的多線程復制，也就是MASTER上同時提交的binlog在SLE端也可以同時被apply，實現(xiàn)并行復制)。
如果有單機數(shù)據(jù)庫技術選型的朋友，基本上只需要考慮5.7或者MariaDB就好了，而且5.6、5.7由Oracle接手后，性能和穩(wěn)定性上都有了明顯的提升。
PostgreSQLPostgreSQL的歷史也非常悠久，其前身是UCB的Ingres，主持這個項目的MichaelStronebraker于2015年獲得圖靈獎。
后來項目更名為Post-Ingres，項目基于BSDlicense下開源。
1995年幾個UCB的學生為Post-Ingres開發(fā)了SQL的接口，正式發(fā)布了PostgreSQL95，隨后一步步在開源社區(qū)中成長起來。
和MySQL一樣，PostgreSQL也是一個單機的關系型數(shù)據(jù)庫，但是與MySQL方便用戶過度擴展的SQL文法不一樣的是，PostgreSQL的SQL支持非常強大，不管是內(nèi)置類型、JSON支持、GIS類型以及對于復雜查詢的支持，PL/SQL等都比MySQL強大得多，而且從代碼質(zhì)量上來看，PostgreSQL的代碼質(zhì)量是優(yōu)于MySQL的，另外相對于MySQL5.7以前的版本，PostgreSQL的SQL優(yōu)化器比MySQL強大很多，幾乎所有稍微復雜的查詢PostgreSQL的表現(xiàn)都優(yōu)于MySQL。
從近幾年的趨勢上來看，PostgreSQL的勢頭也很強勁，我認為PostgreSQL的不足之處在于沒有MySQL那樣強大的社區(qū)和群眾基礎。
MySQL經(jīng)過那么多年的發(fā)展，積累了很多的運維工具和最佳實踐，但是PostgreSQL作為后起之秀，擁有更優(yōu)秀的設計和更豐富的功能。
電腦培訓發(fā)現(xiàn)PostgreSQL9以后的版本也足夠穩(wěn)定，在做新項目技術選型的時候，是一個很好的選擇。
另外也有很多新的數(shù)據(jù)庫項目是基于PostgreSQL源碼的基礎上進行二次開發(fā)，比如Greenplum等。
PostgreSQL9.4帶來了全新的NoSQL特性，并且根據(jù)EnterpriseDB的測試，其加載，插入和查詢的性能都已經(jīng)幾倍于MongoDB了。
雖然我是PG的鐵桿粉絲，但是關系數(shù)據(jù)庫背負了ACID的重型裝甲，在性能上居然能打敗輕裝上陣的NoSQL數(shù)據(jù)庫總覺得有點離譜。
所以我在自己的環(huán)境里驗證了一下EnterpriseDB的測試結果，并且小探一下PG取勝的原因。
1. EnterpriseDB的測試結果
以下是EnterpriseDB的測試結果(數(shù)據(jù)量為5000萬)
（還可以參考這篇譯文： ）
2. 我的驗證結果
測試觀點
為了使測試結果更加單純，我準備單純比拼CPU消耗(盡量排除IO和網(wǎng)絡的干擾)，設定以下測試條件。
1）所有數(shù)據(jù)都要放進內(nèi)存
2）C/S都跑在同一臺單機上
所以，只在單機上進行10萬條小數(shù)據(jù)量的測試。
注）EnterpriseDB的測試環(huán)境是32G內(nèi)存的Amazon Web Services M3.2XLARGE實例，總數(shù)據(jù)量超過內(nèi)存了。
測試環(huán)境
測試環(huán)境為個人PC上的VMware虛擬機
PC
CPU:Intel Core i5-3470 3.2G(4核)
MEM:6GB
SSD:OCZ-VERTEX4 128GB(VMware虛擬機所在磁盤，非系統(tǒng)盤)
OS:Win7
VMware虛擬機
CPU:4核
MEM:1GB
OS:CentOS 6.5
PG:PostgreSQL 9.4.0(shared_buffers = 428MB,其他是默認值)
MG:MongoDB 3.0.2
測試步驟
測試步驟非常簡單,可以參考：
但是，在測試前，有些東西要改。
1)把數(shù)據(jù)量減小到10萬
pg_nosql_benchmark-master/pg_nosql_benchmark:
declare -a json_rows=(10000000)
==
declare -a json_rows=(100000)
2)修改mongo的一處腳本(注)
pg_nosql_benchmark-master/lib/mongo_func_lib.sh:
collectionsize="$(echo ${output}|awk -F"," '{print $5}'|cut -d":" -f2)"
==
collectionsize="$(echo ${output}|awk -F"," '{print $6}'|cut -d":" -f2)"
注)pg_nosql_benchmark原來是基于MongoDB 2.6設計的，MongoDB 3.0的db.json_tables.stats()輸出可能變了，所以這邊要修改一下。
一、 PostgreSQL 的穩(wěn)定性極強， Innodb 等引擎在崩潰、斷電之類的災難場景下抗打擊能力有了長足進步，然而很多 MySQL 用戶都遇到過Server級的數(shù)據(jù)庫丟失的場景——mysql系統(tǒng)庫是MyISAM的，相比之下，PG數(shù)據(jù)庫這方面要好一些。
二、任何系統(tǒng)都有它的性能極限，在高并發(fā)讀寫，負載逼近極限下，PG的性能指標仍可以維持雙曲線甚至對數(shù)曲線，到頂峰之后不再下降，而 MySQL 明顯出現(xiàn)一個波峰后下滑（5.5版本之后，在企業(yè)級版本中有個插件可以改善很多，不過需要付費）。
三、PG 多年來在 GIS 領域處于優(yōu)勢地位，因為它有豐富的幾何類型，實際上不止幾何類型，PG有大量字典、數(shù)組、bitmap 等數(shù)據(jù)類型，相比之下mysql就差很多，instagram就是因為PG的空間數(shù)據(jù)庫擴展POSTGIS遠遠強于MYSQL的my spatial而采用PGSQL的。
四、PG 的“無鎖定”特性非常突出，甚至包括 vacuum 這樣的整理數(shù)據(jù)空間的操作，這個和PGSQL的MVCC實現(xiàn)有關系。
五、PG 的可以使用函數(shù)和條件索引，這使得PG數(shù)據(jù)庫的調(diào)優(yōu)非常靈活，mysql就沒有這個功能，條件索引在web應用中很重要。
六、PG有極其強悍的 SQL 編程能力（9.x 圖靈完備，支持遞歸?。?，有非常豐富的統(tǒng)計函數(shù)和統(tǒng)計語法支持，比如分析函數(shù)（ORACLE的叫法，PG里叫window函數(shù)），還可以用多種語言來寫存儲過程，對于R的支持也很好。這一點上MYSQL就差的很遠，很多分析功能都不支持，騰訊內(nèi)部數(shù)據(jù)存儲主要是MYSQL，但是數(shù)據(jù)分析主要是HADOOP+PGSQL。
七、PG 的有多種集群架構可以選擇，plproxy 可以支持語句級的鏡像或分片，slony 可以進行字段級的同步設置，standby 可以構建WAL文件級或流式的讀寫分離集群，同步頻率和集群策略調(diào)整方便，操作非常簡單。
八、一般關系型數(shù)據(jù)庫的字符串有限定長度8k左右，無限長 TEXT 類型的功能受限，只能作為外部大數(shù)據(jù)訪問。而 PG 的 TEXT 類型可以直接訪問，SQL語法內(nèi)置正則表達式，可以索引，還可以全文檢索，或使用xml xpath。用PG的話，文檔數(shù)據(jù)庫都可以省了。
九，對于WEB應用來說，復制的特性很重要，mysql到現(xiàn)在也是異步復制，pgsql可以做到同步，異步，半同步復制。還有mysql的同步是基于binlog復制，類似oracle golden gate,是基于stream的復制，做到同步很困難，這種方式更加適合異地復制，pgsql的復制基于wal，可以做到同步復制。同時，pgsql還提供stream復制。
十，pgsql對于numa架構的支持比mysql強一些，比MYSQL對于讀的性能更好一些，pgsql提交可以完全異步，而mysql的內(nèi)存表不夠?qū)嵱茫ㄒ驗楸礞i的原因）
最后說一下我感覺 PG 不如 MySQL 的地方。
第一，MySQL有一些實用的運維支持，如 slow-query.log ，這個pg肯定可以定制出來，但是如果可以配置使用就更好了。
第二是mysql的innodb引擎，可以充分優(yōu)化利用系統(tǒng)所有內(nèi)存，超大內(nèi)存下PG對內(nèi)存使用的不那么充分，
第三點，MySQL的復制可以用多級從庫，但是在9.2之前，PGSQL不能用從庫帶從庫。
第四點，從測試結果上看，mysql 5.5的性能提升很大，單機性能強于pgsql，5.6應該會強更多.
第五點，對于web應用來說,mysql 5.6 的內(nèi)置MC API功能很好用，PGSQL差一些。
另外一些：
pgsql和mysql都是背后有商業(yè)公司，而且都不是一個公司。大部分開發(fā)者，都是拿工資的。
說mysql的執(zhí)行速度比pgsql快很多是不對的，速度接近，而且很多時候取決于你的配置。
對于存儲過程，函數(shù)，視圖之類的功能，現(xiàn)在兩個數(shù)據(jù)庫都可以支持了。
另外多線程架構和多進程架構之間沒有絕對的好壞，oracle在unix上是多進程架構，在windows上是多線程架構。
很多pg應用也是24/7的應用，比如skype. 最近幾個版本VACUUM基本不影響PGSQL 運行，8.0之后的PGSQL不需要cygwin就可以在windows上運行。
至于說對于事務的支持，mysql和pgsql都沒有問題。
重慶分公司
重慶分公司
