7 ms·
1) The data is not persistent -- meaning, if your server dies, you loose your database with it. Rebooting the server gives you a clean slate. This theoreticall
by igrigorik 20y ago
1) The data is not persistent -- meaning, if your server dies, you loose your database with it. Rebooting the server gives you a clean slate.
This theoretically can be addressed with a complex backup/redundancy model, but frankly, it's not worth the trouble. Alternatively, you can use a distributed filesystem based on S3, but the performance will be poor. Long story short, your database is your bread and butter, and EC2 simply can't provide the basic services required to run a DB efficiently.
2) Dynamic DNS. Extra headaches, simply not worth it.
EC2 was not designed for persistent data storage, it's a compute cloud.
- gojomo 20y agoRe: "rebooting the server gives you a clean state" That's not quite true: the HD contents survive crashes and reboots. Only if you release the node (or lose it otherwise -- it's not guaranteed to stay with you), the HD contents are lost. I suspect lots of startups are finding it "stable enough", and the backup/redundancy planning needed manageable.
- igrigorik 20y agoAre you certain? This must be new, because before your would get a fresh machine every time. Anytime you boot, AMZ looks at the image you want to run, and they unpack and uninstall it for you, meaning that even a reboot led to a clean drive. Now, there's been some talk about 'shadow copies' where you might even get access to other customers data by simply starting a deep scan on the drive.. but that's hardly persistence.
- gojomo 19y agoYes. Of course, you lose the HD contents if you release the instance, or for other occasional failure and system events.