使用https://docs.yugabyte.com/latest/deploy/public-clouds/aws/#manual-deployment中记录的步骤，我们能够使用YugaByte社区版创建6节点，3可用区（AZ）集群。
我们现在要测试将集群从6个节点扩展到9个节点。
a）将每个AZ中的三个模式节点添加到YugaByte DB中的此运行群集的过程是什么？
b）而且，是否应该在节点之间或一次全部添加建议的时间间隔？
c）并且，一旦节点成为集群的一部分，是否需要采取其他任何步骤来触发现有表到新节点的负载平衡？
找不到与上述相关的文档。感谢您的帮助。
答案 0 :(得分：1)
a）以AZ感知方式添加节点
在ulimit设置，数据驱动器准备，YugaByte DB软件安装等方面，新节点的准备应与其他节点类似（如您所发布的链接中所述）。
在集群扩展期间，假设已经有足够的节点运行yb-master进程，则新节点仅需要运行yb-tserver进程。将节点添加到群集时，可以省略与yb-master进程相关的步骤。 [要详细了解yb-master和yb-tserver进程的作用，请参见https://docs.yugabyte.com/latest/architecture/concepts/universe/.]
在为新添加的节点准备yb-tserver配置文件时，请确保适当地设置其放置信息标志（云/区域/区域），该标志会告诉系统及其负载均衡器有关何处的所需信息。每个节点是：
例如，对于第一个新节点，这些标志可能类似于：
--placement_cloud=aws
--placement_region=us-west
--placement_zone=us-west-2a
，对于其他两个节点，--placement_zone可以说成us-west-2b和us-west-2c。
在分布在三个AZ上的最初6个节点上设置yb-tserver时，您会做类似的事情。
启动那些yb-tserver与初始服务器没有什么不同。例如：
~/tserver/bin/yb-tserver --flagfile ~/yb-conf/tserver.conf >& /mnt/d0/yb-tserver.out &
注意：tserver_master_addrs中主地址gflag tserver.conf的值应与现有yb-tservers的值相同。这就是确保这些节点将无缝加入现有集群的原因。
b）可以一次添加/启动所有节点。无需在它们之间有一定等待间隔的时间添加它们。后者实际上可能导致重新平衡/移动数据的次数超出了必要。当系统知道需要一次从6节点状态转变为9节点状态时，只需执行所需的数据移动量，就可以更理想地达到平衡集群的所需最终状态。
c）无需其他步骤即可触发负载平衡！系统以速率受限的方式自动重新平衡数位板（碎片），以使对前台应用程序的影响降至最低。当前，此每个节点的速率限制由gflag remote_boostrap_rate_limit_bytes_per_sec控制，其默认值为100 MB /秒。但是，根据可用的工作负载和带宽，可以将其调整为更激进或保守的设置。请注意，此重新平衡是YugaByte DB中的后台和在线操作，它是通过从相应的数位板领导者复制压缩文件来完成的。因此，它比最终的一致性数据库（如Apache Cassandra或MongoDB）要轻巧得多，后者必须从所有对等节点进行逻辑（未压缩）数据读取。