Dell XC系列主机内置Satadom卡固件更新流程
Dell XC系列服务器板载的Satadom卡为放置ESXi等虚拟化操作系统核心的存储所用。部分旧版的固件可能导致在主机重启后Satadom不可访问，从而导致无法进入系统。此时需要考虑升级固件，预防Satadom读写故障。
升级前检查
1. 确认当前Satadom固件版本：在ESXi中执行如下命令：
$ esxcli storage core device list| grep -A4 Path
返回结果如下：
Dell XC系列服务器板载的Satadom卡为放置ESXi等虚拟化操作系统核心的存储所用。部分旧版的固件可能导致在主机重启后Satadom不可访问，从而导致无法进入系统。此时需要考虑升级固件，预防Satadom读写故障。
1. 确认当前Satadom固件版本：在ESXi中执行如下命令：
$ esxcli storage core device list| grep -A4 Path
返回结果如下：
MySQL在5.5版本后引入了更高级的InnoDB表处理引擎，其支持以表为单位创建独立的表空间文件。但是在5.5版本中，该特性默认为未启用；或者低版本升级上来的数据库，表引擎从MyISAM转换为了InnoDB，其表空间依旧为共享类型。
随着表数据量的不断增长，这张共享的表空间大小也会随之变大。有别于独立表空间文件，共享表空间文件并不能通过OPTIMIZE TABLE方式进行释放，所以当物理空间不足时，需要通过一次完整的导出导入操作来降低高水位，释放物理空间。同时，建议一并进行表空间类型切换，方便后续维护管理。
MySQL表空间文件（一般为ibdata1）占用过多的物理空间，但实际表的数据大小已经小于表空间所分配的大小，表空间占用无法得到释放。且经查，数据库的表空间使用类型为“共享”。
MySQL数据库集群因故障发生主从切换后，为了保证数据一致性，需要同步在切换后可能产生的数据差异，并恢复主从关系。
innobackupex（XtraBackup）
该工具在各大Linux公有源中都提供有安装包一键部署。请参考官方说明：
NetApp StorageGRID对象存储集群针对每个租户使用的Bucket，在应用端发起S3请求（GET或PUT）时，可以设置一致性等级。通过配合StorageGRID的多副本机制，来确保数据的安全性及高可用性。针对不同的应用场景及副本保存需求，可以在Bucket上灵活调整这一参数。
要声明对象的一致性等级，需要在发起S3请求时添加x-ntap-sg-consistency标签。
PUT /bucket?x-ntap-sg-consistency=default HTTP/1.1 Date: Wed, 13 Feb 2019 16:39:17 GMT Authorization: AWS 9MOYPG9ACWPAJA1SXXXX:jUGbYkLdBApjCWBgK4TxvOjxxxx= Host: imno.one
HTTP/1.1 200 OK
Date: Wed, 13 Feb 2019 16:44:00 GMT
Connection: CLOSE
Server: StorageGRID/10.3.0
x-amz-request-id: 12345
Content-Length: 127
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8"?>
<Consistency xmlns="http://s3.imno.one/demo/">default</Consistency>1. All提供最高的一致性保证。所有节点都会立即接收数据，否则请求失败
对于一个日常数据变化量较大的分布式存储服务集群（比如NetApp StorageGRID），其Cassandra元数据表SSTable中堆积大量过期数据是在所难免的。一般而言，当SSTable大小到达一定值时，便会自动触发元数据压缩任务，这个压缩操作会将标记为过期的key从SSTable中清理掉，进而释放可用空间。
随着数据量变化幅度的增加，有时会出现元数据压缩任务十分缓慢的情况。元数据压缩无法完成，便会影响所在节点的存储服务性能（因为压缩也会占用一定的I/O及CPU资源）。此时可以尝试通过孤立节点的方式，临时缓解元数据压缩速度。
1. 节点的整体存储服务性能下降