| Anonymous | Login | Signup for a new account | 2013-05-21 10:32 PDT |  |
| Main | My View | View Issues | Change Log | Repositories |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||
| 0000182 | Friendica | backend | public | 2011-10-17 13:00 | 2011-10-18 00:23 | ||||||
| Reporter | chriscase | ||||||||||
| Assigned To | |||||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||||
| Status | new | Resolution | open | ||||||||
| Platform | OS | OS Version | |||||||||
| Product Version | |||||||||||
| Fixed in Version | |||||||||||
| Summary | 0000182: Updating large tables (such as 'item') fires off multiple times | ||||||||||
| Description | I updated my system today and noticed, when using mytop to monitor transactions, that the "item" table was being updated with the same column multiple times. The update script does not check to see if the command is already running before firing off another alter table. This hoses friendika and makes it so everything must be done manually. Part of the reason for this is that friendika checks to see if the update is *completed* and if not, fires it off again. This leads to possibly dozens of 'alter table' statements being fired off. On a large table such as 'item' this can cripple a node. | ||||||||||
| Steps To Reproduce | On a large node which hasn't been updated in a few weeks, perform a git pull, then visit the node's front page. It will start kicking off 'alter table' statements which probably won't complete. | ||||||||||
| Tags | No tags attached. | ||||||||||
| Attached Files | |||||||||||
 Relationships |
|
 Relationships |
|
Notes |
|
|
(0000271) chriscase (developer) 2011-10-17 13:04 |
This PHP command mysql_list_processes() may be of use. Docs for this command are here: http://www.php.net/manual/en/function.mysql-list-processes.php [^] |
|
(0000272) macgirvin (administrator) 2011-10-17 14:26 |
For large sites with a lot of activity I think we need to provide an alternative to the automatic update which basically puts the system in maintenance mode and blocks normal DB access until the update (manually initiated via an alternative DB interface that isn't blocked) is completed. |
|
(0000273) macgirvin (administrator) 2011-10-18 00:23 |
[master 0609648] hopefully solve db update issues bug 0000182 Hopefully this will work without re-architecting the entire update process. We're now setting a config variable prior to performing an update step, and ignoring the update completely if another process has already set the variable. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2011-10-17 13:00 | chriscase | New Issue | |
| 2011-10-17 13:04 | chriscase | Note Added: 0000271 | |
| 2011-10-17 14:26 | macgirvin | Note Added: 0000272 | |
| 2011-10-18 00:23 | macgirvin | Note Added: 0000273 | |
|
Issue History |
| Copyright © 2000 - 2010 MantisBT Group |
 |