场景:数据量50T左右,应用服务器10台左右。
现有备份方式:
上午11点左右先停应用,确认无未知进程连接后进行停机备份(一般需到下午14点后开始)。停应用正常情况下需1-1.5小时,实际备份耗时16小时左右(第二天早上才可完成备份)。
优点:能比较清楚地知道哪些应用会对数据库有影响
缺点:若出现应用升级或者平台版本发布等情况,必须提前预演,否则在实际备份过程中,可能遇到杀不干净的未知进程,耗时久,不可控。
由于业务需要,要求缩短备份总耗时,目标是当天24点前完成备份并启应用。
考虑更改备份方式。
改端口备份:
1.无需等应用停完,上午11点左右直接将数据库端口改掉开始备份;
2.应用同步按正常操作停
优点:避免提前预演,避免存在未知进程的时候过度耗时,缩短整体备份耗时。
缺点:据反馈(实际备份操作不归我们管),改端口方式备份前与备份后均需对数据库做重启,重启一次需1-1.5小时。
问题:
1.50T左右数据,数据库重启耗时一般多久?
2.两种方式还有什么优缺点?
3.这类场景,有什么更好的建议?
各位大牛,请答疑解惑,谢谢!
1.数据库正常shutdown,重启跟你的数据大小没有关系
2.在讨论你这两种备份方式前,首先要说明下你的备份方式:1)物理备份? 2)逻辑备份(备份数据)?
3.大容量的数据库,需要定义详细的数据周期,对每个存储周期的数据单独备份。比如:有些历史数据有可能永远都不会被更新,那是不是可以一年备份一次就够了,有些数据一月更新一次,是不是每月备份一次就够了,等等。大容量数据库不能仅仅只考虑备份方式,数据的存储规划更加重要,可以大大降低数据库的风险。
收起