mysql> alter system set datafile_size=‘200G’;
Query OK, 0 rows affected (0.01 sec)
mysql> alter system set datafile_size=‘100G’;
Query OK, 0 rows affected (0.01 sec)
先将datafile_size设置为200GB，然后再设置为100GB，再查看block_file文件还是不变呢
使用类似的方法调整了log_disk_size参数，clog目录大小会随着调整而变化的
不会缩小
为何不向log_disk_size那样可以动态调整磁盘上的大小呢？是有什么考虑吗？
log_disk_size这个是在磁盘上预占用的 ，你调整也不是调整磁盘文件实际占用的大小 也是在预占用下调整的大小 这个都和linux文件系统有关系 例如mysql、oracle也是这样的，原理都是差不多的
datafile_size不也是预占的吗？
OB 数据文件叫 blockfile ，初始大小由参数 datafile_size 或 datafile_disk_percentage（不推荐用比例）指定，4.x 后新增自动扩展功能，每次扩展 大小 datafile_nextsize，最大大小 datafile_maxsize 。
OB 的原理是 LMS Tree，每次转储或合并都是生成新版本的 sstable，sstable 就从 blockfile中分配，并且每次都是分配新的可用空间。对 blockfile的使用是循环利用。当合并之后老的版本对应的 sstable 不需要的时候，其空间就是可以覆盖的，再下次循环利用的时候会被覆写。
OB 为啥不做数据文件的收缩呢？如果想做也行，因为OB对 数据文件的管理单位是宏块（2MB大小）， 哪些宏块空间可以回收是可以做的，只是 OB 不想做这个。如果要做，也只会在合并的时候收缩文件才最合适。但是一旦有这个功能，如果用户收缩后的大小不能容纳当前的sstable，这个就容易带来问题。 OB 对资源的使用思想本来是先占用主机资源，然后OB内部分配管理。所以 空间收缩并不符合 OB 的设计。传统ORACLE数据库表空间虽然可以收缩，但也是非常大的动作，会影响业务读写性能。也要考虑剩余空间是否足够。如果收缩后又要扩容，那收缩的意义就更没有了。
用户之所以会想要收缩，一般是一开始空间搞得太大了。OB刚开始初始化的时候如果用户没有指定 datafile_size 那就默认用了 datafile_disk_percentage 那个参数(默认值在 4.x之前是90， 4.x后稍微动态决定，可能是60也可能是90）。当用户给的磁盘文件系统非常大的时候（比如说10T），OB 这一初始化可能就搞出一个 9T 的文件。传统的监控一下子就报警了。
这属于交付的时候参数没有控制好。也有时候是交付人员想简单了事，永远不扩容数据文件。
精细化的运维建议是初始大小能容纳1年左右的数据容量的3倍大小，同时设置一个更大的最大大小，在内部空间不足的时候允许 OB 自动扩容数据文件。只扩容不缩容。
如果当初失误设置的很大严重超出了业务的数据量大小非要缩容不可能，办法也是有的。在三节点OB集群里，挨个节点删除数据文件，重新初始化这个节点observer进程（指定 datafile_size 为缩容后期望的合理值），ob会自动补齐数据，补完后操作下一个节点。一轮下来，所有节点的数据文件就缩容了。
都是预占用 参数调整是逻辑上调整 调整的是你能用预占用的物理文件大小是多少 但是预占用的物理文件大小不变的
log_disk_size是预占的，但调小log_disk_size后，clog目录也是会缩小的。而调整datafile_size ，blockfile是不会缩小的
已在用的ob集群这样操作不合适吧，我觉得可以扩容observer节点，替换掉之前的observer节点
我找了相关的同学 确认了log_disk_size是预占的，调小log_disk_size后，clog也是会缩小的，调整datafile_size ，blockfile是不会的
OCP 里替换主机的时候，看有没有机会指定 新机器的 observer 进程参数 datafile_size 。如果可以就行。
从4.x 后 clog 的也采用了预分配空间的设计了。 log_disk_size 决定了集群整体的 clog 空间最大可分配大小。
OB 集群维护了一个 日志池子给各个租户用，租户创建的时候指定 log_disk_size 申请一定大小的空间，前提是集群的日志池子里还有剩余空间。
OB 租户在自己的 日志空间池里再循环使用，写clog 日志。clog 是否可以删除有一些条件限制，当clog 不再被需要的时候，clog就可以回收。当 租户日志空间里已经无法分配出新的空间时，就是 clog 空间用尽了。
集群的 log_disk_size 是可以缩小，但是不能收缩到比当前所有租户（包括sys租户）已经申请的 log_disk_size 之和还小。
此外，关于 clog 什么时候被需要或者不被需要，官网文档还没有详尽的描述。所以 clog的空间不要太省。否则，可能影响租户事务的写性能。 官网建议大小是 租户内存的 3-4倍。
嗯嗯 非常感谢大神的解读
替换貌似不行的， datafile_size参数设置了也没用
不知道这种方式有没有人使用过，我现在有个环境POC的时候数据量比较大，使用率98%了。。
现在把数据都删了，想缩小点。
我之前貌似在哪个文档上也看到过，这个操作是不是得手动启动observer进程，并且指定datafile_size参数
是的。操作并不复杂。相当于处理节点数据文件损坏的流程，节点重建。
需要删干净 数据文件、clog 文件、run/ 下文件 log/ 下文件。可以保留 etc/observer.config.bin 。保留了参数后启动时就只需要指定 -o datafile_size=xxxx；如果没有保留参数文件就指定必要的几个参数。具体要看手动部署 observer 时的参数。
