mysql 5.7 - the first few months
Post on 22-Jan-2018
601 Views
Preview:
TRANSCRIPT
MySQL 5.7 GA
- the first few months -
Simon J Mudd <simon.mudd@booking.com>
Senior Database Administrator
10 Feb 2016
MMUG15 – Madrid MySQL Users Group
Who am I?
● Simon Mudd
● Senior Database Administrator at booking.com
● Working there since 2007
● We manage a large MySQL environment
What we will cover
● What is MySQL 5.7
● Why upgrade?
● How to upgrade?
● Our experience with 5.7 GA in production
What is MySQL 5.7?
● Latest MySQL version
● 5.7.9 released 2015-10-21
● 5.7.11 released 2016-02-05
● Previous MySQL 5.6
● 5.6.10 released 2013-02-05
● 5.6.29 released 2016-02-05
4
What version do you use?
?
5
What we look for when upgrading
Basically motivation for upgrades:
●Longer uptime and more dynamic configuration● avoid mysqld restarts
●Better performance related to● Replication
● Concurrency
● Better stability under load
● Seamless upgrade path from existing 5.6 setup to using 5.7
● More features and flexible configuration
● Incorporation of features requested while using 5.6
● Better visibility of what MySQL is doing and where it is busy
What does MySQL 5.7 provides?
● Specific Features of Interest:
● Parallel Replication
● GTID migration possible on live system and no binlogs needed on slaves
● Dynamic InnoDB buffer pool size reconfiguration
● Dynamic replication configuration (filters etc)
● Improved cache preloading on startup (configurable percentage to load)
● InnoDB Fill-size – should be good for statistics tables which are write-once
● Loss-less semi-sync
● Plus others mentioned previously
Why test MySQL 5.7 DMRs
Testing of DMR releases has allowed us to:
●Preview potential new features and give feedback
●Check performance meets expectations
●Catch unexpected behaviour early
Resources required to do this are not significant
MySQL 5.7 Timeline
● 2013-04-23 – MySQL 5.7.1 m11 release
● 2015-10-21 – MySQL 5.7.9 GA release
● 2015-10 Oracle Open World
● 2015-12-07 – MySQL 5.7.10
● 2016-02-05 – MySQL 5.7.11
Upgrading to 5.7
Master5.6
5.6 Slave1
5.6 Slave2
SlaveN
…
Upgrading to 5.7
Master5.6
Slave5.7
Slave5.7
SlaveN
…
Upgrading to 5.7
Master5.6
Slave 1MySQL 5.7
Slave 2MySQL 5.7
Slave 3MySQL 5.7
Slave NMySQL 5.7
IntermediateMaster
MySQL 5.7
1. Move slaves under 5.7 intermediate master
2. Move application writes to 5.7 master
Moving MySQL 5.7 into production
The setup of a new environment is simpler
• the new defaults require less cleanup
Configuration changes in /etc/my.cnf
• Few required changes
• log_syslog
• innodb_buffer_pool_dump_pct
• show_compatibility_56
• Pay attention to changes in default values between 5.6 and 5.7
• We have had to add some extra settings
Upgrading to 5.7 vs previous upgrades
• Slight changes in procedures but generally they are simpler
• Just run mysql_upgrade, no need for --skip-grant-tables
MySQL 5.7 GA Observations
● ~250 MySQL servers run 5.7 in production● ~25 different clusters
● No crashes seen (DMRs did crash)
● No major problems
● 3 issues seen● default_password_lifetime
● range_optimizer_max_mem_size
● GET_LOCK() change in behaviour
● Memory behaviour looks better under load
default_password_lifetime
● MySQL 5.7 accounts have password
expiry:
● <5.7.10: default: 360 days
● 5.7.11+: 0 days
● May be reverted to 360 in 5.8?
● New scripts needed to manage this!
range_optimizer_max_mem_size
● Introduced into the first GA version● Do not do that!
● behaviour different to 5.6
● If you use queries with large IN () lists this falls back to doing table scans
● Affects SELECT, but also UPDATE/DELETE!
● Has affected several clusters, but with the right config things work well
GET_LOCK() change in behaviour
● GET_LOCK() often used to ensure control of a unique resource. No
database involved.
● 5.6 allowed a single lock to be held and grabbing a new one would
release the existing one
● 5.7 allows multiple locks and they need to be freed explicitly
● Possible solutions:
● use /*!50700 */ comments and adjust the query
● Use query rewrite plugin
● Check your usage to see if you might be affected
17
Other Comments (1)
● mysql_upgrade better but inline upgrade would be nice: others are considering this
● SYS schema is good: take a look if you haven’t yet
● We still need to try JSON (but needs master + slaves to be migrated to do that)
● Multi-source replication● Good, but missing per source filters, including on
statements like GRANTs (we like to clone tables between systems)
Other Comments (2)
● Group Replication● Looks very promising, on our near radar
● Plugin mechanism: would be good to extend to other parts of MySQL
● Semi-sync: We are evaluating to avoid data loss on committed data
● Encryption: announced in 5.7.11 could be interesting for some
Conclusion
● Best MySQL yet, thanks Oracle
Questions?
top related