首先，由于安全原因和其他原因，我无法使用 S3 或其他类似的解决方案。
我有一台存储服务器，里面有 1TB 的硬盘。我有一个 Mysql 服务器在里面运行。我们的计算机每小时大约会将 1GB 的数据添加到数据库中。所以大约一个月后我的存储空间就会用完。
我希望能够添加新硬盘并将其他系统连接到网络并链接存储。例如：如果我链接一个以上的 1TB 系统，我希望 MySQL db 的可用存储空间为 2TB。即：分布在两个系统上。
负载平衡选项也很好。即两个系统上的 MySQL 服务器都应该能够访问数据库。
我怎样才能实现这一点（最好使用开源解决方案）。
答案1
每次接近满时，启动一个新的 MySQL 服务器。重写客户端软件，根据所需信息的日期访问正确的 MySQL 服务器。
当然，您需要有可以按日期戳分区的数据。需要跨服务器的查询必须查询每个服务器并合并结果。连接会很困难。但是，考虑到您想要无限的存储，您必须在其他方面做出妥协。您不能拥有无限的存储空间而仍然使用 MySQL。
这对于存储日志或其他累积但不改变的存档数据的任何数据库都非常有用。此类数据也易于按日期戳进行分区。
这是 Twitter 最初使用的方案。他们有一个 MySQL 服务器来存档旧推文；当它满了时，他们就启动一个新服务器。搜索“用户 X 曾经发过的所有推文”会将查询发送到每台服务器，从最新的服务器开始，到创建帐户时存储存档的服务器结束。所有旧服务器都设置了只读副本；因为需要许多副本才能满足它们必须处理的查询量。因此，系统可以双向扩展：向上扩展（移动到下一个服务器以获得更多空间）和向外扩展（添加更多副本以增加负载）。
然而，你最终会发现，关系数据库对于存储日志或其他累积但不会改变的存档数据来说是一个糟糕的选择。一次插入多行涉及锁定，这会减慢进程，如果你能保证所有数据都是“一次写入”，那么这会很浪费。
Twitter 最终转向了其他存储技术，您会发现自己也想这样做。您将希望选择一个通过添加更多机器而无限增长的系统。然后，系统会跟踪哪些机器保存哪些数据，即使您将查询发送到主节点，它也会做正确的事情来找到结果。这样的系统包括：MongoDB、Hbase、CouchDB，我认为还有 Riak。
如果您的数据无法轻松分区，那么这个答案对您没有帮助。在这种情况下，您需要考虑向现有系统添加越来越多的存储空间。向 SAN 添加大量磁盘并将其连接到机器是一种解决方案。
答案2
我要在这里打个比方，并假设您对将存储连接到几台不同的物理机器上进行组合并不真正感兴趣，正如您的问题所指出的那样，而只是希望能够随着存储需求的增长在单个主机上扩展存储解决方案。
如果是这样，我建议你仔细看看虚拟文件系统。它的设计具体来说能够处理这样的情况（以及其他情况），并且它是一个通用文件系统。
有Linux 实现不幸的是在某些使用场景下仍会出现问题或者，如果您更喜欢坚如磐石的稳定性，您可以将文件托管在 FreeBSD 主机上并通过 NFS 或 SMB 共享它们，或者甚至只是在 FreeBSD 系统上运行数据库。我没有看到您指定操作系统，但您提到 MySQL 并更喜欢开源解决方案确实指向 *nix。主要的警告是您确实希望使用 64 位并拥有大量 RAM 才能真正满足 ZFS 的需求，但这在今天不应该像历史上那样令人担忧。
在 ZFS 上，您可以使用所谓的 zpools，它基本上有点像您可能认为的文件系统。每个 zpool 由一个或多个 vdev 组成，而每个 vdev 又由一个或多个物理（或逻辑）设备组成。在整个 zpool 上，您可以创建 ZFS 术语中所谓的文件系统（可单独安装的层次结构）。通过向新的或现有的 vdev 添加额外的物理设备，文件系统会自动提供并使用获得的额外存储容量（如果有；例如，如果您向 vdev 添加镜像设备，虽然您获得了冗余，但不会获得额外的存储空间）。添加设备是一个完全透明的在线操作；因此，如果存储设备本身是热插拔的，则可以构建一个在容量升级期间没有停机时间的存储解决方案。
答案3
您可以考虑使用 LVM 作为文件系统，但这意味着修改文件系统，这可能很关键。这里有很好的解释： https://wiki.ubuntu.com/Lvm
答案4
如果您每小时真的有数 GB 的数据在不停的、永无止境的洪流中流动，那么设计选择将非常有限。您可以考虑将所有新数据排队到一台机器上，然后将其输入到 MySQL 数据库。这样，您就可以关闭 MySQL 数据库进行维护：添加磁盘、连接到新的 SAN 等等。
队列机器将为您提供尽可能多的维护时间，因为它可以保存数据，但请记住，当它重新连接到 MySQL 服务器时，它将需要赶上进度。例如，您可能会发现，如果队列机器用于存储 4 小时的积压数据，则可能需要 8 小时才能将该积压数据清空到 MySQL 服务器；它现在执行的 INSERT 次数是原来的两倍。
提示：如果您构建了这样的排队机，您会发现设置一个监控仪表板很有帮助，该仪表板记录了批次在被推送到 MySQL 服务器之前等待的时间。等待时间的统计数据将帮助您管理系统。例如，如果您绘制 7 天的尾随数据图，则 90 百分位值将是整体健康状况的良好指标。当该值很高时，请发出警报。有些地方不对劲。您可以绘制每周数据的 90 百分位图；这将让您了解随着时间的推移您的表现是变好还是变坏。