The document presents an overview of MySQL 5.7 based on the experiences of Simon J. Mudd, a senior database administrator at Booking.com. It highlights the benefits of upgrading to 5.7, including enhanced performance, stability, and new features like parallel replication and dynamic configuration. The author shares insights from their production use of 5.7, noting that while they have faced some challenges, there have been no major problems reported.

1. 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

2. Who am I?
● Simon Mudd
● Senior Database Administrator at booking.com
● Working there since 2007
● We manage a large MySQL environment

3. What we will cover
● What is MySQL 5.7
● Why upgrade?
● How to upgrade?
● Our experience with 5.7 GA in production

4. 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

5. What version do you use?
?
5

6. 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

7. 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

8. 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

9. 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

10. Upgrading to 5.7
Master
5.6
5.6 Slave
1
5.6 Slave
2
Slave
N
…

11. Upgrading to 5.7
Master
5.6
Slave
5.7
Slave
5.7
Slave
N
…

12. Upgrading to 5.7
Master
5.6
Slave 1
MySQL 5.7
Slave 2
MySQL 5.7
Slave 3
MySQL 5.7
Slave N
MySQL 5.7
Intermediate
Master
MySQL 5.7
1. Move slaves under
5.7 intermediate
master
2. Move application
writes to 5.7
master

13. 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

14. 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

15. 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!

16. 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

17. 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

18. 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)

19. 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

20. Conclusion
● Best MySQL yet, thanks Oracle

21. Questions?

22. Thank You
Contact:
Simon J Mudd <simon.mudd@booking.com>