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报告要求更换电池。