CUSTOM NON-RDS MULTI-AZMYSQL REPLICATIONCloudpack Night #65/17/2013
ABOUT ME (@IJIN)• Michael H. Oshita• Japanese American• In Japan since 2002• Software/Infra/Cloud Engineer• http://ijin.gi...
CERTIFIEDTODAY!
COMPONENTS• AWSVPC (Routing-Based HA Pattern)• MySQL Master-Slave Replication• MHA (Master HA Manager for MySQL)• no RDS!!
MHAMasterSlaveSlaveManagerManager detects failure on master
MasterMasterSlaveManagerMHASlave is promoted to master after binlogs are appliedbinlogbinlogbinlog
"Starting master failover.""* Phase 1: Configuration Check Phase..n""* Phase 2: Dead Master Shutdown Phase..n"==> Delete r...
“SHARE A PRIVATE IP ACROSS AVAILABILITY ZONES”http://d.hatena.ne.jp/c9katayama/20111225/1324837509#ヤマン ++
• Storage engines & distributions• Instance types• Fast• EfficientWHY NOT RDS?→ FLEXIBILITY!!
• Percona Server (XtraDB)• MariaDB• TokuDB• MroongaSTORAGE ENGINES &DISTRIBUTIONS
• hi1.xlarge• m3.xlarge• c1.xlarge• etc.INSTANCETYPES
• RoutingTable changes pretty quickly• Total failover in roughly <20s (RDS takes 3-6m)• Non-DNS based• Apps can be configur...
• Minimum of 2 (web+db) servers• Warm up (replication booster)• Fine tuning• Server LogsEFFECIENT
DEMO
CONSIDERATIONS• Backups → Xtrabackup, copy binlogs to s3• Point inTime Recovery → Automate with Chef• Provisioning Replica...
THANKYOU!
Upcoming SlideShare
Loading in...5
×

Custom Non-RDS Multi-AZ Mysql Replication

4,245

Published on

Lightning Talk slide for Cloudpack Night #6

Published in: Technology

Custom Non-RDS Multi-AZ Mysql Replication

  1. 1. CUSTOM NON-RDS MULTI-AZMYSQL REPLICATIONCloudpack Night #65/17/2013
  2. 2. ABOUT ME (@IJIN)• Michael H. Oshita• Japanese American• In Japan since 2002• Software/Infra/Cloud Engineer• http://ijin.github.io
  3. 3. CERTIFIEDTODAY!
  4. 4. COMPONENTS• AWSVPC (Routing-Based HA Pattern)• MySQL Master-Slave Replication• MHA (Master HA Manager for MySQL)• no RDS!!
  5. 5. MHAMasterSlaveSlaveManagerManager detects failure on master
  6. 6. MasterMasterSlaveManagerMHASlave is promoted to master after binlogs are appliedbinlogbinlogbinlog
  7. 7. "Starting master failover.""* Phase 1: Configuration Check Phase..n""* Phase 2: Dead Master Shutdown Phase..n"==> Delete routing table (master_ip_failover)"* Phase 3: Master Recovery Phase..n""* Phase 3.1: Getting Latest Slaves Phase..n""* Phase 3.2: Saving Dead Masters Binlog Phase..n""* Phase 3.3: Determining New Master Phase..n"==> Change routing table (master_ip_failover)"* Phase 4: Slaves Recovery Phase..n"MHAFAILOVER SEQUENCE
  8. 8. “SHARE A PRIVATE IP ACROSS AVAILABILITY ZONES”http://d.hatena.ne.jp/c9katayama/20111225/1324837509#ヤマン ++
  9. 9. • Storage engines & distributions• Instance types• Fast• EfficientWHY NOT RDS?→ FLEXIBILITY!!
  10. 10. • Percona Server (XtraDB)• MariaDB• TokuDB• MroongaSTORAGE ENGINES &DISTRIBUTIONS
  11. 11. • hi1.xlarge• m3.xlarge• c1.xlarge• etc.INSTANCETYPES
  12. 12. • RoutingTable changes pretty quickly• Total failover in roughly <20s (RDS takes 3-6m)• Non-DNS based• Apps can be configured with a single IP• no need to worry about internal DNS problemsFAST FAILOVER
  13. 13. • Minimum of 2 (web+db) servers• Warm up (replication booster)• Fine tuning• Server LogsEFFECIENT
  14. 14. DEMO
  15. 15. CONSIDERATIONS• Backups → Xtrabackup, copy binlogs to s3• Point inTime Recovery → Automate with Chef• Provisioning Replicas → Automate with Chef• Some learning curve• API backplane a SPoF
  16. 16. THANKYOU!
  1. ¿Le ha llamado la atención una diapositiva en particular?

    Recortar diapositivas es una manera útil de recopilar información importante para consultarla más tarde.

×