-
Notifications
You must be signed in to change notification settings - Fork 248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xtrabackup Template #132
Xtrabackup Template #132
Conversation
I'll review the changeset here, but we should take the backup strategy discussion to the mailing list. |
# Setup apt sources for percona | ||
codename = capture('lsb_release -c -s').chomp | ||
sources = <<-SOURCES | ||
deb http://repo.percona.com/apt #{codename} main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you redo this with a call to apt-add-repository? That should prevent duplicate entries from showing up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I can tell, the opposite is true. Running apt-add-repository multiple times adds the deb lines to /etc/apt/sources.list repeatedly. The way the code currently works it only ever writes the deb lines to /etc/apt/sources.list.d/percona.list which would already be there on percona servers (and therefore simply overwritten on bootstrap) or created for mysql servers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh. I didn't realize percona added the repo itself.
You guys cool with merging this + percona? |
Go for it. |
Xtrabackup template for Rubber. When vulcanized, this will replace itself as the default backup strategy for MySQL and Percona templates. It supports both full and incremental backups (easily switched on with a simple flag). No matter the mode of backup, each backup set is fully "prepared" (in xtrabackup parlance) to allow an immediate restore via the restore util command.
Also amended lib/rubber/commands/util.rb to allow the backupdb command to take an optional -f (filename) flag. This is because the default way of naming backups isn't correct anymore for Xtrabackup since all backups are tar'd and then gzipped. Since it's optional, the committed implementation doesn't use this flag since I didn't want to edit the crontab's anyone would already have in place.
Eventually I'd like to move a lot of this logic from the shell scripts into Rubber. What do you guys think of creating backup strategies just like the DNS strategies? It would require a lot of re-plumbing of existing stuff so I didn't want to go down that rabbit hole if this kind of stuff is preferable.