![Care and Feeding of a MySQL Database for Linux Administrators Dave Stokes MySQL Community Manager [email_address]](https://image.slidesharecdn.com/thecareandfeedingofamysqldatabase-111019225431-phpapp01/85/The-care-and-feeding-of-a-MySQL-database-1-320.jpg)
The care and feeding of a MySQL database
- 1. Care and Feeding of a MySQL Database for Linux Administrators Dave Stokes MySQL Community Manager [email_address]
- 2. Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
- 3. Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator
- 4. Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database servers have needs different than SMTP, HTTP, or other servers
- 5. Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database servers have needs different than SMTP, HTTP, or other servers Hardware choices are critical! (do not go cheap)
- 6. Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database servers have needs different than SMTP, HTTP, or other servers Hardware choices are critical! (do not go cheap) Tuning to 80% efficiency is relatively easy
- 7. Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database servers have needs different than SMTP, HTTP, or other servers Hardware choices are critical! (do not go cheap) Tuning to 80% efficiency is relatively easy (last 20% is tricky)
- 8. Session Overview Basics of a database server
- 9. Hardware
- 12. Backups
- 13. Replication
- 14. Indexes
- 15. Tuning
- 16. Q/A
- 17. How does a Database server work Client SELECT phone FROM friends WHERE name = ‘Joe’; Server
- 18. How does a Database server work Client SELECT phone FROM friends WHERE name = ‘Joe’; Server PARSE find Joe in friends table in memory return phone
- 19. How does a Database server work Client SELECT phone FROM friends WHERE name = ‘Joe’; . . . Process phone data Server PARSE find Joe in friends table in memory return phone
- 20. How does a Database server work Client SELECT phone FROM friends WHERE name = ‘Joe’; . . . Process phone data Server PARSE find Joe in friends table in memory return phone What was that about memory???
- 21. Rule #1 Databases love data in memory
- 22. Rule #1 Databases love data in memory Corollary #1 – getting data in/out of memory will cause you nightmares!
- 23. What if it is not in memory? MySQL Please give me the data from the city table OS
- 24. What if it is not in memory? MySQL Please give me the data from the city table OS Get inode
- 25. What if it is not in memory? MySQL Please give me the data from the city table OS Get inode Ask disk for data
- 26. What if it is not in memory? MySQL Please give me the data from the city table OS Get inode Ask disk for data Get data into buffer
- 27. What if it is not in memory? MySQL Please give me the data from the city table Load data into memory OS Get inode Ask disk for data Get data into buffer Hand buffer off
- 28. What if it is not in memory? MySQL Please give me the data from the city table Load data into memory OS Get inode Ask disk for data Get data into buffer Hand buffer off Much longer than just reading from memory
- 29. Rule #2 Databases have to do unpredictable queries, random I/O, and sequential scans so slow I/O kills performance
- 30. Buffers What happens when you read a file into memory DISK Disk Controller Page Cache User Buffer
- 31. Buffers Memory Lookup – 100 nanoseconds, 12GB/sec DISK Disk Controller Page Cache User Buffer
- 32. Buffers Memory Lookup – 100 nanoseconds, 12GB/sec DISK seek – 10 milliseconds, 760MB/sec DISK Disk Controller Page Cache User Buffer
- 33. Disk Reads A disk read is 100,000 slower than reading memory For comparison 100,000 minutes is about 69.5 days
- 34. 100,000 feet is about 19 miles
- 35. 100,000 kilometers is 15.7 times around Earth's equator
- 36. Cache Write back and write through caches Writethrough on disk Writethrough on controller Disk Controller DISK
- 37. Cache Recommended setup Writethrough on disk Writeback on controller Disk Controller DISK
- 38. SSD Use standard RAID controller SSD as writeback cache
- 39. Battery backed
- 41. Very fast seek time
- 42. Density
- 43. Hardware recommendations Memory – lots of it, ecc
- 44. Hardware recommendations Memory – lots of it, ecc
- 45. DISKs – more spindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3
- 46. Hardware recommendations Memory – lots of it, ecc
- 47. DISKs – more spindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3
- 48. Write-through caches with battery backup units for disks must be monitored, and have life span much longer than planned outages
- 49. Hardware recommendations Memory – lots of it, ecc
- 50. DISKs – more spindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3
- 51. Write-through caches with battery backup units for disks must be monitored, and have life span much longer than planned outages
- 52. CPUs, Core less important (spend money on Memory and IO)
- 53. Quick Security Warning! MySQL login security is primitive. Database mysql has users table
- 54. 'jsmith'@'co.com' or 'fred'@'10.10.%' Matches host , then user , then password fields Be explicit Proxy and Pluggable logins on the way MySQL privilege security GRANT functions or access
- 55. Can get Byzantine quickly
- 56. Use a GUI
- 57. When root is the root of your root problem OR stingy is your best friend Linux server has root Highly privileged
- 58. Dangerous MySQL daemon has root Highly privileged
- 59. Dangerous
- 60. Understand MySQL priv system and be stingy
- 61. Proxy and plug-in adapters soon
- 62. Really limit access, not just play at it Linux root is not the same as MySQL root but both can be dangerous to you!!!
- 63. Installation Use pre built MySQL packages
- 64. Installation Use prebuilt MySQL packages
- 65. Don’t double up with other services
- 66. Installation Use prebuilt MySQL packages
- 67. Don’t double up with other services
- 68. Supplied configuration files are OLD !
- 69. Installation Use prebuilt MySQL packages
- 70. Don’t double up with other services
- 71. Supplied configuration files are OLD !
- 72. Move logs to different disk than data
- 73. Installation Use prebuilt packages
- 74. Don’t double up with other services
- 75. Supplied configuration files are OLD !
- 76. Move logs to different disk than data
- 77. Spread data over different drives
- 78. Installation Use prebuilt packages
- 79. Don’t double up with other services
- 80. Supplied configuration files are OLD !
- 81. Move logs to different disk than data
- 82. Spread data over different drives
- 83. Backups are necessary – and practice recovery!
- 84. Monitoring Operations Slow query log -- not all long running queries are bad
- 85. Monitoring Operations Slow query log -- not all long running queries are bad
- 86. Log queries not using indexes
- 87. Monitoring Operations Slow query log -- not all long running queries are bad
- 88. Log queries not using indexes
- 89. Use monitoring software – MEM, Innotop, Cacti, Munin, Nagios, etc – and pay attention to it
- 90. Monitor!!!
- 91. Monitoring Operations Slow query log -- not all long running queries are bad
- 92. Log queries not using indexes
- 93. Use monitoring software – MEM, Innotop, Cacti, Munin, Nagios, etc – and pay attention to it
- 94. More in tuning ….
- 95. Backups Backups are usually some sort of disk snap shot or serializing data to a file
- 96. Backups Backups are usually some sort of disk snap shot or serializing data to a file The more the better but you need to know steps to recover dropped table, lost databases, or mangled data
- 97. Backups Backups are usually some sort of disk snap shot or serializing data to a file The more the better but you need to know steps to recover dropped table, lost databases, or mangled data. Use data replication to a slave and then backup slave
- 98. Backups Backups are usually some sort of disk snap shot or serializing data to a file The more the better but you need to know steps to recover dropped table, lost databases, or mangled data. Use data replication to a slave and then backup slave Be paranoid!!!!!
- 99. Replication Replication for MySQL is the binary log for the master being copied to a slave. The slave then updates its copy of the data
- 100. Replication Replication for MySQL is the binary log for the master being copied to a slave. The slave then updates its copy of the data Two types: Asynchronous – server does not check changes sent to slave before proceeding
- 101. Replication Replication for MySQL is the binary log for the master being copied to a slave. The slave then updates its copy of the data Two types: Asynchronous – server does not check changes sent to slave before proceeding
- 102. Semi Synchronous – server checks that slave received changes before proceeding
- 103. Replication -- threads Currently single threaded – 5.6 will fix that
- 104. Replication -- network Network latency will affect MySQL replication. So plan network topology to minimize bandwidth competition with other systems/services.
- 105. Replication -- network Network latency will affect MySQL replication. So plan network topology to minimize bandwidth competition with other systems/services. Slaves do not need to be as fast as the master but try to keep things reasonably close
- 106. Replication -- network Network latency will affect MySQL replication. So plan network topology to minimize bandwidth competition with other systems/services. Slaves do not need to be as fast as the master but try to keep things reasonably close Do not have to replicate all tables/databases to all slaves. Cut down on traffic by replicating what is needed!
- 107. Write to one master
- 108. Read from many slaves, easily add more as needed
- 109. Perfect for read/write intensive apps Application MySQL Replication Load Balancer MySQL Database Replication Enables Scalability Writes & Reads Reads Reads
- 110. Indexes are good Without Index DB needs to scan entire table or table scan With Index DB can go right to record
- 111. Indexes, the bad Overhead -- space, speed, maintenance
- 112. Indexes, the bad Overhead -- space, speed, maintenance
- 113. Not a panacea – does not cure all problems
- 114. Indexes, the bad Overhead -- space, speed, maintenance
- 115. Not a panacea – does not cure all problems
- 116. Will not help if you need to perform a table scan
- 117. Indexes, the bad Overhead -- space, speed, maintenance
- 118. Not a panacea – does not cure all problems
- 119. Will not help if you need to perform a table scan
- 120. Composite indexes can be tricky – YearMonthDay usually better than DayMonthYear
- 121. Tuning to 80% Use InnoDB
- 122. Tuning to 80% Use InnoDB
- 123. Set innodb_buffer_pool_size to 70-80% of memory
- 124. Tuning to 80% Use InnoDB
- 125. Set innodb_buffer_pool_size to 70-80% of memory
- 126. Use XFS/ZFS/ext4
- 127. Tuning to 80% Use InnoDB
- 128. Set innodb_buffer_pool_size to 70-80% of memory
- 129. Use XFS/ZFS/ext4
- 130. Partition data -- divide and conquer
- 131. Tuning to 80% Use InnoDB
- 132. Set innodb_buffer_pool_size to 70-80% of memory
- 133. Use XFS/ZFS/ext4
- 134. Partition data -- divide and conquer
- 135. Architect your data
- 136. Tuning to 80% Use InnoDB
- 137. Set innodb_buffer_pool_size to 70-80% of memory
- 138. Use XFS/ZFS/ext4
- 139. Partition data -- divide and conquer
- 140. Architect your data
- 141. Review your SQL statements
- 142. Don't hurt yourself Some RAID controllers have a battery learning cycle when BBU goes write-back. Schedule during off-time!
- 143. Minimize time for most frequent queries
- 144. Keep on top of upgrades
- 145. - 5.5 20% faster than 5.1
- 146. Tuning Past 80% Will depend on your data
- 147. Tuning Past 80% Will depend on your data
- 148. Lots of Tuning Help Available
- 149. Tuning Past 80% Will depend on your data
- 150. Lots of Tuning Help Available High Performance MySQL – Schwartz et al
- 151. MySQL Administrator's Bible – Cabral
- 152. Tuning Past 80% Will depend on your data
- 153. Lots of Tuning Help Available High Performance MySQL – Schwartz et al
- 154. MySQL Administrator's Bible – Cabral
- 155. OurSQL podcast
- 156. Tuning Past 80% Will depend on your data
- 157. Lots of Tuning Help Available High Performance MySQL – Schwartz et al
- 158. MySQL Administrator's Bible – Cabral
- 159. OurSQL podcast
- 160. Performance forum on Forums.MySQL.Com
- 162. Tuning Past 80% Will depend on your data
- 163. Lots of Tuning Help Available High Performance MySQL – Schwartz et al
- 164. MySQL Administrator's Bible – Cabral
- 165. OurSQL podcast
- 166. Performance forum on Forums.MySQL.Org
- 167. Planet.MySQL.com & MySQL.com Skilled DBA
- 168. Tuning Past 80% Will depend on your data
- 169. Lots of Tuning Help Available High Performance MySQL – Schwartz et al
- 170. MySQL Administrator's Bible – Cabral
- 171. OurSQL podcast
- 172. Performance forum on Forums.MySQL.Org
- 173. Planet.MySQL.COM & MySQL.Com Skilled DBA Defined as obsessive professional looking to save nanoseconds off queries, possess current backups, helps developers rewrite queries, plans for future, and watches buffer hits rates compulsively.
- 174. Big hint Seek to optimize the system as a whole. Often the database is blamed for systemic slowness when other components are at fault.
- 175. General Last hints SQL Fetch needed data only, no SELECT *
- 176. Use EXPLAIN
- 177. Think in data sets, not nested loops
- 178. Set benchmark times
- 179. Use smallest data type possible
- 180. Rewrite subqueries to joins Mysqld Pay attention to new technologies, updates
- 181. Know which buffers are per-session, global
- 182. Do not ignore log files
- 183. Q&A [email_address] - http://NorthTexasMySQL.org
Editor's Notes
- #2: Thanks for coming Intro What is new in MySQL 5.5
- #4: A single 40 minute session can not turn you into a good DBA than the same time to turn a novice into a good system admin. We have been promoting MySQL on generic hardware – but sometimes you need better performance and that may require specialized hardware.
- #5: Most Linux based services are CPU bound – not database servers
- #6: Databases are the heart of the LAMP stack. Poor hardware choice is like an unhealthy heart.
- #7: This session will cover much of what you need to know for a solid foundation to make your MySQL database per optimally but …
- #8: That last 20% is where a good DBA comes in to play Indy Car example
- #10: Gross over simplification! Client wants phone number for Joe from database
- #11: Database server parses query, finds record in memory, returns phone number
- #12: Client program proceeds with phone number
- #13: This is an optimal situation.
- #14: Rule 1
- #15: The database needs to get data not in memory off storage Also updates need to get written to disk Disk is MUCH slower than memory
- #16: Another vast over simplification
- #17: OS has to pry open file
- #18: Then pull out data
- #19: Load data into memory
- #20: Hand data back to database
- #21: Much longer
- #22: I/O subsystem is critical to performance. Spend money here instead of latest speedy processor.
- #31: Minimize contention
- #32: KNOW your BBU system – does it occasionally going into self test mode and could that self test mode happen at the wrong time?
- #33: Spend money on memory and disks over latest CPU
- #36: MySQL supports .DEB, RPM, Windows, tar balls, and source code. Pre-built uses better compilers and libraries than you probably have access to.
- #37: Do not run other services (HTTP, LDAP, memcached, etc) on same box if you need performance.
- #38: Large system 2-4 GB ram
- #39: Do not let logs fill disks..
- #40: Move to another spindle to avoid contention
- #42: Queries over 1 second, configurable, go into slow query log. But you may need full table scans or complex queries from time to time.
- #43: May be a quick gain (more later)
- #44: You need a way to check on how well your database is running, or not. Granularity depends on application.
- #46: More later
- #47: Two choices -- mysqldump, MySqL Enterprise backup, LVM snapshots or some variant of these
- #48: Need to determine before hand what you can lose, what you can not lose, service levels, and develop strategy.
- #50: Look for single points of failure Watch out for organization flaws – one person knows backup system or one person can call for support
- #52: Been around for a while
- #53: Recent development
- #59: Without index, entire table must be read With index, can go directly to record usually via a B Tree
- #61: Do not index everything!
- #62: 200 MPH Ferrari in rush hour traffic Data warehousing usually done without indexes
- #63: Leave composite indexes for DBAs – but know about them and ask
- #66: Ext-2 and ext-3 lock a per-inode mutex for the duration of a write. This means that ext-2 and ext-3 do not allow concurrent writes to a file and that can prevent you from getting the write throughput you expect when you stripe a file over several disks with RAID. XFS does not do this which is one of the reasons many people prefer XFS for InnoDB. I don't know whether ext-4 does this. Depending on what caches are enabled in your storage, this can have reduce disk write throughput. Even when you have a battery backed write cache, unless the batteries can be hot-swapped, it is likely that at some point in time your server will run in production with the RAID write cache disabled.
- #67: Divide the data in logical small chunks, chunks. I.E. Account receivables by month instead of year so that smaller segment can be processed
- #68: To easy to add tables here, de-normalize there, quick fix there, and soon the data is an unusable mess. Plan what your data looks like and make smart choices as needs grow.
- #69: A bad SQL statement can ruin all the work you have done. Use EXPLAIN to check for the efficiency of statements. Seek to minimize that data needed, no ‘SELECT *’.