Exchange邮箱数据库事务日志引起磁盘暴涨

简介:

最近在做公司邮件系统的数据迁移(zimbra to exchange),原zimbra700多G的数据文件迁移到exchange2010中(IMAPSYNC迁移数据到exchange)。考虑到增长因素,exchange中预留了2T的空间用于数据存储。

Imapsync 详见:http://imapsync.lamiral.info/

本次数据迁移预计10天完成(账户5000多及其他原因,很耗时,哈哈哈。。。),过程基本正常,当进行到第五天时,查看进度,账户完成3000多,数据同步600G左右。zimbra服务器正常运行,邮件收发正常。Exchange服务器正常,同步完的账户邮件数量及内容一致。最后查看exchange数据库占用磁盘容量,竟然多达1.4xTB。继续下去,exchange会因数据库磁盘写满而无法正常运行。

为什么同步后邮件会增长这么多呢?

首先想到的问题是linux系统和windows系统的数据块大小不一致照成的,查看windows分配单元和linux block size的大小,都是4096字节,所以排除这个原因。既然和系统及分区无关,其他可能的原因就是数据库本身了。打开一个exchange邮箱数据库,能看到edb后缀的数据库文件及log后缀的日志文件。查看数据大小,log文件的总容量和edb文件几乎相同(log稍微大一些)。同步过程中exchange生成了相当于数据大小的日志文件。相当于在exchange中存有两份数据。查询微软知识库:Exchange邮箱数据库的事务日志文件将记录数据库引擎执行的每个事务。所有事务将先写入日志,然后再慢慢写入数据库。“每天生成的事务日志数”的值取决于选择的邮件配置文件和平均邮件大小。它表示每天每个邮箱将生成的事务日志数。每个邮件配置文件的日志生成数需考虑以下因素:

邮件大小的影响

发送/接收的数据量

数据库运行状况维护操作

记录管理操作

不是邮件但存储在邮箱中的数据(任务、本地日历约会、联系人)

强制的日志滚动(定期关闭当前事务日志文件的机制)

详细参考:http://technet.microsoft.com/zh-CN/library/ee832796

同时IMAPSYNC的工作原理相当于以imap的方式在exchange服务器上接收一份邮件数据。同步的邮件数量和邮件大小是正常工作的几百甚至上千倍,因此同一时刻会产生相当于数据大小的事务日志文件,进而磁盘容量暴涨。还好发现及时,问出现故障。

最后就是想办法清除多于日志文件,解决方法有两种,一种是启用Exchange2010循环日志,另一种是使用Windows Server backup执行一次“VSS完整备份”,这种方式会清空日志(推荐方法)。

注:清除日志后在mailbox出现问题的时候 无法进行排错。

生产环境中遇到日志占满磁盘空间,推荐采用备份的方式清除日志。考虑到我们这阶段只是同步邮箱数据产生的日志而非exchange运行中的发送接收产生,不会对mailbox有太大影响。因此采用启用日志循环功能,清除日志完成数据同步后再关闭日志循环个功能。

方法:

1. 启动 Exchange 管理控制台EMC。

2. 在EMC控制台中,展开“服务器配置”,然后单击“邮箱”。

3. 在工作窗格中,右键单击要启用或禁用循环日志记录的邮箱数据库,再单击“属性”。将出现“属性“对话框。

4. 选中“启用循环日志记录”复选框。

clip_image001

5. 单击“确定”。

6. 若要使对循环日志记录设置的更改生效,请重新启动 Microsoft Exchange 信息存储服务,或卸除后再重新装入存储组中的所有数据库。

clip_image002 clip_image003

7 对于多个邮箱数据库,可使用exchange powershell 命令开启日志循环,格式如下:

Set-MailboxDatabase -CircularLoggingEnabled $true -Identity 'CEOMSBGS'

多条写入ps1脚本运行即可。

8 当需求不能重启服务及卸载数据库时,可通过更改数据库维护时间时循环日志生效

clip_image004

对于多个数据库,同样适用于脚本,格式如下:

Set-MailboxDatabase -MaintenanceSchedule '日.14:00-日.15:00, 一.14:00-一.15:00, 二.14:00-二.15:00, 三.14:00-三.15:00, 四.14:00-四.15:00, 五.14:00-五.15:00, 六.14:00-六.15:00' -Identity 'CEOMSBGS'

所有执行完成后,查看磁盘容量,数据量大概是zimbra数据量的120%,属于正常范围。最后同步完成后再将日志循环功能关闭。

最后,问题解决,逃过被老板骂存储容量未规划好,呵呵呵。。。




本文转自liang_simon51CTO博客,原文链接:http://blog.51cto.com/shubao    ,如需转载请自行联系原作者

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
2月前
|
SQL Java 关系型数据库
数据库事务
数据库事务
14 0
|
7天前
|
文字识别 运维 Oracle
asm 磁盘故障处理日志
asm 磁盘故障处理日志
14 2
|
22天前
|
关系型数据库 MySQL 数据库
MySQL员工打卡日志表——数据库练习
MySQL员工打卡日志表——数据库练习
83 0
|
25天前
|
存储 监控 关系型数据库
MySQL Redo Log解密:事务故事的幕后英雄
MySQL Redo Log解密:事务故事的幕后英雄
18 0
|
25天前
|
监控 安全 数据库
Binlog vs. Redo Log:数据库日志的较劲【高级】
Binlog vs. Redo Log:数据库日志的较劲【高级】
70 0
|
25天前
|
存储 缓存 关系型数据库
Binlog vs. Redo Log:数据库日志的较劲【基础】
Binlog vs. Redo Log:数据库日志的较劲【基础】
52 0
|
25天前
|
SQL 监控 关系型数据库
数据库日志解析:深入了解MySQL中的各类日志
数据库日志解析:深入了解MySQL中的各类日志
51 0
|
28天前
|
存储 关系型数据库 MySQL
MySQL 数据库系列(五)-----索引、事务与存储引擎(Linux版)
MySQL 数据库系列(五)-----索引、事务与存储引擎(Linux版)
26 0
|
2月前
|
存储 JSON 运维
【运维】Powershell 服务器系统管理信息总结(进程、线程、磁盘、内存、网络、CPU、持续运行时间、系统账户、日志事件)
【运维】Powershell 服务器系统管理信息总结(进程、线程、磁盘、内存、网络、CPU、持续运行时间、系统账户、日志事件)
26 0
|
2月前
|
SQL 关系型数据库 MySQL
Mysql高可用,索引,事务与调优:提高数据库性能的关键技术
在当今互联网时代,高可用性、稳定性和性能是数据库的三大关键要素。本文将深入探讨Mysql高可用、索引、事务和调优等方面的技术,为读者提供实用的解决方案和经验。
14 0

相关产品

  • 云迁移中心