*** jonaspf has quit IRC | 00:51 | |
*** jonaspf has joined #openstack-freezer | 00:55 | |
*** jonaspf has quit IRC | 01:23 | |
*** reldan has quit IRC | 01:30 | |
*** jonaspf has joined #openstack-freezer | 01:40 | |
*** reldan has joined #openstack-freezer | 01:41 | |
*** reldan has quit IRC | 02:01 | |
*** jonaspf has quit IRC | 02:18 | |
*** jonaspf has joined #openstack-freezer | 03:02 | |
*** jonaspf has quit IRC | 03:17 | |
*** jonaspf has joined #openstack-freezer | 03:19 | |
*** jonaspf has quit IRC | 03:55 | |
*** jonaspf has joined #openstack-freezer | 03:57 | |
*** jonaspf has quit IRC | 05:11 | |
*** jonaspf has joined #openstack-freezer | 05:13 | |
*** jonaspf has quit IRC | 05:28 | |
*** jonaspf has joined #openstack-freezer | 05:36 | |
*** jonaspf has quit IRC | 07:14 | |
*** jonaspf has joined #openstack-freezer | 07:24 | |
*** jonaspf has quit IRC | 07:43 | |
*** jonaspf has joined #openstack-freezer | 07:48 | |
*** memogarcia has joined #openstack-freezer | 08:23 | |
*** jonaspf has quit IRC | 09:08 | |
*** jonaspf has joined #openstack-freezer | 09:21 | |
*** jonaspf has quit IRC | 09:39 | |
*** jonaspf has joined #openstack-freezer | 09:49 | |
*** reldan has joined #openstack-freezer | 10:08 | |
*** jonaspf has quit IRC | 10:22 | |
*** jonaspf has joined #openstack-freezer | 10:29 | |
*** reldan has quit IRC | 10:30 | |
*** jonaspf has quit IRC | 11:34 | |
*** memogarcia has quit IRC | 11:35 | |
*** jonaspf has joined #openstack-freezer | 11:50 | |
*** reldan has joined #openstack-freezer | 12:09 | |
*** memogarcia has joined #openstack-freezer | 12:14 | |
*** marzif has joined #openstack-freezer | 12:16 | |
*** jonaspf has quit IRC | 12:18 | |
*** jonaspf has joined #openstack-freezer | 12:23 | |
*** memogarcia has quit IRC | 12:25 | |
*** jonaspf has quit IRC | 13:02 | |
*** jonaspf has joined #openstack-freezer | 13:07 | |
*** memogarcia has joined #openstack-freezer | 13:15 | |
*** jonaspf has quit IRC | 13:51 | |
*** jonaspf has joined #openstack-freezer | 14:11 | |
*** jonaspf has quit IRC | 14:37 | |
*** reldan has quit IRC | 14:43 | |
*** reldan has joined #openstack-freezer | 15:02 | |
*** dschroeder has joined #openstack-freezer | 15:04 | |
*** jonaspf has joined #openstack-freezer | 15:18 | |
*** marzif has quit IRC | 15:35 | |
*** memogarcia has quit IRC | 15:41 | |
*** reldan has quit IRC | 15:54 | |
*** jonaspf has quit IRC | 16:01 | |
*** marzif has joined #openstack-freezer | 16:05 | |
*** jonaspf has joined #openstack-freezer | 16:14 | |
*** jonaspf has quit IRC | 16:29 | |
daemontool_ | all: https://wiki.openstack.org/wiki/Freezer | 16:33 |
---|---|---|
*** jonaspf has joined #openstack-freezer | 16:38 | |
*** marzif has quit IRC | 17:08 | |
*** marzif has joined #openstack-freezer | 17:09 | |
*** marzif has quit IRC | 17:15 | |
*** marzif has joined #openstack-freezer | 17:16 | |
*** reldan has joined #openstack-freezer | 17:16 | |
*** marzif has quit IRC | 17:18 | |
*** marzif has joined #openstack-freezer | 17:19 | |
*** jonaspf has quit IRC | 17:41 | |
*** marzif has quit IRC | 17:49 | |
*** marzif has joined #openstack-freezer | 17:50 | |
*** marzif has quit IRC | 17:55 | |
*** jonaspf has joined #openstack-freezer | 18:02 | |
*** memogarcia has joined #openstack-freezer | 18:05 | |
*** jonaspf has quit IRC | 18:25 | |
*** jonaspf has joined #openstack-freezer | 18:35 | |
*** memogarcia_ has joined #openstack-freezer | 18:36 | |
*** memogarcia has quit IRC | 18:36 | |
*** jonaspf has quit IRC | 18:50 | |
*** jonaspf has joined #openstack-freezer | 18:55 | |
*** federico3 has joined #openstack-freezer | 18:59 | |
federico3 | hi there | 18:59 |
daemontool_ | Hi federico3 | 19:01 |
daemontool_ | any way we can help? : ) | 19:04 |
federico3 | daemontool_: thanks for asking! I'm trying to add Freezer support to my team's product - Designate and I'm looking for some pointers. | 19:06 |
daemontool_ | ok | 19:06 |
federico3 | We want to back up the contents of a Percona database, should we use the regular mysql adoptor or a Percona tool? | 19:06 |
daemontool_ | the answer is easy, but long :) | 19:07 |
federico3 | Are you aware of other projects that are using Mysql + Freezer that I can look at ? | 19:07 |
daemontool_ | how big it is your db? | 19:07 |
federico3 | Relatively small, in the order of tenths of MB rather than GB | 19:07 |
daemontool_ | does the backup needs to be synchronized with any other service? | 19:08 |
federico3 | and with a good compress ratio | 19:08 |
daemontool_ | i.e. you need to take the db and the data needs to be point-in-time consistent with some other service? | 19:09 |
federico3 | in terms of other services fetching backups to do something with it? No Or running all the backups at the same time? Neither | 19:09 |
*** jonaspf has quit IRC | 19:09 | |
daemontool_ | like, i.e. if you backup nova, you may need also to backup keystone db as the users/tenants needs to own the vms... | 19:10 |
daemontool_ | that kind of cases... | 19:10 |
federico3 | btw, is up to our hosts to start backups when needed or is Freezer managing the backup runtimes centrally? | 19:10 |
daemontool_ | it can be both ways | 19:10 |
daemontool_ | so, if you need for example, for disaster recovery, have your backup solution support multiple storage back ends, I advice you to use freezer | 19:11 |
daemontool_ | i.e. swift or ssh or localfs (nfs mounted for instance) | 19:11 |
daemontool_ | encrypted, etc but I think percona can encrypt too | 19:11 |
federico3 | this could be user-configurable but I'd expect Swift to be the default choice | 19:12 |
daemontool_ | ok, I'm asking because, if you need to restore things, and keystone is down... and you didn't thought about it before hand... you can't restore | 19:12 |
daemontool_ | so freezer support multiple backup ends | 19:12 |
federico3 | It's a DNS API; given that there's no auth data and most DNS data is public maybe encryption might be off by default | 19:13 |
daemontool_ | and withing the next 4 weeks also parallel back end | 19:13 |
daemontool_ | ok | 19:13 |
daemontool_ | if the dataset is small | 19:13 |
daemontool_ | and you don't need any sync with other services (ie. synchronized backup over multiple nodes) you can use percona | 19:13 |
daemontool_ | it's good... it works... | 19:14 |
daemontool_ | it is fast .... | 19:14 |
federico3 | (Are you aware of other projects that are using Mysql + Freezer that I can look at ? I'm searching GitHub for examples) | 19:14 |
daemontool_ | I work in hp | 19:14 |
daemontool_ | I can tell you what here is using it | 19:14 |
federico3 | me too :) | 19:15 |
daemontool_ | there's deutsche telekom using it to backup some nodes | 19:15 |
daemontool_ | onto swift | 19:16 |
daemontool_ | not sure if it is used for mysql | 19:16 |
daemontool_ | I've been using it extensively to backup gerrit and the cicd platform of the hp public cloud | 19:16 |
daemontool_ | for more then 1 year | 19:16 |
daemontool_ | now it's being used in helion to backup the percona cluster | 19:16 |
federico3 | I meant projects (e.g. LBaaS, celiometer...) | 19:17 |
daemontool_ | so we are backing up the swift rings with freezer | 19:17 |
daemontool_ | and the mysql db for all of the core projects | 19:17 |
daemontool_ | so we are backing mysql for all of them in helion | 19:17 |
federico3 | great! Btw, why is LVM used when backing up mysql? | 19:18 |
daemontool_ | I don't think in a cloud environmen percona is a better solution, cause you need to take point-in-time immutable data | 19:18 |
daemontool_ | cause with lvm freezer tell to mysql "flush tables with read lock"; create the lvm snapshot read only; unlock the tables; start the backup | 19:19 |
daemontool_ | and if you need to do that on two nodes (i.e. /var/lib/nova in the compute nodes) and the mysql db | 19:20 |
daemontool_ | you need to have a mechanism that allows you to take an lvm snapshot in the most close time as possible on the involved nodes.... | 19:20 |
daemontool_ | so there are no or little difference on the data state | 19:20 |
daemontool_ | and we use lvm to do that with job sessions | 19:20 |
federico3 | is Freezer handling the distributed locking? | 19:20 |
daemontool_ | where? | 19:21 |
daemontool_ | nope | 19:21 |
daemontool_ | there's no need to do that | 19:21 |
*** jonaspf has joined #openstack-freezer | 19:21 | |
daemontool_ | we just take an lvm snapshot read only | 19:21 |
daemontool_ | on the master node | 19:21 |
daemontool_ | while on multi master, you can do it on anynode | 19:21 |
daemontool_ | (I mean percona multi master) | 19:22 |
federico3 | we simply trust that the flush command will start at roughly the same time across every host? | 19:22 |
daemontool_ | we do that only on one node | 19:22 |
daemontool_ | as to reduce the data corruption | 19:22 |
federico3 | oh in multi master - of course | 19:22 |
daemontool_ | we need to make sure all the data hold in memory | 19:22 |
daemontool_ | is written to the disk | 19:22 |
daemontool_ | as long we have the in memory data written to the disk... | 19:23 |
daemontool_ | we can reduce the data corruption risks | 19:23 |
daemontool_ | on this scenario what is not replicated from other master, is just not part of the backup | 19:23 |
federico3 | you seems to be ruling out mysqldump as an option? | 19:23 |
daemontool_ | mmmhhh nope | 19:24 |
daemontool_ | because mysqldump even though has many option | 19:24 |
daemontool_ | but it is slowest than lvm snap | 19:24 |
daemontool_ | and lock the db for the whole time you are dumping the db | 19:24 |
federico3 | in our use case the amount of data is moderate - but critical, so the balance is shifted all the way on the reliability side :) | 19:24 |
daemontool_ | if you do not lock with mysql dump, the data might change... | 19:25 |
daemontool_ | therefore the risk of data corruption can eb increased | 19:25 |
daemontool_ | I agree | 19:25 |
daemontool_ | lower risk of data corruption is way important then anything | 19:25 |
daemontool_ | totally agree | 19:25 |
federico3 | I'll investigate but it's likely that we can block writes for a long enough time do do a mysqldump | 19:26 |
daemontool_ | ok, where do you plan to store the output of mysqldump? | 19:26 |
daemontool_ | on the local disk? | 19:26 |
federico3 | (and the write traffic is modest as well) | 19:26 |
daemontool_ | so in your case that can be ok | 19:26 |
daemontool_ | but if your db is 30-50 or 100GB | 19:27 |
federico3 | either local disk or - can freezer ingest it and stream it to Swift on the fly? | 19:27 |
federico3 | more like 100MB :) | 19:27 |
daemontool_ | that mean you need by requirements the double of the space of your data set size | 19:27 |
federico3 | of course | 19:27 |
daemontool_ | yes | 19:27 |
daemontool_ | same for restore | 19:27 |
daemontool_ | in your case it's all good | 19:27 |
daemontool_ | percona when restoring needs to prepare the data | 19:28 |
daemontool_ | so you might need the double of the space locally | 19:28 |
daemontool_ | of the data set size | 19:28 |
daemontool_ | yes freezer do everything in stream | 19:28 |
daemontool_ | for backup and for restoer | 19:29 |
daemontool_ | do you need to backup also any config file? | 19:29 |
federico3 | potentially | 19:29 |
daemontool_ | in that case freezer it's ok, as you can backup mysql and files on the file system | 19:30 |
federico3 | yup! | 19:30 |
daemontool_ | if the files | 19:30 |
daemontool_ | are modified after the first deployment | 19:30 |
daemontool_ | you may need to backup them | 19:31 |
daemontool_ | unless you manage configs with tools like puppet or chef | 19:31 |
federico3 | that's up to the end user | 19:31 |
federico3 | probably we could back up a handful of small and very static config files just in case | 19:32 |
daemontool_ | what do you think if you provide to the end user also the backup so he/she can forget about it :) | 19:32 |
daemontool_ | you can provide all the backup already setup, and the procedure for restore | 19:32 |
daemontool_ | and how to verify if the backups works | 19:32 |
daemontool_ | every n months | 19:32 |
federico3 | speaking of restore: are restores triggered centrally from the Freezer UI or do product owners implement a big red button in each product? | 19:33 |
daemontool_ | you can trigger them from the freezer ui | 19:34 |
daemontool_ | or from the freezer-scheduler | 19:34 |
daemontool_ | or just manually using the freezer-agent | 19:34 |
daemontool_ | case if keystone is down.... you don't have api or web ui | 19:34 |
daemontool_ | it depends a bit on the environment the user find himself, when he needs the restore | 19:35 |
federico3 | daemontool_: thank you very much, I'll investigate | 19:42 |
daemontool_ | federico3, you are welcome, just let us know if you need anything : ) | 19:45 |
daemontool_ | ah.... it's in roadmap also the backup of postgres and oracle standard edition... | 19:46 |
daemontool_ | that will happen soon, just fyi in case you have a user that needs backup as a service integrated in openstack to do that :) | 19:46 |
federico3 | thanks :) | 19:47 |
*** reldan has quit IRC | 19:55 | |
*** reldan has joined #openstack-freezer | 19:56 | |
*** jonaspf has quit IRC | 20:02 | |
*** jonaspf has joined #openstack-freezer | 20:05 | |
*** jonaspf has quit IRC | 20:29 | |
*** jonaspf has joined #openstack-freezer | 20:39 | |
*** jonaspf has quit IRC | 20:58 | |
*** reldan has quit IRC | 20:59 | |
*** reldan has joined #openstack-freezer | 21:20 | |
*** jonaspf has joined #openstack-freezer | 21:28 | |
*** jonaspf has quit IRC | 21:43 | |
*** jonaspf has joined #openstack-freezer | 21:46 | |
*** jonaspf has quit IRC | 22:26 | |
*** jonaspf has joined #openstack-freezer | 22:29 | |
*** reldan has quit IRC | 22:54 | |
*** jonaspf has quit IRC | 23:01 | |
*** reldan has joined #openstack-freezer | 23:03 | |
*** dschroeder has quit IRC | 23:07 | |
*** jonaspf has joined #openstack-freezer | 23:09 | |
*** jonaspf has quit IRC | 23:25 | |
*** reldan has quit IRC | 23:32 | |
*** jonaspf has joined #openstack-freezer | 23:36 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!