Skip to content
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

[YT-CC-1189] Overlay ey-backup attributes to move MySQL backup to DB slave. #280

Open
wants to merge 1 commit into
base: next-release
Choose a base branch
from

Conversation

mikong
Copy link
Contributor

@mikong mikong commented Oct 23, 2017

Description of your patch

Adds attributes/default.rb to the ey-backup cookbook that determines if the MySQL backup is setup on the master (default) or replica. A sample cookbook in custom-cookbooks is provided to move it to replica.

Fixes #218.

Recommended Release Notes

MySQL backup location is now configurable through attributes overlay.

Estimated risk

Medium - changes the ey-backup/recipes/mysql.rb that's used it many existing environments.

Components involved

MySQL backup

Description of testing done

I setup a test environment running stack stable-v5-3.0.32. I used the custom-cookbooks/db-backup/cookbooks/ey-backup as the base custom cookbook. Then, I had to copy cookbooks/ey-lib due to recent RDS-related changes that's not yet released in stable-v5-3.0.32. After running chef, MySQL backup cron job was removed from the master and added to the replica, as expected. Removing this custom cookbook reverted the change.

QA Instructions

TODO (after code review, in case there are major changes needed)

@@ -41,7 +41,13 @@
end
end

if node.dna['backup_window'] != 0 && ['db_master','solo'].include?(node.dna['instance_role'])
is_backup_instance = if node['db_backup']['mysql']['backup_slave']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It took me a minute to get my head around this. Would it be clearer to assign is_backup_instance explicitly in the two different cases, rather than assigning the result of the if statement? (It would have been clearer to me :D )

@@ -41,7 +41,13 @@
end
end

if node.dna['backup_window'] != 0 && ['db_master','solo'].include?(node.dna['instance_role'])
is_backup_instance = if node['db_backup']['mysql']['backup_slave']
['db_slave'].include?(node.dna['instance_role']) && node['db_backup']['mysql']['db_slave_name'] == node['dna']['name']
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this change means that the customer must specify the name of the replica which should run the backup. What happens if they don't? What happens if the name they specify doesn't exist? Is it possible to gracefully fall back to the same behaviour as PostgreSQL in either of those cases, and just choose the first replica?

(If so then it would be good to have this behaviour for both, and simply set default['db_backup']['mysql']['backup_slave'] true for PostgreSQL while leaving default['db_backup']['mysql']['db_slave_name'] empty by default.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Obviously we would rename the variables if we were making this more general.
Perhaps:
default['db_backup']['run_backup_on_replica']
default['db_backup']['backup_replica_name']

@jegasega jegasega changed the title CC-1189: Overlay ey-backup attributes to move MySQL backup to DB slave. [YT-CC-1189] Overlay ey-backup attributes to move MySQL backup to DB slave. Apr 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants