使用 mysql 在 Amazon EC2 上设置网站
我有一个由 Joomla 驱动的新网站，其中包含许多依赖于 Mysql 数据库的自定义应用程序。这全部托管在 Amazon EC2 上，根设备是 EBS。
我关心的是我的 Mysql 设置。我已经用几乎默认的设置安装了 mysql-server（安全清理除外）。
我的问题是我是否应该将 Mysql 设置为在单独的 EBS 卷上运行： http://aws.amazon .com/articles/1663 或者我应该查看 Amazon RDS：http://aws.amazon.com/rds/mysql/？
对于我现在只有 0 个用户的初创公司来说，这些似乎都太过分了。我显然想确保我积极主动，以防这种情况确实增长，但我不知道以后添加这些是否会是一个很大的痛苦？
I've got a new website that is Joomla driven and contains many custom apps that depend on the Mysql database. This is all hosted on Amazon EC2 with the root device being EBS.
My concern is with my Mysql setup. I've installed mysql-server with pretty much default settings (other than the security cleanup).
My question is if I should be setting up Mysql to run on a separate EBS volume: http://aws.amazon.com/articles/1663 or should I even be looking at Amazon RDS: http://aws.amazon.com/rds/mysql/?
These both seem overkill for my startup right now with 0 users. I obviously want to make sure I'm proactive in case this does grow but I have no idea if it will be a major pain to add these later?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我肯定会说，出于多种原因，您应该将 MySQL 设置为在另一个 EBS 卷上运行。以下是一些：
更轻松的备份。您可以对整个 EBS 卷进行快照，而不是进行 MySQL 转储并将其推送到 S3。当您拥有卷的快照时，您可以比使用 MySQL 转储更快地恢复数据库。
磁盘争用。当您在同一磁盘上运行所有内容时，您会看到一些磁盘争用。特别是当您尝试进行 MySQL 复制时。我有一份用于 MySQL 日志的卷，一份用于数据，另一份用于其他所有内容。
EBS 卷相对便宜。
如果需要，您可以将整个卷移动到另一个实例。
总的来说，这是一个更好的选择。如果您需要的话，我可以给您更多理由。
我认为您可以在 EBS 卷上度过一段时间，然后决定分片、为 NOSql 重写应用程序、迁移到 Amazon RDS 等。但我的意见是用尽 MySQL，直到没有剩余。
I would definitely say you should setup MySQL to run on another EBS volume for many reasons. Here are a few:
Easier backups. You can snapshot the entire EBS volume rather than doing a MySQL dump and pushing it to S3. When you have a snapshot of the volume, you can restore your database much quicker than with a MySQL dump.
Disk contention. You will see some disk contention when you run everything on the same disk. Especially if you are trying to do MySQL replication. I have one volume for MySQL logs, one for Data, and one for everything else.
EBS volumes are relatively cheap.
You can move the entire volume to another instance if you need to.
Overall it is a much better choice. I could give you more reasons if you need them.
I think you could get by on EBS volumes for a while and then decide to shard, rewrite application for NOSql, move to Amazon RDS, etc. But my opinion is to use up MySQL until there is nothing left.
我在 RDS 可用之前就写过关于 EBS 的 MySQL 文章。
我建议您从 RDS 开始。设置简单，为您解决很多后顾之忧，而且充满乐趣。
仅当您遇到 RDS 的某些限制时才切换到管理您自己的 MySQL（可能性不大）；当您这样做时，请遵循我的文章中的最佳实践并使用单独的 EBS 卷。
I wrote that MySQL on EBS article before RDS was available.
I would recommend you start with RDS. It's simple to set up, takes care of many worries for you, and is fun.
Only switch to managing your own MySQL if you hit some limitation of RDS down the line (not tremendously likely); and when you do, follow best practices in my article and use a separate EBS volume.
如果您不使用 RDS，则应考虑将多个 EBS 卷条带化到软件 RAID 配置中。
如果不这样做，您很可能会发现 EBS IO 性能对于适度繁忙的 MySQL 实例来说太差了。
有关如何执行此操作的详细信息，请查看
http://alestic.com/2009/06 /ec2-ebs-raid
If you do not use RDS, you should consider striping multiple EBS volumes into a software RAID configuration.
If you do not, you may well find that the EBS IO performance is too poor for a modestly busy MySQL instance.
For details on how to do that, check out
http://alestic.com/2009/06/ec2-ebs-raid