Amazon和Mysql之間的那點事兒

摘要

本文主要介紹了亞馬遜RDS的使用過程當中發現的問題以及基於亞馬遜EC2實例本身搭建Mysql服務器的一些經驗。

初始

公司項目初始，就使用了亞馬遜的各項雲服務，亞馬遜的各項服務真的很是棒，大大簡化了公司產品的擴容和運維工做。

以前公司使用亞馬遜的EC2實例，一切都很是好。隨着業務的擴展，客戶須要mysql關係型數據庫，爲了使用方便，咱們選了亞馬遜提供的RDS服務，這玩意兒就是那麼簡單，選個mysql版本，直接就部署好了，什麼my.cnf 文件，那是啥？我不關心啊。

開始運行的挺好，各類方便，還能動態製做一個主機的鏡像實例，真是簡單又省心。

隨着用戶量的增長，高可用和負載均衡提上了日程。

高可用？很簡單啊，亞馬遜的RDS高可用跟用戶不要緊，他本身內部都冗餘好了，亞馬遜系統本身準備的slave會頂上去的；負載均衡，嗯，這有點麻煩，我找找資料。

深刻

亞馬遜提供了一個通用的ELB模塊，來動態分配訪問落到哪臺RDS上，但兩臺RDS的數據一致性怎麼解決呢？

mysql社區版本並不提供集羣服務，也就是說實際上在不少mysql系統中，並無官方的負載均衡的解決方案，這就意味着，若是要從系統層面解決，必須使用第三方工具，或者經過用戶的應用代碼來完成。如今RDS就是提供一個數據庫連接，全部系統工具都不能用。

第三方系統工具用不了，那麼讓用戶改代碼？這豈不是和咱們的目標衝突了？咱們的目標就是讓用戶可以零修改就能使用咱們服務。

因而，咱們分析了RDS的情況。

優勢：

1. 簡單易用

2. 自動高可用

3. 按期有snapshot

缺點：

1. 缺少系統級的數據庫管理界面

2. 沒有root權限

3. …(不說了)

缺點的第一和第二兩點，足以讓咱們放棄RDS的應用了。

這難道就是一言不合就開撕？呵呵，並非，若是亞馬遜的RDS能交出root權限，能解決數據同步，讀寫分離，負載均衡，動態遷移… 。嗯，咱們還會是好朋友的 ☺。

棄坑挖新坑

好了言歸正傳，咱們轉手搞了3臺EC2實例，搭了三個mysql，一主兩叢，結構是1常主，一備主，一永從。

這很好理解了，2臺作主的，性能比較好，一臺永從的，只作數據備份用，按照必定的時間間隔備份數據到S3服務器上。

這裏要介紹一個熟悉mysql都會知道的專門搞mysql，擴展mysql的大牛公司：PERCONA。寫下這個幾個字母的時候，俺的心情是激動的，因此都是大寫的。

你們都知道mysql的存儲引擎如今主流的有兩種MyISAM和INNODB，其中的差異咱們不說，只說數據備份，MyISAM的備份很簡單，拷貝複製; INNODB的備份就扯了，用mysqldump 命令對數據庫進行蹂躪。有時還會偶爾疏忽，漏了個參數，咋辦？vi打開sql文件改幾十，幾百個地方？仍是再來重複蹂躪一下，再dump一遍？Oh my god，太痛苦了，想一想就是一場噩夢。

一方有難八方支援之一

Percona華麗麗的給出了一份在線熱備的工具XtraBackup。這真是mysql admin的居家旅行，XXXX的利器啊，老鳥能夠不用在乎，小鳥同窗們，大家可要好好的掌握這一大殺器啊！

XtraBackup在運行期間，不鎖庫，不鎖庫，不鎖庫。重要的事情說三遍，光這個優點就能夠棄用mysqldump了。

還有什麼增量備份，差別備份，單庫備份恢復等等，猶如瑞士軍刀，總有一件適合你。

下面給三條命令：

1. 備份(備份的時候不須要停服務，若是是主庫，用戶是無感的)

innobackupex --defaults-file=/etc/my.cnf  --user='root' --password='xxxxx' /opt/data/abcd --no-timestamp

注：/opt/data/abcd 是指定數據庫備份輸出的目錄， --no-timestamp讓工具不要主動生成時間戳目錄

1. 恢復

innobackupex --user=root --default-file=/etc/my.cnf --apply-log  /opt/data/abcd
innobackupex --user=root --default-file=/etc/my.cnf --copy-back  /opt/data/abcd

注1:以上是兩條命令

注2:恢復以前，須要停mysql服務，刪除mysql的data目錄下的全部數據，恢復完以後，須要執行命令chown –R 命令把mysql data目錄改成mysql:mysql ，以後啓動mysql 服務。

Xtrabackup輸出的數據目錄會有一個文件，裏面記錄了bin-log文件的序號和position位置，也就是說，咱們在執行Xtrabackup命令進行備份的時候，此時輸出的數據，是和此文件序號中的position位置的log記錄相匹配的。（若是你搭建過主從，就會明白，不然就會認爲我在胡言亂語。）

想要深刻了解Xtrabackup是怎麼幹的，能夠去看下[Mysql技術內幕－InnoDB存儲引擎]。

有了這個工具，搭建主從不要太方便。

先找臺作主服務的EC2，搭個mysql。

裝下google的半同步插件（寫到這裏，不由想到，RDS不知道是用的是啥，難道是異步同步）

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

把REPLICATION SLAVE和REPLICATION CLIENT都搞上，而後就能用Xtrabackup來一式兩份了。

