Geert Janssens <geert.gnuc...@kobaltwit.be> writes: >> > Of course this doesn't help with the service redundancy. If there IS a >> > local issue (hardware, power, network) then the service will go offline >> > until it can be repaired. Granted, I have a large-scale UPS and a >> > natural-gas-powered backup generator so there is no longer a local power >> > outage issue. However HW and ISP issues are a bit more out of my >> > control. >> >> I could provide a mirror site for redundancy with my shared hosting (at >> Dreamhost), if that would help. Perhaps just a "hot backup" that could be >> enabled if you did lose connectivity or so far a while, rather than working >> up a more complicated High Availability system. I assume a brief outage >> (eg, hour?) of the bug tracker would not be critical to life. > > That's very kind. For the record I have two redundant servers myself that can > be configured to run as backups/mirrors/whatever of the gnucash > infrastructure. > > This is something I'd like to pick up some time later, when gnucash 2.7/.28 > are taking less of my time. Those are top priority now as several distros are > starting to drop gnucash due to the webkit obsolescence.
Linas and I have talked about it as well. The problem, of course, is that it's easy to set up load-balancing redundancy (with two separate systems in separate locations) both serving requests.. But this really only works for static (or quazi-static) content. I'm not sure how we would accomplish that with the Wiki or even GIT, where there's a read-write backend. For something backed by a database you would need to run multiple instances of MySQL with concurrency behind them. I'm not enough of a MySQL guru to set that up. Similarly, I'm not sure how we would replicate the Mailman instances. We could certainly set up a redundant MX record, but SMTP already holds mail for ~5 days so should handle relatively short outages. The other option is to have a "hot spare" running, which is taking updates from the primary but isn't serving any content. But I don't know how to handle an "automated cutover" in the case of a failure. All the solutions I know about are for multiple instances in the same data center. I have no idea how to do it in a globally distributed manner. > Geert -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warl...@mit.edu PGP key available _______________________________________________ gnucash-devel mailing list email@example.com https://lists.gnucash.org/mailman/listinfo/gnucash-devel