Set-up regular spreadfirefox.authstage db refresh



11 years ago
4 years ago


(Reporter: alex, Assigned: fox2mike)





11 years ago
Could we please get the database on spreadfirefox.authstage refreshed with current production on a daily basis?

Right now I think we have to do it by hand...

Comment 1

11 years ago
I  think it might be  better to pull the production database to stage following a commit to subversion and prior to testing the changes to scripts / database schema on stage. 

If the database on stage is scheduled to be refreshed with what is currently on production on a daily basis it is possible that the following could happen

1. a commit happens to subversion with changes for scripts and database schema
2. these changes are operational on stage
3. the production database is then copied over from stage
4. problems arise as result of new scripts and a previous database schema  and the site unexpectedly breaks


Comment 2

11 years ago
I'm somewhat wary about doing any sort of "big" operation like this (import the database) whenever you do a commit.  But perhaps we could set something up so that there's a dummy file, and whenever that file is changed, we pull in the latest database?

I assume that we currently have an auto-checkout script on the stage server.  So we could add a cron that runs every few minutes that says "if this file is newer than we last saw, then re-import the database."  That way it's still automatic, but you get control over when it happens and we don't do it on every checkin.

Assignee: server-ops → mark

Comment 3

11 years ago
Sounds like a good plan to me.

I'm not sure if we have an auto db import script now....

Comment 4

11 years ago
Great idea Mark :-)

Comment 5

11 years ago
Okay then, please tell me what file you want to key this on?

Also, what is involved in the actual refresh process?  Take the latest production SQL and copy it over to staging?  That's easy and straightforward, are there any gotchas?

Comment 6

11 years ago
the only gotcha is to make sure to dump the binary data correctly. Oremj, can you provide the details of that? 

Comment 7

11 years ago
oremj - is that the --hex-blob or whatever you added to the dump script?  Can I assume that with that in place, it's a simple matter of "cat foo.sql | mysql" to import this dump?
It was removing --hex-blog from the mysqldump command.

Comment 9

11 years ago
I still need to know what file to key this on.  Just give me an svn path to something that you will update whenever you want to update the database.  Thanks.
Closing since I haven't gotten any info in about a month.  If you decide what file to key this off of, or come up with another way of doing this, please reopen.  Thanks.
Last Resolved: 11 years ago
Resolution: --- → INCOMPLETE

Comment 11

11 years ago

Have we done this anywhere in the past that we can use as a best practice? If not, key off of trunk/db-update/flag (which does not exist, yet)

Resolution: INCOMPLETE → ---

Comment 12

11 years ago
thanks to buchanae, the flag is in r16327
Amazing, wait a month for a response and nothing, close the bug and get one in 36 minutes.  :p

To my knowledge there is no existing system that lets developers choose when to update staging.  Given you don't have access to the staging servers, we have traditionally gone with 'updates every night' or 'updates when you ask IT.'

Since you want something in the middle, 'let us choose when to update but not rely on IT', then we have to come up with a new way of doing it.  This seems to be the easiest way, IMO.  Open to suggestions though.  :)


I've gone ahead and set this up.  Every 5 minutes, it checks the latest revision on that file.  If it's greater than the last check, it initiates the import process.  Note that a full dump and import takes about 10 minutes, and the cron runs every 5 minutes, so it'll take 15-20 minutes for you to see the results of your commit.

During the course of testing, I ran the import.  I realized afterwards that this might not be a good idea if there's stuff going on on authstage that would be bad to import a DB over.  Sorry if I've mucked anything up.
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
Does anyone know where this was set up?
I think that it's setup on khan or dracula.

There's a cron that runs every few minutes that checks to see if the revision of a certain file has changed.  If so, then it will go ahead and import the latest nightly backup (which is what makes me think it's on khan or dracula, since the backups are stored there).
Found it just now while looking for something else.
Could someone check if this is still set up properly?

I tried updating the timestamp, but I haven't seen the stage DB update yet.

Assignee: mark → server-ops
Severity: minor → major
Resolution: FIXED → ---


10 years ago
Assignee: server-ops → shyam
QA Contact: justin → mrz

Comment 18

10 years ago
Seems to be running :

[root@mradm02 sfx-update]# cat sfx-last-version 

Comment 19

10 years ago
The scripts and the cron job seem alright. I'm running the script by hand now to verify that it's working.

Comment 20

10 years ago

