-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add support for RDS DB with read replica #15
Conversation
5d15a6a
to
b019cfa
Compare
Putting this PR on hold whilst the |
201da73
to
390be5e
Compare
This comment was marked as resolved.
This comment was marked as resolved.
e3c6726
to
ff0ba55
Compare
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.
Looks good to me, and I was also able to get the functional tests working rebased off this branch with a small update 👍.
The read replica functionality is kept locally to ensure it doesn't break functionality
`format` can fix issues `check` can't.
ff0ba55
to
b74f147
Compare
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.
Code looks fine, unable to test for 'real' atm.
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.
Reviewed =) Have no comments. Some of the code here overlapped with some things I was looking into to come up with the solution for the BDD UI test suite issues, particularly the code in test_db_router.py tests interestingly.
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.
LGTM!
What is the context of this PR?
IAM authentication
In production, rather than a username and password, authentication to the database will be done using IAM. This means there are no credentials to leak or rotate.
When a connection is opened, a signed token is generated and used for authentication. This token is only valid for 15 minutes. The complexities of this are handled by an external library.
Connecting the application to IAM itself is done by the cluster, hence no additional configuration.
Multiple database connections
In production, multiple database connections will be used: one for writes and one for reads. The write connection points to a single database server, whilst reads are load balanced between a set of servers ("read replicas").
It's up to the application to decide whether the write or read connections is used, which is what the database router handles. Django internally identifies whether a query is a "read" or a "write", and uses the router to identify the connection. Most of the time, there's no need for a developer to worry about this.
Specifically:
Note: AWS is responsible for balancing traffic across the replicas - this is not the responsibility of the application.
For consistency, local development also uses multiple connections handled by the same router, however these point to the same server, and there's no restriction that the read connection only handles reads.
How to review
This shouldn't make a difference to local development.
Relevant Django documentation: https://docs.djangoproject.com/en/5.1/topics/db/multi-db/
Follow-up Actions
There are discussions happening about being able to handle a completely read-only connection. "read replica" functionality is separate.