One of the rea[s]ons for the new 3 day downtime. I did wonder at one time whether they were pushing the Informix database to its limits but it appears not, there are larger ones out there.

Except that Boinc (s@h) uses the one database for all of the data AND all of the system state changes for all users...

I still wonder if the processing speed of Boinc for a project is limited by the (single threaded) serial updates maximum write speed of the one database log file...


Hang in there Matt and gang!

Happy crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

One of the rea[s]ons for the new 3 day downtime. I did wonder at one time whether they were pushing the Informix database to its limits but it appears not, there are larger ones out there.

Except that Boinc (s@h) uses the one database for all of the data AND all of the system state changes for all users...
...
Martin

The BOINC database is MYSQL, and does cover a lot of territory: all of the infrastructure which BOINC provides. The S@H science database, and probably the Astropulse science database, are Informix (though one of the rare Berkeley SETI blog entries mentioned that Eric was thinking of converting to MYSQL for that too).

                                                               Joe

The Server Status Page describes Mork as the Primary BOINC database, with Jocelyn being the replica. But many posts from the admins say that "the replica is down", or "the replica is recovering", yet Mork is said to be the problem child with many untimely crashes (there is never a timely crash, of course). So, for clarification, is Mork being used as the Primary or the Replica?
Thanks

Good question. When mork crashes, its relay logs are then in a funny/inconsistent state, which means the replica is unable to work with these relay logs. The easiest way to fix that is to dump the whole database on mork and "recover" the replica from that dump - then everything is consistent again.

- Matt

The Server Status Page describes Mork as the Primary BOINC database, with Jocelyn being the replica. But many posts from the admins say that "the replica is down", or "the replica is recovering", yet Mork is said to be the problem child with many untimely crashes (there is never a timely crash, of course). So, for clarification, is Mork being used as the Primary or the Replica?
Thanks

---

-- BOINC/SETI@home network/web/science/development person
-- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude

Good question. When mork crashes, its relay logs are then in a funny/inconsistent state, which means the replica is unable to work with these relay logs. The easiest way to fix that is to dump the whole database on mork and "recover" the replica from that dump - then everything is consistent again.

- Matt

Gosh, Matt, I remember having this problem with MSSQL Server 2k, back in the day. Basically, the company didn't want to buy the enterprise license, so I wrote scripts to perform log shipping manually. After the first catastrophic failure, I changed the scripts to backup the logs to a separate (fast) file server instead. That way, the log backup (on master) and log restore (on replica) can happen asynchronously. Even in the event of master failing, I can resume the logs from the standby from the point of failure. Not sure of the details of MySQL, but this should be possible if you have said file server available. Point is, reading logs from the master directly from the replica has never been robust for me.