-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Revert "Store split modulestore's course indexes in Django/MySQL" #28979
Conversation
This reverts commit 96e5ff8.
|
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.
Bummer!
The split_modulestore_django.0001_initial
migration successfully applied on Stage. I assume that reverting that migration (and then later reintroducing it) won't cause any issues?
@kdmccormick: Yeah, I think that'll be fine. |
@bradenmacdonald: I suspect this may be because MongoDB is case sensitive on course_id and MySQL is not. (Trying to verify if this is the issue with this data now.) |
Yeah, it’s totally the case sensitivity thing (capitalization difference in the orgs):
|
@bradenmacdonald: Just as a heads up, edX will be running with limited staffing next week, so my new target deploy date for this would be Oct. 18. |
@ormsbee Argh, ok. Well I knew the probability of something like that was high. Thanks for taking care of the deploy and revert today. |
I'm merging this despite quality failures, cause, revert. |
EdX Release Notice: This PR has been deployed to the staging environment in preparation for a release to production. |
EdX Release Notice: This PR has been deployed to the production environment. |
EdX Release Notice: This PR has been deployed to the staging environment in preparation for a release to production. |
EdX Release Notice: This PR has been deployed to the production environment. |
1 similar comment
EdX Release Notice: This PR has been deployed to the production environment. |
@bradenmacdonald: Another thought for your consideration–I believe the current PR as it stands would introduce a period of time in which writes can get lost (i.e. the gap between when the migrations have run and all the frontends have switched over to the new code). It's only a gap of ten minutes or so, but depending on time of day, that could still result in hundreds of lost edits. The two mitigations I can think of for this are to temporarily bring down Studio or to re-order the elements of this PR so that the code prefers MongoDB for some time until we're sure all the data is migrated over. Thoughts? |
@ormsbee Good point, I wasn't sure how long that time period would be and assumed it was quite short. I think if we change this to read from MongoDB but to write to both (MySQL + MongoDB), we could deploy it without the data migration, and then later run the data migration only for courses which haven't been written to since the original deployment. I think that would avoid any gaps. What do you think? |
That sounds great. |
@ormsbee OK, I'll do that. Unfortunately I didn't get time to do it for Monday AM but I'll try to get it ready for Tuesday. |
@ormsbee Just to be clear, are those two different courses or two different records about the same course? Is this just a concern for migration or for the general case of using this? |
Reverts edx/edx-platform#27565
@bradenmacdonald: The original PR broke migrations on stage. Will add more details later, but starting the revert build now.