Managing Databases In A DevOps Environment 2016
•
0 likes•761 views
Given at #pgdayphilly2016, this talk covers how configuration management, monitoring, and rapid deployments are impacting how we think about database management.
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to Managing Databases In A DevOps Environment 2016
Similar to Managing Databases In A DevOps Environment 2016 (20)
More from Robert Treat
More from Robert Treat (16)
Recently uploaded
Recently uploaded (20)
Managing Databases In A DevOps Environment 2016
- 1. / Robert Treat Managing Databases in a {DEVOPS} Environment
- 3. OmniTI Who Am I? “we offer a full suite of operational, database, and development services. whether you need help with an existing architecture, are looking to build out a new service, or just need a second opinion, we would love to help”
- 4. Who Am I? Highly Scaled Big Data Heavy Transactions
- 5. What Is “DevOps” ?
- 6. putting your development in my ops
- 7. putting your ops in my development
- 8. mindmeld
- 9. not a talk about devops per se
- 10. let’s focus on three things
- 12. monitoring
- 14. yes, I just offended everyone with a “kanban” t-shirt
- 15. moving on
- 17. some sysadmins get very excited about systems automation
- 19. *yawns*
- 20. many DBA’s have like ONE BOX to manage
- 22. this makes server automation seem like a hassle
- 23. now you have two problems
- 24. even with one box, there are many things to configure
- 25. database configs, cron jobs, packages, monitoring, scripts, binaries, shell config, pooler?
- 27. it’s a lot to configure
- 28. and it needs to be documented, or at least reproducible
- 29. and it would be nice to know when changes occur within your environment
- 30. these tools can help you with that
- 34. track changes
- 36. also consider
- 38. is probably more than just one database
- 39. webservers data loading script load balancer primary replay node B writes writes reads reads writes replay node A a1 a2 a3 b1 b2 b3
- 40. failover, reporting, staging, development, read replicas, and more!
- 41. and then someone sets up a new service
- 42. now you have to configure everything again on multiple machines
- 43. how long does it take you to stand up a new copy of your database?
- 44. how confident are you that everything has been configured correctly?
- 47. system stuff
- 48. disk i/o, disk space, cpu, network traffic, load
- 49. database stuff
- 52. transactions per second, connections, index scans, seq scans, table size
- 53. transactions per second, connections, index scans, seq scans, table size, cache hit ratios
- 54. don’t get hung up on details
- 55. DBA’s are sometimes finicky about data quality
- 56. it is better to have useful metrics than to have accurate metrics
- 57. metrics enable capacity planning
- 59. metrics let you know what good looks like
- 62. why did my site break?
- 63. changes
- 64. configuration parameters code pushes traffic spikes
- 65. make it easy to correlate changes
- 66. expose this to everyone!
- 67. dba’s, devs, sa’s, finance, marketing, everyone!
- 71. a bazillion deploys a day!
- 72. from idea to code in the blink of an eye
- 74. this doesn’t work well for databases
- 75. databases are fundamentally different
- 76. they have data
- 78. and hard to replace
- 79. you can always rewrite your code
- 81. you can’t get everyone to give you their data again
- 82. cf.
- 83. furthermore
- 84. code is static
- 88. data is often dynamic
- 89. control is in the hands of users
- 90. this makes database administration more difficult
- 91. we cannot eliminate change
- 92. we need to manage change
- 93. ideally, we want to enable change
- 94. back in the day
- 95. DBA’s lived in walled gardens
- 97. you send them requirements
- 99. they send you a schema
- 101. send them updated requirements
- 103. different schema
- 104. this goes back and forth
- 106. dev keeps pushing just to get it done
- 107. dba pushing to minimize change
- 108. in order to minimize risk
- 109. eventually something is agreed upon
- 110. but this takes a long time
- 111. forget you!
- 113. many shops bypass dba’s
- 114. where bypass means “don’t have”
- 115. but you still need someone to make it work
- 116. you need balance
- 118. devs design schema
- 119. BLASPHEMY!
- 120. (devs) meet with project managers
- 122. (devs) understand the app
- 123. confer with dba’s if you have questions!
- 124. if you had a {perl|php|ruby|python|javascript} python question, you would ask a senior dev
- 125. dba’s are your senior devs wrt databases
- 126. have a style guide for schema design
- 127. schema changes become migrations
- 128. new stuff, changed stuff
- 129. all migrations must be reviewed
- 130. look for red flags
- 131. nulls, indexes, datatypes, constraints
- 132. what’s the impact?
- 133. locking, data rewrites, other stuff that sucks
- 134. 1000 Pushes A Day?
- 135. No
- 136. remember locking?
- 137. you have peak times
- 138. build schema change windows around off-peak hours
- 139. once a week
- 140. once a day
- 141. just not during lunch
- 142. you can’t eliminate risk
- 143. minimize the unnecessary risk
- 144. and it’s worth pointing out
- 145. schema changes should not be married to code changes
- 146. if your feature launches next week, push the schema changes this week
- 147. add columns well in advance of writing to them
- 148. stop writing to columns well before dropping them
- 149. like development, it is easier to digest small, incremental changes
- 150. devops has changed the way we think
- 151. dba’s are the original devops
- 152. it’s time we all got on the same team