Closed Bug 479854 Opened 16 years ago Closed 16 years ago

Cannot create articles on staging

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: cilias, Assigned: justdave)

References

Details

(Whiteboard: regression)

If this gets passed on to prod, then I consider it to block 0.9. Go to <https://support-stage.mozilla.org/en-US/kb/Creating+articles>, and try to create an article. The connection times out ("The connection to the server was reset while the page was loading.") Email notification is sent, telling me that the object was added, but the URL says the article does not exist. <https://support-stage.mozilla.org/en-US/kb/testest> Clicking on "Create this page" gives me a blank body (no content in markup area), even though I created the page with the "test" in the body.
Blocks: 478685
Target Milestone: --- → 0.9
Setting to 0.9. Just in case...
I can't seem to produce this locally. I've tried two separate boxes, both at r22525. Can anyone test for this locally so we can confirm this is a staging only problem? 404's are thrown at webroot/tiki-index.php:238. The conditional is at 218.
Maybe Paul can give it a try on his dev instance?
I can give it a try, tomorrow evening. Hectic first day, sorry.
Sounds like Eric is working on this - assigning. Sounds like we want to hold 0.9 until we can confirm?
Assignee: nobody → smirkingsisyphus
Yes, it should block 0.9 until we can confirm it's something on staging and not the code.
OK, marking blocker.
Severity: critical → blocker
Anything involving db writes seems to be affected. Watches, forums, etc. If we're using multiple databases, it seems like a data replication issue. It could be a caching Sometimes, new data will show up, sometimes it won't. We aren't getting any db errors, so it would seem that the data just isn't there. If a few folks can confirm, I'll re-title and reassign to IT.
I wonder if bug 436878 is also affected by this. I couldn't verify it works on staging, but on my local copy it's just fine. Also, I've determined that the problem is that the preferences don't get saved in the admin area. And that has to do with saving in the tiki-preferences table of the database. Since I can't reproduce this locally, it seems to be a database issue.
Laura/Nelson, you're more familiar with the IT setup than Paul and I. Is comment 8 a reasonable assumption? This appears to be a staging-only issue.
Blocks: 444703
Replication died on the staging database cluster two weeks ago, and someone acked the page without fixing it. :( I'm resyncing the databases now.
Assignee: smirkingsisyphus → justdave
Component: Knowledge Base Software → Server Operations
Product: support.mozilla.com → mozilla.org
QA Contact: kb-software → mrz
Target Milestone: 0.9 → ---
Version: unspecified → other
ETA on getting the master database back online is about 30 minutes. Probably about 90 minutes after that to get the slave synced up again.
Master's up. I'll post again when the slave is back online.
Slave's up finally. 167 minutes elapsed time for the restore to the slave. Turns out someone disabled the automatic slave-start when mysql starts on the slave for some reason. Don't know why, but that's been taken out, so it'll automatically start replicating at launch in the future. Likely what happened is it never started replicating after the kernel reboots a week or two ago.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.