Hrm, I seem to have lost the first few repies. 1) you can see an archive of all issues here: http://status.heroku.com/past 2) Sigh, I had a long long response here. Short version - we've got advanced monitoring. The pagers went off before any user knew about the problem. We were working on it within 2 m
On Mon, Mar 15, 2010 at 9:44 AM, Oren Teich <o...@heroku.com> wrote: > at this time. >> [/QUOTE] >> >> However, my app would still not start at Mar 14, 2010 - 4:25 UTC. >> > > That sounds odd for sure. In the future, make sure to submit a ticket if > you're seeing errors. We had no other reports that I'm aware of. It's > possible you got unlucky somehow. > > >> So, what exactly is the definition of "New and idled apps". My >> understanding is that as long as I'm paying for dynos that my app will >> not go idle, but if I increase the dynos from say 4 to 10 are the 6 >> new dynos considered 'new' and won't start in such a situation? What >> about workers? > > >> What about accidentally pushing a 'new' version of code during such an >> outage? I assume this would effectively bring my running app offline. >> > > When issues like this occur, the system automatically identifies it, and > prevents users from hurting things. You can't push, you can't change your > dynos or workers. We make sure your app continues to run while we find and > resolve the issue. > > >> >> 4) If I have a running app that is being concurrently hit by say 100 >> users. What is the exact process the server takes when I push a new >> version of code? In other words, do those 100 users immediately get >> disconnected, or does Heroku spin up the new app, redirecting all new >> requests to the new version once it is online, and then terminate the >> 'old' version dynos after all existing requests to those dynos have >> been satisfied? Basically, what is the user experience for someone >> who is in the middle of submitting their credit card info at the >> precise time that I push a new version of code? >> > > The latter. Open request are served on the old dynos, which are then > replaced with new ones. Users don't see anything. > > >> >> 5) I'm a little concerned about recent posts dealing with getting >> large datasets in and out of the database on Heroku. I've read plenty >> of creative ideas on how to get the data in and out, but nothing that >> would really be considered acceptable for a high traffic site that >> needs virtually zero downtime (especially with the posts saying that >> Taps gets really slow after about 500 MB). Does Heroku have any plans >> of making it easier to get large datasets in and out of the database? >> What about scaling the database? It's easy to spin up app dynos, but >> what about moving from a Fugu database to a Zilla? What kind of >> downtime are we looking at for such a transition? (How about from >> Ronin -> Fugu?) The faqs state: "Switching to/from a dedicated >> database usually takes one business day as our support staff processes >> the requests, and verifies that data migrations completed >> successfully." I assume this is for switching between say Koi and >> Ronin, but is it also true for Ronin->Fugu->Zilla? >> > > There's two issues: one the ingress/outgress of big data. We're working on > improvements and docs for this. > > Two - dedicated DB migrations. We handle this for you, and will coordinate > with you. It takes 1-2 days to do, with a few minutes of down time each > time you switch. That's between any dedicated option. We'll work with you > directly to coordinate. > > >> 6) I assume I would be looking to move away from Heroku long before I >> reached 2TB of data limit on the database (since at that point I would >> be looking for redundant systems that can have read/write traffic >> separated, etc which Heroku doesn't appear to support), but how would >> I get this data off Heroku? >> >> > We haven't had anyone leave due to traffic or size yet. If you start > hitting performance bottlenecks, we'd love to work with you to optimize the > system or make any changes needed. > That said, you can always request a data dump for us if the tools aren't > working for you. > > 7) What systems are used to store the database data? In other words, >> how safe is my data in the event of system failure (hard disk, etc)? >> Single disk, Raid 1, Raid 5, Raid 10, etc? >> > > Very safe. There's a combination of protection at every layer. SW raid > across EBS (which are themselves RAIDed), daily backups of all data, etc. > > >> 8) In the event of system failure, what kind of support can I expect >> from Heroku to get the database back online? (Meaning that a hard >> disk failure with a response of "restore from your backup bundle" >> would not be considered acceptable. Transaction logs would need to be >> replayed, etc.) >> >> > We provide full support for this. We'll take care of it for you. > > >> 9) DNS related: Is it possible to have say 2 set subdomains for a >> given domain (ex: forums.mydomain.com, chat.mydomain.com) that point >> to separate apps, and then have a catchall domain point to a 3rd app? >> Ex: subdomainXYZ.mydomain.com points to a given app for any value of >> XYZ. The docs seem to indicate that I need to use the heroku console >> to add any subdomains, so what I'm looking for is how I would add a >> catchall domain in Heroku. >> >> > Wildcard domain, or add each domain independently, your choice. > > Oren > -- You received this message because you are subscribed to the Google Groups "Heroku" group. To post to this group, send email to her...@googlegroups.com. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/heroku?hl=en.
