使用 EBS 在 Amazon EC2 上运行 MySQL
我有一台生产服务器，其MYSQL可能没有备份。相关实例有一个 EBS 支持的根设备 (/dev/sda1)，它持久存储文件。我不清楚它是否自然地持久存储我的 MYSQL 数据和二进制日志文件。
如果它安装在根目录下，是否应该这样做？我也这么认为。
我是否应该附加并安装另一个卷，然后将 MYSQL 服务器指向新位置？
我的命令如下所示（加上在创建快照时锁定 MYSQL 表）
sudo mkdir /vol/etc /vol/lib /vol/log
sudo mv /etc/mysql /vol/etc/
sudo mv /var/lib/mysql /vol/lib/
sudo mv /var/log/mysql /vol/log/
sudo mkdir /etc/mysql
sudo mkdir /var/lib/mysql
sudo mkdir /var/log/mysql
echo "/vol/etc/mysql /etc/mysql none bind" | sudo tee -a /etc/fstab
sudo mount /etc/mysql
echo "/vol/lib/mysql /var/lib/mysql none bind" | sudo tee -a /etc/fstab
sudo mount /var/lib/mysql
echo "/vol/log/mysql /var/log/mysql none bind" | sudo tee -a /etc/fstab
sudo mount /var/log/mysql
我不是系统管理专家，我不想搞砸我现有的数据库。这里有什么风险吗？我是否应该在这里使用额外的设备，或者只是坚持使用内置的根设备？
I have a production server whose MYSQL may not be backed up. The instance in question has an EBS backed root device (/dev/sda1), which is persistently storing files. It's not clear to me whether it is naturally storing my MYSQL data and binary log files persistently.
Should it do so if it's mounted at root? I would think so.
Should I instead attach and mount another volume and then point the MYSQL server at the new location?
My commands look like the following (plus locking the MYSQL table while creating the snapshot)
sudo mkdir /vol/etc /vol/lib /vol/log
sudo mv /etc/mysql /vol/etc/
sudo mv /var/lib/mysql /vol/lib/
sudo mv /var/log/mysql /vol/log/
sudo mkdir /etc/mysql
sudo mkdir /var/lib/mysql
sudo mkdir /var/log/mysql
echo "/vol/etc/mysql /etc/mysql none bind" | sudo tee -a /etc/fstab
sudo mount /etc/mysql
echo "/vol/lib/mysql /var/lib/mysql none bind" | sudo tee -a /etc/fstab
sudo mount /var/lib/mysql
echo "/vol/log/mysql /var/log/mysql none bind" | sudo tee -a /etc/fstab
sudo mount /var/log/mysql
I am no sys admin expert and I don't want to screw up my existing database. Is there any risk here? Should I even bother with an additional device here or just stick with the built in root device?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我将 /etc/mysql 和 /var/lib/mysql 目录移至我的 EBS 并在其之前的位置创建了符号链接。
这样我就不必修改配置文件或担心找不到文件。
我还移动了 /etc/mysql 的原因是，如果我将 EBS 连接到另一个实例，配置文件和维护脚本就不会丢失。
至于该数据的备份，最好创建另一个实例并创建主/主配置，这样您还可以获得故障转移的好处。
I moved the /etc/mysql and /var/lib/mysql directories to my EBS and created symlinks in their previous locations.
That way I didn't have to modify configuration files or worry about something not finding the files.
The reason I also moved /etc/mysql was so that the configuration files and maintenance script would not be lost if I attached the EBS to another instance.
As for a backup of that data, it would be best to create another instance and create a master/master configuration so you also get the benefits of failover.
如果您担心数据持久性：
拍摄 /dev/sda1 的快照，创建一个完全独立的实例（t1.micro 非常适合于此），根据您拍摄的 /dev/sda1 的快照创建一个新卷，然后在新的单独实例上安装该新卷吗？如果您的数据存在于新卷上，那么它肯定会存储在 /dev/sda1 上的 EBS 中。
话虽如此：许多默认的 Linux 映像都设置为在实例终止时自动终止根 (/dev/sda1) 卷。意思是：如果您丢失了一个实例，并且没有在其他地方进行备份，那么您也会丢失该卷上的所有数据。保留备份的一个简单方法是仅使用 EC2 设施每天拍摄卷的快照。创建一个脚本非常容易，该脚本拍摄快照并在新快照完成后删除旧的每日定期快照。如果您正在寻找更小的备份大小或增量备份策略，您可以编写更高级的脚本来在备用可用区域或区域中启动 t1.micro，通过您喜欢的任何机制仅对 MySQL 数据执行备份，然后重新关闭 t1.micro 实例。
If you're concerned about data persistence:
Take a snapshot of /dev/sda1, create a completely separate instance (t1.micro works great for this), create a new volume based off the snapshot you took of /dev/sda1, then mount that new volume on the new separate instance? If your data is present on the new volume, it's definitely getting stored in EBS on /dev/sda1.
Having said that: a lot of the default Linux images are set up to automatically terminate the root (/dev/sda1) volume when the instance terminates. Meaning: if you ever lose an instance, you're also losing all your data on the volume if you don't have it backed up elsewhere. An easy way to keep backups is to just use the EC2 facilities to take a snapshot of the volume daily. It's pretty easy to create a script that takes a snapshot and removes old daily periodic snapshots once the new snapshot is complete. If you're looking for smaller backup sizes or incremental backup strategies, you can write more advanced scripts that fire up a t1.micro in an alternate availability zone or region, perform the backup on just the MySQL data via whatever mechanism you like, then shuts the t1.micro instance back down.
如果您停止实例，它将类似于常规关闭，并且 EBS 卷应保留所有数据。
我认为，如果您终止实例，则快照以来的所有数据都将消失。
但通常我认为没有太多理由终止它。无论如何，尝试起来应该很简单
在测试实例上。您可以只编写一些文件，然后看看在不同的用例下会发生什么。
这样你也会感觉比仅仅依赖某人的答案更安全。
If you stop your instance it will be similar to regular shutdown and EBS volume should remain with all data.
If you terminate instance than, I think, all data since snapshot will be gone.
But normally I don't see much reason to terminate it. In any case, it should simple to try out
on a test instance. You could just write some files and see what happens under different use cases.
This way you would also feel much safer than just relying on someone's answer.