Aug 24 09:06:01 mradm02 crond[11675]: (root) CMD (/root/bin/sfx-update/
Aug 24 09:11:01 mradm02 crond[12593]: (root) CMD (/root/bin/sfx-update/
Aug 24 09:16:01 mradm02 crond[13716]: (root) CMD (/root/bin/sfx-update/
Aug 24 09:21:01 mradm02 crond[14661]: (root) CMD (/root/bin/sfx-update/
Aug 24 09:26:01 mradm02 crond[15451]: (root) CMD (/root/bin/sfx-update/
Aug 24 09:31:01 mradm02 crond[16697]: (root) CMD (/root/bin/sfx-update/
Aug 24 09:36:01 mradm02 crond[17579]: (root) CMD (/root/bin/sfx-update/
Aug 24 09:41:01 mradm02 crond[18500]: (root) CMD (/root/bin/sfx-update/
Aug 24 09:46:01 mradm02 crond[19610]: (root) CMD (/root/bin/sfx-update/
Aug 24 09:51:01 mradm02 crond[20494]: (root) CMD (/root/bin/sfx-update/
Aug 24 09:56:01 mradm02 crond[21309]: (root) CMD (/root/bin/sfx-update/
Aug 24 10:01:01 mradm02 crond[22657]: (root) CMD (/root/bin/sfx-update/
Aug 24 10:06:01 mradm02 crond[23693]: (root) CMD (/root/bin/sfx-update/
Aug 24 10:11:01 mradm02 crond[24606]: (root) CMD (/root/bin/sfx-update/
Aug 24 10:16:01 mradm02 crond[25752]: (root) CMD (/root/bin/sfx-update/
Aug 24 10:21:01 mradm02 crond[26687]: (root) CMD (/root/bin/sfx-update/
Aug 24 10:26:01 mradm02 crond[27507]: (root) CMD (/root/bin/sfx-update/
Aug 24 10:31:01 mradm02 crond[28817]: (root) CMD (/root/bin/sfx-update/

Comment 21

10 years ago
And when run by hand :

[root@mradm02 sfx-update]# ./ 
Dumping up to date copy of SFX...
   importing to stage...

So, this seems to be working fine. The cron job runs every 5 mins and well, takes 10-15 mins to I think ideally, you shouldn't be running this for more twice an hour, to give it time to complete correctly.

Comment 22

10 years ago
Looks good, closing.

Alex, feel free to reopen if it doesn't work.
Last Resolved: 11 years ago10 years ago
Resolution: --- → FIXED
I tried again today, and I haven't seen the database update,

Resolution: FIXED → ---
Running from the CLI returns instantly:

[root@mradm02 cron.d]# cd  /root/bin/sfx-update/             
[root@mradm02 sfx-update]# ./ 
[root@mradm02 sfx-update]# 

If run the commands within, both CURVER and LASTVER match:

[root@mradm02 sfx-update]# svn log 2>/dev/null | grep "^r" | head -1 | awk '{ print $1 }' | sed 's/^r//'
[root@mradm02 sfx-update]# cat /root/bin/sfx-update/sfx-last-version

So the whole if[] block is skipped.

Appears working then?

Comment 25

10 years ago

When the flag is updated, while the runs, for some reason, even when the numbers don't match, it doesn't seem to be calling the script. Or somehow failing in between.

I was thinking we should just integrate the two (since we know that is being called by cron without any issues).

Comment 26

9 years ago
I've intgrated the scripts, re-open if this doesn't work the next time, and I'll poke at it again.
Last Resolved: 10 years ago9 years ago
Resolution: --- → FIXED
Tried this today, it's been a few hours and I don't see the stage has synced with production.
Resolution: FIXED → ---

Comment 28

9 years ago
I refactored this a little bit, and when I was done the cron automatically ran..and it seemed to work. 

We can test this again once before we close this...probably when you're up in the morning.

ok, checked in a test update to the flag file,

Sending        db-update/flag
Transmitting file data .
Committed revision 53459.

Comment 30

9 years ago

I fixed a max_allowed_packet issue and added a lockfile to make sure we don't have more than one instance of this running at a time.

This cron currently runs every 5 mins, do we want that frequency? The run by hand (twice) took about 30 mins to finish, I'm going to run it by cron once and then can you please do a check for me in the morning?
it worked!

many thanks for all your help on this.
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
Product: → Graveyard
You need to log in before you can comment on or make changes to this bug.