![[object Object],[object Object]](https://image.slidesharecdn.com/thecareandfeedingofamysqldatabase-111019225431-phpapp01/85/The-care-and-feeding-of-a-MySQL-database-1-320.jpg)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à The care and feeding of a MySQL database
Similaire à The care and feeding of a MySQL database (20)
Plus de Dave Stokes
Plus de Dave Stokes (20)
Dernier
Dernier (20)
The care and feeding of a MySQL database
- 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)
- 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???
- 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
- 34. 100,000 feet is about 19 miles
- 35. 100,000 kilometers is 15.7 times around Earth's equator
- 39. Battery backed
- 41. Very fast seek time
- 42. Density
- 45. DISKs – more spindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3
- 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
- 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)
- 55. Can get Byzantine quickly
- 56. Use a GUI
- 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!!!
- 65. Don’t double up with other services
- 67. Don’t double up with other services
- 68. Supplied configuration files are OLD !
- 70. Don’t double up with other services
- 71. Supplied configuration files are OLD !
- 72. Move logs to different disk than data
- 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
- 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!
- 86. Log queries not using indexes
- 88. Log queries not using indexes
- 89. Use monitoring software – MEM, Innotop, Cacti, Munin, Nagios, etc – and pay attention to it
- 90. Monitor!!!
- 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
- 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!
- 108. Read from many slaves, easily add more as needed
- 110. Indexes are good Without Index DB needs to scan entire table or table scan With Index DB can go right to record
- 113. Not a panacea – does not cure all problems
- 115. Not a panacea – does not cure all problems
- 116. Will not help if you need to perform a table scan
- 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
- 123. Set innodb_buffer_pool_size to 70-80% of memory
- 125. Set innodb_buffer_pool_size to 70-80% of memory
- 126. Use XFS/ZFS/ext4
- 128. Set innodb_buffer_pool_size to 70-80% of memory
- 129. Use XFS/ZFS/ext4
- 130. Partition data -- divide and conquer
- 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
- 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
- 143. Minimize time for most frequent queries
- 144. Keep on top of upgrades
- 145. - 5.5 20% faster than 5.1
- 148. Lots of Tuning Help Available
- 151. MySQL Administrator's Bible – Cabral
- 154. MySQL Administrator's Bible – Cabral
- 155. OurSQL podcast
- 158. MySQL Administrator's Bible – Cabral
- 159. OurSQL podcast
- 160. Performance forum on Forums.MySQL.Com
- 164. MySQL Administrator's Bible – Cabral
- 165. OurSQL podcast
- 166. Performance forum on Forums.MySQL.Org
- 170. MySQL Administrator's Bible – Cabral
- 171. OurSQL podcast
- 172. Performance forum on Forums.MySQL.Org
- 176. Use EXPLAIN
- 177. Think in data sets, not nested loops
- 178. Set benchmark times
- 179. Use smallest data type possible
- 181. Know which buffers are per-session, global
- 182. Do not ignore log files
- 183. Q&A [email_address] - http://NorthTexasMySQL.org
Notes de l'éditeur
- Thanks for coming Intro What is new in MySQL 5.5
- 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.
- Most Linux based services are CPU bound – not database servers
- Databases are the heart of the LAMP stack. Poor hardware choice is like an unhealthy heart.
- This session will cover much of what you need to know for a solid foundation to make your MySQL database per optimally but …
- That last 20% is where a good DBA comes in to play Indy Car example
- Gross over simplification! Client wants phone number for Joe from database
- Database server parses query, finds record in memory, returns phone number
- Client program proceeds with phone number
- This is an optimal situation.
- Rule 1
- 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
- Another vast over simplification
- OS has to pry open file
- Then pull out data
- Load data into memory
- Hand data back to database
- Much longer
- I/O subsystem is critical to performance. Spend money here instead of latest speedy processor.
- Minimize contention
- KNOW your BBU system – does it occasionally going into self test mode and could that self test mode happen at the wrong time?
- Spend money on memory and disks over latest CPU
- MySQL supports .DEB, RPM, Windows, tar balls, and source code. Pre-built uses better compilers and libraries than you probably have access to.
- Do not run other services (HTTP, LDAP, memcached, etc) on same box if you need performance.
- Large system 2-4 GB ram
- Do not let logs fill disks..
- Move to another spindle to avoid contention
- Queries over 1 second, configurable, go into slow query log. But you may need full table scans or complex queries from time to time.
- May be a quick gain (more later)
- You need a way to check on how well your database is running, or not. Granularity depends on application.
- More later
- Two choices -- mysqldump, MySqL Enterprise backup, LVM snapshots or some variant of these
- Need to determine before hand what you can lose, what you can not lose, service levels, and develop strategy.
- Look for single points of failure Watch out for organization flaws – one person knows backup system or one person can call for support
- Been around for a while
- Recent development
- Without index, entire table must be read With index, can go directly to record usually via a B Tree
- Do not index everything!
- 200 MPH Ferrari in rush hour traffic Data warehousing usually done without indexes
- Leave composite indexes for DBAs – but know about them and ask
- 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.
- Divide the data in logical small chunks, chunks. I.E. Account receivables by month instead of year so that smaller segment can be processed
- 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.
- 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 *’.