1

我想确保我已尽我所能配置系统磁盘以供严重的数据库使用。我知道（任何其他？）需要关注的三个领域是：

  1. I/O 大小：数据库引擎和磁盘的本机大小应该匹配，或者数据库的本机 I/O 大小应该是磁盘本机 I/O 大小的倍数。
  2. 应该为其配置能够进行直接内存访问的磁盘（例如 IDE）。
  3. 当磁盘说它已持久写入数据时，一定是这样！不要将其保存在缓存中并对其撒谎。

我一直在寻找有关如何确保 CENTOS 和 Ubuntu 如此的信息，但似乎根本找不到任何东西！

我希望能够检查这些东西并在需要时进行更改。

任何和所有输入表示赞赏。

请注意：所涉及的实际硬件非常适中。关键是要充分利用我们现有的硬件，即使从更广泛的角度来看它不是“非常严肃的硬件”。

更多的：

我很感激阅读和回复所花费的时间，但我希望得到的“答案”不仅仅是好的数据库/硬件建议，而是真正解决我所询问的具体问题的答案。即：

1) 有什么简单的方法来判断操作系统想要执行的 I/O 单元大小是多少？我怎样才能改变它？（IOW：如果这完全是一个文件系统格式问题，我怎么知道在已经创建的文件系统上使用了什么？我知道 /etc/fstab 会告诉我文件系统格式......在这种情况下，它是分机3。

2) 如何判断磁盘驱动器是否具有 DMA？如果是这样，我该如何打开它？（有人告诉我某些驱动器具有此功能，但现在我想跟进并确保如果这些驱动器具有此功能，则它已打开。）

最后；

3）我如何判断驱动器是否只是告诉作者他们的材料实际上仍在缓存中时已写入？而且，更重要的是，如果/当它们存在时，我如何将系统设置为不使用这些功能？

感谢您的见解。逆转录

4

3 回答 3

1

“严重的数据库使用”和您在同一句话中提到 IDE？

多轴 RAID 1+0 阵列中的 SSD 或 15k SCSI，具有用于数据、日志和备份的单独阵列。也考虑为 tempdb 设置一个单独的数组。

您还可以将控制器缓存切换为 100% 读取以避免缓存问题

当然，如果它是“严重的”，那么你会考虑集群等：所以 SAN 在这里很有用，但你可能不如本地主轴那么快

于 2010-03-31T21:49:59.863 回答
1

1) 检查/sys/block/sdX/queue/{max_hw_sectors_kb,max_sectors_kb}。第一个是硬件允许的最大传输大小，另一个是当前最大值，可以设置为任何值 <= max_hw_sectors_kb

2) hdparm -i /dev/sdX

3) 关闭回写缓存（hdparm 可以做到），或确保文件系统在同步时发出障碍（如 fsync() 或日志提交）。

于 2010-04-01T17:21:40.340 回答
0

您没有包含有关文件系统或数据库的任何信息，因此这里有一些杂项指针。

最终您不可避免地会丢失磁盘，因此制定良好的备份和恢复策略以及镜像您的事务日志同样重要，这样您就可以处理磁盘故障甚至完整的数据文件丢失。

1) 如果可能，将至少一份事务日志副本放在固定磁盘上。不要将您唯一的事务日志放到外部存储子系统中。（假设您使用支持日志镜像的数据库）。

2）我同意gbn，在实践中，不要使用写缓存。我丢失了带有备用电池的 RAID 阵列上的数据库。将存储控制器卡配置为直写。

3）原始设备提供有保证的写入，但不值得麻烦。一些文件系统也提供同步写入选项，如果可能的话使用一个。我偏爱 VxFS，但我来自 Sun 世界。在 Linux 上，btrfs 至少是杰出的，但目前，如果您正确设置数据库，Ext3 可以正常工作。

于 2010-03-31T22:01:59.827 回答