Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
MySQL - The Old Way
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Gea-Suan Lin
July 29, 2012
Technology
490
4
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
MySQL - The Old Way
Gea-Suan Lin
July 29, 2012
More Decks by Gea-Suan Lin
See All by Gea-Suan Lin
High Availability Vault Service on AWS Environment
gslin
0
7.3k
用 AWS CodeDeploy 解決程式佈署
gslin
0
450
MySQL to NoSQL & Search Engine
gslin
0
2.2k
用 Vagrant 與 Docker 拯救世界
gslin
1
310
Startup IT infrastructure: Developing and Working with AWS
gslin
8
3.8k
Talk about Percona XtraDB Cluster
gslin
0
210
API Design Optimized for Mobile Platform
gslin
9
8.8k
Use Facebook::Graph to write desktop application
gslin
2
520
COSCUP 2012 - MySQL System Stability
gslin
17
12k
Other Decks in Technology
See All in Technology
AIエージェントの知識表現と推論に なぜグラフが使われるのか - 記号的AIの復権とニューラルAIとの統合
yohei1126
1
200
セキュリティ研修【MIXI 26新卒技術研修】
mixi_engineers
PRO
31
25k
AIツールを導入しても生産性はあがらない? カオナビが直面した 3つの壁と乗り越え方。/ Overcoming 3 Barriers to AI-Driven Productivity at kaonavi
kaonavi
0
460
大 AI 時代におけるC# の事情 ~ぶっちゃけトークを交えながら~
nenonaninu
1
540
カメラ×AIで挑む「ホワイト物流」― 車両管理、自動化の壁と突破口【SORACOM Discovery 2026】
soracom
PRO
0
180
文字起こし基盤の信頼性
abnoumaru
0
150
どこまでAIに任せるか 〜確率論と決定論の境界決定〜
shukob
0
560
論語・武士道・産業革命から見る かわるもの、かわらないもの
ichimichi
8
1.6k
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
53k
人手不足への挑戦:車両保全を支えるIoTとクラウド内製化の道【SORACOM Discovery 2026】
soracom
PRO
0
160
AIがAPIを書く時代に、私たちは何を設計すべきか
nagix
0
160
WEBフロントエンド研修【MIXI 26新卒技術研修】
mixi_engineers
PRO
1
730
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
174
15k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
350
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
640
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
360
GraphQLとの向き合い方2022年版
quramy
50
15k
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
360
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
1
380
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.7k
Skip the Path - Find Your Career Trail
mkilby
1
170
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.4k
Transcript
MySQL - The Old Way Gea-Suan Lin
Old != Bad
In this case, Old implies Reliable
Reliable
We are familiar with these issues,
We can workaround these issues
So...
First Solution
Built-in Replication
http://dev.mysql.com/ doc/refman/5.5/en/ replication.html
The Good Part
Simple
Dead Simple Setup
Dead Simple Concept
Master logs changes
Slave applies changes
The Bad Part
Async
Means...
Replication Lag
When you write data to master,
It’s possible unable to read from slave
Workaround
Always use master if you write data
The Worst Part
Application cannot write after master crash
This derives...
Second Solution
Master-Master
Two MySQL servers
Set each other as master server
The Good Part
Both MySQL servers can be written
The Bad Part
Data inconsistent
MySQL Server A TRUNCATE TABLE t; INSERT t SET i=1;
MySQL Server B TRUNCATE TABLE t; INSERT t SET i=2;
MySQL Server A TRUNCATE TABLE t; INSERT t SET i=1;
TRUNCATE TABLE t; INSERT t SET i=2; MySQL Server B TRUNCATE TABLE t; INSERT t SET i=2; TRUNCATE TABLE t; INSERT t SET i=1;
Result
MySQL Server A i=2 MySQL Server B i=1
Workaround
Write one server in normal case
Write another one when primary node fails
You can write code to handle failover
But we suggest to use Heartbeat
Heartbeat can handle this failover case
When data is inconsistent,
We can use Percona’s pt-table-sync to sync data
Third Solution
DRBD + Heartbeat
DRBD is Network-based RAID-1
Block-level mirror
Heartbeat handles High Availability
http://dev.mysql.com/ doc/refman/5.5/en/ha- drbd.html
http://dev.mysql.com/ doc/refman/5.5/en/ha- heartbeat.html
The Good Part
Data consistent
You won’t need to worry about data inconsistent issue
The Bad Part
Utilization Rate
Only one server uses to serve applications
Warm up time
When I/O rate cannot catch query rate
Conclusion
DRBD has higher down-time than other twos,
And it costs higher in server hardware
But it costs lower for SA Operations
If down-time of DRBD + Heartbeat is acceptable,
You should choose it
How much down- time ?
It depends,
Usually < 30 secs to failover
With warm up time
Possible 3~5 mins for 10GB data size ?
Thanks !