GRANT REPLICATION SLAVE ON *.* to 'xxx'@'%' identified by 'xxx';
GRANT REPLICATION CLIENT ON *.* to 'xxx'@'%' identified by 'xxx';

把Xtrabackup輸出的目錄打個包，scp到兩臺從機上，恢復並啓動mysql服務以後，執行命令:

CHANGE MASTER TO MASTER_HOST='xxx',master_port=3306,master_user='xxx',master_password='xxx',master_log_file='xxx',master_log_pos=xxx;

命令中的xxx各不相同哦，各位謹慎。

master_log_file='xxx',master_log_pos=xxx; 這兩個數據能夠從xtrabackup_binlog_pos_innodb 文件中獲取。

而後在mysql命令行下 show slave statusG; 看下主從複製的狀況，就萬事OK了！

一方有難八方支援之二

既然搭建了主從，那麼MHA也是必須的。

MHA項目地址 https://code.google.com/p/mys...

雖然這個項目許久沒有更新，不過歷史證實仍是蠻可靠的。

我曾經作過一個無負載測試，搞了1600屢次，每次都在10-15秒以內順利切換完成。若是你的服務器能中止mysql服務1600屢次，那我還能說什麼呢？

MHA通常配合Keepalived 給App提供一個惟一可用的mysql連接ip，一旦MHA腳本檢測到mysql 服務中斷，能夠本身寫腳本，中斷目標服務器的keepalived服務，這樣VIP就漂移到新的服務器上，繼續提供服務了。

可是咱們架設在亞馬遜EC2實例上的mysql服務器爲了安全起見都是跨網段的，Keepalived不支持，實現不了啊。還好天無絕人之路，EC2實例提供了輔助私有ip的功能，用AWS命令爲主服務器添加一個輔助私有IP，而且把原來的輔助私有IP回收掉，不就能夠了嗎？

想到就幹。

回收：

aws ec2 unassign-private-ip-addresses --network-interface-id xxx --private-ip-addresses $VIP

添加：

aws ec2  assign-private-ip-addresses --network-interface-id xxx --private-ip-addresses $VIP --allow-reassignment

以後咱們看下MHA提供的代碼：
打開文件master_ip_failover 這是用perl寫的(寫到這裏，又不由自主的想到了，誰說perl不行了，系統管理到處是perl啊！)：

GetOptions(
 'command=s'              => \$command,
 'orig_master_host=s'     => \$orig_master_host,
 'orig_master_ip=s'       => \$orig_master_ip,
 'orig_master_port=i'     => \$orig_master_port,
 'orig_master_user=s'     => \$orig_master_user,
 'orig_master_password=s' => \$orig_master_password,
 'new_master_host=s'      => \$new_master_host,
 'new_master_ip=s'        => \$new_master_ip,
 'new_master_port=i'      => \$new_master_port,
 'new_master_user=s'      => \$new_master_user,
 'new_master_password=s'  => \$new_master_password,
);

這串代碼蠻關鍵，是上游代碼調用該腳本時傳進來的參數，這些參數也蠻好理解，望文生意的。經過這些拿到的ip，賬號，就能上服務器去折騰一下，從新分配IP到備主上，這樣就能很方便的完成常主->備主的切換了。

再看下MHA的配置腳本：

[server default]
user=xxx
password=xxx
repl_user=xxx
ssh_user=xxx
master_binlog_dir=/opt/mysql
remote_workdir=/var/log/masterha
secondary_check_script= masterha_secondary_check -s x.x.x.x -s x.x.x.x -s x.x.x.x
ping_interval=3
master_ip_failover_script=/mha4mysql/script/master_ip_failover_app1
report_script= /mha4mysql/script/send_report

[server1]
candidate_master=1
hostname=x.x.x.x

[server2]
candidate_master=1
hostname=x.x.x.x

[server3]
no_master=1
hostname=x.x.x.x

須要解釋下的包括：

secondary_check_script= masterha_secondary_check -s x.x.x.x -s x.x.x.x -s x.x.x.x

mha檢查機制，內置的，咱不用管，只要接着填寫-s 後面的ip就行了，有幾個就填幾個。

ping_interval=3

俗語說叫採樣間隔，放這兒就叫探測間隔吧。

master_ip_failover_script=/mha4mysql/script/master_ip_failover_app1

failover時執行的腳本，作一些IP回收，分配啥的，主從強制數據同步，以及最新數據源挑選等在主服務器拒絕服務以後，MHA內置腳本幫咱們都搞定了，咱們也不要care了。（咱們這裏不用選，就一個 ☺）

report_script= /mha4mysql/script/send_report

這個也挺關鍵，failover以後發送郵件通知，要不數據庫少了一個服務，你還不知道，那不是扯淡麼。

後臺Daemon運行：

nohup masterha_manager --conf=/etc/app1.cnf < /dev/null >> /var/log/masterha/app1.log 2>&1 &

好了，一套可靠的mysql服務就搭好了。

那麼各位要說了，MHA搞定了，那負載均衡呢？

呃～ 各位等我喝口水，且聽下回分解吧，哈哈！

---

做者信息
原文做者來自 MaxLeap 團隊_Service&Infra 成員：Kevin， 喜歡開發一些小腳原本協助流程建設。
力譜宿雲 LeapCloud首發：https://blog.maxleap.cn/archi...

相關閱讀
快速部署Test-Driven Development/Debug環境

歡迎你們來請關注咱們的微信公衆號：MaxLeap_yidongyanfa