-
Notifications
You must be signed in to change notification settings - Fork 38
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
Extremely long sync with some DBs (e.g. BU) #727
Comments
for illinois I switched to running it at midnight, that way next morning database is synced. This is something I want to look at in the future (time permitting). Question is do you need to sync so frequently? Probably worth it to check on how frequently things change. |
Is it mostly a particular (eg runs) table / set of tables? We could
consider cleaning out the unnecessary records and / or only syncing those
tables infrequently?--
David
…--
David LeBauer
Director of Data Sciences
CALS Comm and Technologies
THE UNIVERSITY OF ARIZONA
BSRL, 207
1230 N Cherry Ave | Tucson, AZ 85721
Office: 520-621-4381 | Cell: 760-468-8621
***@***.***
datascience.cals.arizona.edu
orcid | twitter | github | linkedin
|
@dlebauer that is a good idea, we can skip the runs table, which will be the biggest set. That is a quick (famous last words) fix. |
I also will note seeing errors like this on some occasions
The rationale for syncing more is that for collaborative projects (e.g .NASA CMS) across institutions there may be/is a need to be able to share updated posteriors etc. Waiting 24hrs between syncs could be an issue. I am game to try a more complicated sync where we sync what we can more often and only sync say the runs every 1 day or so. |
I think so , or at least there is still an issue. Perhaps not the same as the missing file. See below for the sync log. it looks like the syncing still times out before it gets trhough all of the tables
|
Pretty sire I have raised this before but when our DB has gone done for a period of time and I re-enable the sync, syncing with BU takes / can take a very long time (hours). Even during the course of normal operation and syncing it sometimes doesnt finish before my next sync cron job starts.
Does anyone have any suggestions on how they are managing to keep their DBs synced but avoiding jobs not completing before the next? Should I create a separate sync with BU that runs slower than say with WI and UIUC?
Feedback requested.
The text was updated successfully, but these errors were encountered: