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.

Sign up for GitHub

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

Jump to bottom

Reduce Aurora durability for better write performance #29067

Merged
merged 1 commit into from Jun 11, 2019
Merged

Reduce Aurora durability for better write performance #29067

merged 1 commit into from Jun 11, 2019

Conversation

sureshc
Copy link
Contributor

@sureshc sureshc commented Jun 11, 2019 •
edited 

MacBook:code-dot-org suresh$ bundle exec rake stack:data:validate RAILS_ENV=production
Data layer including RedShift cluster configuration and synchronization with RDS instance.
Listing changes to existing stack `DATA-production`:
Modify AuroraClusterDBParameters [AWS::RDS::DBClusterParameterGroup] Properties (Parameters)

@sureshc
Copy link
Contributor Author

sureshc commented Jun 11, 2019 •
edited

Stack update applied:

MacBook:code-dot-org suresh$ bundle exec rake stack:data:start RAILS_ENV=production
update stack: DATA-production...
Stack update requested, waiting for provisioning to complete...
2019-06-11 22:38:58 UTC- DATA-production [UPDATE_IN_PROGRESS]: User Initiated
.2019-06-11 22:39:10 UTC- AuroraClusterDBParameters [UPDATE_IN_PROGRESS]
2019-06-11 22:39:12 UTC- AuroraClusterDBParameters [UPDATE_COMPLETE]
.2019-06-11 22:39:15 UTC- DATA-production [UPDATE_COMPLETE_CLEANUP_IN_PROGRESS]

Stack update complete.
Outputs:

@sureshc sureshc merged commit c6ccfa2 into staging Jun 11, 2019
@sureshc sureshc deleted the reduce-aurora-durability branch June 11, 2019 22:49
wjordan
wjordan approved these changes Jun 11, 2019
View reviewed changes
Copy link
Contributor

@wjordan wjordan left a comment

Choose a reason for hiding this comment

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

👍
We might also want to compare a setting of 2 as well (which writes data but does not do a synchronous OS flush, so slightly better durability in case of process but not OS crash), but either 0/2 should give us a good idea of the performance tradeoff.

@sureshc
Copy link
Contributor Author

sureshc commented Jun 11, 2019

I thought that you had advised using 0 on Aurora because the the OS flush was not relevant with Aurora’s custom storage system?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@wjordan wjordan wjordan approved these changes

@uponthesun uponthesun uponthesun approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
3 participants
@sureshc @wjordan @uponthesun