http://www.dbaleet.org/cach_write_policy_write-through_and_write-back
write-through和write-back这个概念在存储工程师眼里绝对不会陌生，而对于数据库管理员来说并却并不一定十分清楚。我说看到的数据库管理员与存储工程师的接口无非就是这些：
1. 我需要一个scalable vg，大小是100g。
2. 我需要使用三个1T的裸盘用来做asm。
3. 我需要一个IOPS为12000的阵列，底层做成raid 10， 条带大小为1M
没有人愿意去了解关于磁盘cache是怎么工作的，因为那不是我工作的范畴。
俗话说： “不想当厨师的裁缝不是个好司机“， 如果预备做Exadata的管理员，或许您应该先了解了解cache的写模式。Take it easy, it is not rocket science.
在进入正题之前，先来问问wikipedia怎么看： Writing Policies 。 wiki大神已经解释得非常清楚了，看来没有写下去的必要了。这篇文章就到这吧，再见。No， to make it more clear， I would like to interpret it in an Exadata way, that is the point. 俗话说：“No pictures, No trues”, let’ s get started.
Write-Through 模式：
1. DB向Cell发送一个写请求， cellsrv进行验证确认其请求有效;
2. cellsrv将发送指令将其写入到物理磁盘;
3. 写完成以后，给DB确认已经写成功;
4. cellsrv判断次数据是否适合缓存到cache中，如果满足条件则缓存，否则不缓存。
Write-Back 模式：
1. DB向Cell发送一个写请求， cellsrv进行验证确认其请求有效;
2. cellsrv将发送指令将其写入到磁盘Cache;
3. 将此数据的状态置为dirty的状态。（直到下次临界条件将脏数据刷新到磁盘，并判断此数据是否适合缓存，如果不适合，刷新完成以后会丢弃，刷新和缓存过程是异步的，并不在步骤3来完成）
4. 写完成以后，给DB确认已经写成功;
Write-Back 模式明显更高效，因为写数据到cache的速度比写到物理磁盘速度要快几个数量级。但是cache属于挥发性设备，无法持久的保存数据，所以需要磁盘控制器/Flash卡有独立的电源模块作为驱动将cache中的数据写回到磁盘。如果没有电源模块，则原本保存在cache中的数据并无法保障总能成功写入到磁盘，如果这个时候主机发生掉电，则可能造成数据不一致。为了保证数据的一致性，如果磁盘控制器或者flash卡的电量不足，则会自动从write-back模式转到write through 模式， 进而对系统的I/O造成影响。在exadata中可以使用exachk工具来检查，以下是Exachk中磁盘raid控制器电池不足导致自动切换到write-through的告警。
实际上可以在BIOS中强行修改磁盘控制器的wirte-back或者write-through模式，但是为了保证数据的一致性，我们并不建议这么做。如果出现了以上问题，正确的做法应该是开一个sr，上传对应的exachk报告要求更换电池。
Comment