Download as ODP, PPTX
![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)
![Care and Feeding of a MySQL Database for Linux Administrators Dave Stokes MySQL Community Manager [email_address]](https://image.slidesharecdn.com/thecareandfeedingofamysqldatabase-111019225431-phpapp01/75/The-care-and-feeding-of-a-MySQL-database-1-2048.jpg)
More Related Content
Similar to The care and feeding of a MySQL database
The care and feeding of a MySQL database
- 1. Care and Feedingof a MySQL Database for Linux Administrators Dave Stokes MySQL Community Manager [email_address]
- 2. Safe Harbor StatementThe 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 Thisis a general introduction to running a MySQL database server(s) for Linux Administrator
- 4. Simple Introduction Thisis 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 Thisis 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 Thisis 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 Thisis 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 Basicsof a database server
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17. How does aDatabase server work Client SELECT phone FROM friends WHERE name = ‘Joe’; Server
- 18. How does aDatabase server work Client SELECT phone FROM friends WHERE name = ‘Joe’; Server PARSE find Joe in friends table in memory return phone
- 19. How does aDatabase 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 aDatabase 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 Databaseslove data in memory
- 22. Rule #1 Databaseslove data in memory Corollary #1 – getting data in/out of memory will cause you nightmares!
- 23. What if itis not in memory? MySQL Please give me the data from the city table OS
- 24. What if itis not in memory? MySQL Please give me the data from the city table OS Get inode
- 25. What if itis not in memory? MySQL Please give me the data from the city table OS Get inode Ask disk for data
- 26. What if itis 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 itis 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 itis 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 Databaseshave to do unpredictable queries, random I/O, and sequential scans so slow I/O kills performance
- 30. Buffers What happenswhen 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 Adisk read is 100,000 slower than reading memory For comparison 100,000 minutes is about 69.5 days
- 34. 100,000 feet isabout 19 miles
- 35. 100,000 kilometers is15.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 setupWritethrough on disk Writeback on controller Disk Controller DISK
- 38. SSD Use standardRAID controller SSD as writeback cache
- 39.
- 40.
- 41. Very fast seektime
- 42.
- 43. Hardware recommendations Memory– lots of it, ecc
- 44. Hardware recommendations Memory– lots of it, ecc
- 45. DISKs – morespindles, 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 – morespindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3
- 48. Write-through caches withbattery 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 – morespindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3
- 51. Write-through caches withbattery backup units for disks must be monitored, and have life span much longer than planned outages
- 52. CPUs, Core lessimportant (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 Byzantinequickly
- 56.
- 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 daemonhas root Highly privileged
- 59.
- 60. Understand MySQL privsystem and be stingy
- 61. Proxy and plug-inadapters 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 prebuilt MySQL packages
- 64. Installation Use prebuiltMySQL packages
- 65. Don’t double upwith other services
- 66. Installation Use prebuiltMySQL packages
- 67. Don’t double upwith other services
- 68. Supplied configuration filesare OLD !
- 69. Installation Use prebuiltMySQL packages
- 70. Don’t double upwith other services
- 71. Supplied configuration filesare OLD !
- 72. Move logs todifferent disk than data
- 73. Installation Use prebuiltpackages
- 74. Don’t double upwith other services
- 75. Supplied configuration filesare OLD !
- 76. Move logs todifferent disk than data
- 77. Spread data overdifferent drives
- 78. Installation Use prebuiltpackages
- 79. Don’t double upwith other services
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 *’.