你在问这样的问题
如果使用sql*loader在oracle中加载数据时出现网络故障，会发生什么情况？
或者，在传输数据时，sqoop会由于某种情况而停止处理吗？
简单地说，无论在电气故障或系统关闭前传输什么样的数据，都将保持不变。
进入第二个问题，当memtable耗尽空间时，即当密钥数超过某个限制（默认值为128）或当它达到持续时间（群集时钟）时，它将被存储到sstable的不可变空间中。

cassandra的提交日志为cassandra提供了持久的写操作。当您向cassandra写入时，在向客户机确认写入之前，写入会附加到提交日志中。这意味着客户机收到成功响应的每一次写入都保证写入提交日志。写入也会写入当前的memtable，当memtable足够大时，它最终会作为sstable写入磁盘。这可能是一个很长的时间后，写了。
但是，由于性能原因，提交日志不会立即同步到磁盘。默认为周期模式（由cassandra.yaml中的commitlog\u sync参数设置），周期为10秒（由cassandra.yaml中的commitlog\u sync\u period\u in \u ms设置）。这意味着提交日志每10秒同步一次到磁盘。在这种情况下，如果服务器断电，最多可能会损失10秒的写入时间。如果集群中有多个节点，并且使用了大于1的复制因子，则需要在10秒内失去多个节点的电源才能丢失任何数据。
如果此风险窗口不可接受，则可以对提交日志使用批处理模式。在提交日志同步到磁盘之前，此模式不会确认对客户端的写入。时间窗口由commitlog\u sync\u batch\u window\u以毫秒为单位设置，默认值为50毫秒。这将显著增加写入延迟，并可能降低吞吐量，因此仅当丢失一些已确认写入的成本很高时才使用此选项。使用此模式时，将提交日志存储在单独的驱动器上尤其重要。
在服务器断电的情况下，启动时cassandra会重放提交日志以重建其memtable。在写容量非常大的服务器上，此过程需要几秒钟（可能需要几分钟）。
如果要确保memtables中的数据写入磁盘，可以运行“nodetool flush”（该操作针对每个节点）。这将创建一个新的sstable并删除引用memtables中数据的提交日志。