Custom Non-RDS Multi-AZ Mysql Replication
Upcoming SlideShare
Loading in...5
×
 

Custom Non-RDS Multi-AZ Mysql Replication

on

  • 3,618 views

Lightning Talk slide for Cloudpack Night #6

Lightning Talk slide for Cloudpack Night #6

Statistics

Views

Total Views
3,618
Views on SlideShare
890
Embed Views
2,728

Actions

Likes
9
Downloads
6
Comments
0

13 Embeds 2,728

http://ijin.github.io 2102
http://d.hatena.ne.jp 254
http://localhost 215
http://blog.cloudpack.jp 107
http://yoshidashingo.hatenablog.com 12
https://twitter.com 7
http://translate.googleusercontent.com 6
http://webcache.googleusercontent.com 6
http://newsblur.com 6
http://3449707904234438373_ebb5d0aa9dae40f61c46202be459da9b0f197f5a.blogspot.com 4
http://10.0.1.216 4
http://www.newsblur.com 3
https://duckduckgo.com 2
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Custom Non-RDS Multi-AZ Mysql Replication Custom Non-RDS Multi-AZ Mysql Replication Presentation Transcript

    • 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.github.io
    • 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 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
    • “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 configured with a single IP• no need to worry about internal DNS problemsFAST FAILOVER
    • • 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 Replicas → Automate with Chef• Some learning curve• API backplane a SPoF
    • THANKYOU!