Timeline for What are the reasons Docker should not be used for databases?
Current License: CC BY-SA 4.0
8 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
S Oct 4, 2018 at 5:11 | history | suggested | Cocowalla | CC BY-SA 4.0 |
Spelling, loosing --> losing
|
Oct 3, 2018 at 19:59 | review | Suggested edits | |||
S Oct 4, 2018 at 5:11 | |||||
Sep 6, 2017 at 1:54 | comment | added | dres | Neither of these points apply to cassandra or other distributed databases but I still don't think running it in a container is a good idea. | |
Jul 10, 2017 at 16:55 | comment | added | Alix Axel | Have you seen flynn.io? They are supposedly production-ready and avoid split-brain scenarios by using a chorum state machine (based on Joyent Manatee). | |
Jun 10, 2017 at 3:45 | vote | accept | hawkeye | ||
Feb 20, 2018 at 8:26 | |||||
Jun 6, 2017 at 10:58 | comment | added | Robo | From your question it seems you're using some kind of orchestration to start the db and mount the volume. But then you have a potential consistency problem with the orchestration, which i talk about. My caveat is explicitly about when you use no orchestration. | |
Jun 6, 2017 at 10:50 | comment | added | hawkeye | Thanks - that's nearly a reasoned answer. In your blog post however - you add a caveat that validates the assumption I've written up the top. "The issues laid out below don’t relate to just running your database in docker with no shared storage or ability to start it automatically on a different node." Ie - your blog post says that the situation I've written about above is valid. | |
Jun 6, 2017 at 9:54 | history | answered | Robo | CC BY-SA 3.0 |