Win10 x64, 卸载了QtCreator之后重新安装，打开原有项目时出现一堆报错，例如“常量中有换行符”。 可以确定代码本身没问题。 网上查询一番之后找到了答案，原来是源码文件编码的问题。 解决方法： 对于提示报错的文件，用文本编辑器（例如notepad++)打开，编码修改成 UTF-8-BOM，然后保存。 再次运行，问题解决。 ...
检查，如果发现混用则拒绝提交 建议使用最严格的 true 选项。 然而，我在代码中，却将换行符设置为了Linux换行符，
只要将文件改成CRLF，然后再提交。就没问题了...今天本地新建了一个项目，然后通过idea share到GitHub，发现一只share失败。报错
信息如下： 原因是，我安装git的时候，将git的换行检查功能设置为true。 Git提供了一
在Windows环境下编写的config文件，换行符为\n\r，而Linux环境下换行符为\n，故而执行./configure添加模块时会不正常 添加location配置至nginx配置文件中时，报段错误
模块实现文件中内存出现错误，修改后正常
near unexpected token '{ 解决： 查看文件的第六行的内容，并没有发现有什么异常！！！ 文件
格式错误导致，原文件格式为windows格式，其换行符为：cr lf 转换为unix文件格式后，其换行符为：lf 再次执行上面的语句后，成功执行。
昨天上午，中国银监会下发的关于“数据库文件损坏风险提示”的文件图片在朋友圈和大部分IT微信群里刷屏了。这是继2014年7月1日宁夏银行核心系统数据库出现故障，导致该行（含异地分支机构）存取款、转账支付、借记卡、网上银行、ATM和POS业务全部中断之后，又一家城市商业银行爆出的灾备故障，数据库容灾问题一时被推到了风口浪尖。
根据《中国银监会办公厅关于数据库文件损坏风险提示的通知》中描述：2015年5月8日，某城市商业银行核心系统使用的甲骨文数据库系统发生故障，数据库自动存储管理（ASM）头文件异常损坏，由于该行配置数据备份缺失，在此情况下，数据库无法加载存储磁盘组，数据服务中断。此外，该行同城灾备中心采用了存储级同步复制技术，数据库损坏文件被复制到灾备系统，导致灾备系统的数据库也存在同样问题，无法正常启用，造成该行柜面和渠道业务较长时间的中断。
Mirror存储级数据复制技术。
王晓征（浙江移动信息技术部副总经理）：一、现在黑O记是一种时髦；二、任何数据库容灾技术都有优缺点，底层复制对此次逻辑损坏确实无能为力，但这个方式也绝非一无是处。与时俱进，找到适合自己的方式就是王道；三、从人性角度，没出事的时候技术部门要花钱搞灾备总是很容易被卡，然后出了事之后估计又往往只有技术部门出来顶包，这也是普遍规律，醉一下。
吴东昕（15年IT系统资深架构师）：嘿嘿，非要用存储复制，非要体验这种会故障传递的风险，放着DG或者别的数据库类似的方案例如HADR不用，这下歇菜了吧。再提醒一下那些搞所谓双活extend RAC或者GDPC的，小心双死。
老李：实际案例，存储复制关键时候切换不了。以下是Oracle科技部信息规划的博士做的总结：
|
|
Exadata（数据类应用，如CRM、绩效、报表、反洗钱、征信等）
|
|
传统Oracle IOE架构（包括信贷、财务、二代支付等）
|
|
DB2（包括网银、中间业务系统）
|
|
|
通过SAN进行存储之间的数据拷贝
|
|
利用虚拟技术提供存储数据的服务（镜像/快照/迁移/NAS/远程复制/写入保护）
|
|
通过卷管理器的快照功能实现数据同步
|
|
基于数据库日志的物理复制
|
通过把数据库的日志传送到远程数据库，借助数据库的恢复机制将数据恢复出来。如：Oracle的Active Data Guard的日志传送功能
|
|
通过第三方数据库复制应用软件来实现。如：Oracle的GoldenGate等
|
老耿的工具箱:peony,gdul,osync.：硬件灾备可能无法应对逻辑损坏的状况，但有人说有些存储级也可以回复到某个时间点，不知道真的假的。【babyblue：存储级可以通过快照来实现。】我也是听说的，如果是可以闪回到任何时间点，那也是可用的。
洪烨：hadr基于日志传输复制，目前可以做到三备库，免费。花钱的话可以考虑cdc。【杨建荣_北京：我知道很多海外的电信都是使用bcv的这种方式，不过自从有了11g的adg以后，还是比较方便，很多都在大规模采用。】【Marvelyu：银联的容灾是什么技术架构组建？灾备没用HADR吧？是存储级别复制吗？】存储+应用，银联的业务类型很简单，全都是交易流水，不涉及账务，银联数据SharePlex。灾备没用HADR，是存储级别复制。
Lei：客户准备实施cdp（连续数据保护），我准备下狠手给否定了。大体是这样的，rac中用两个存储，主存储和cdp的旁路镜像存储，asm
diskgroup使用normal冗余。主存储上的lun构成一个fg，cdp的旁路镜像存储构成一个fg。【乘风破浪：cdp的稳定性很让人担心。】【lastwinner：现在用cdp的基本都是大白鼠。】
清泉石：以前更多考虑的是在线实时备份，主要应对操作性故障、硬件故障，很少考虑这种故障。只能寄希望于完整备份和不完整恢复了。
谁动了我的琴弦：应该定期做备份恢复测试。
Lunar：换adg就屏蔽db下面一层的灾备问题，再结合flashback，有条件做个实时，再做个延迟，基本各类物理损坏都扛过去了。至少上面那个存储复制如果换成Oracle的ADG，解决上面说的存储复制没问题。我说的是更全面的设计，容灾的RPO、RTO要结合预算和需求。【Joseph：ADG不如本地CDP，我见过两家客户做的dg都不稳定，偶尔会发生问题，需要全库重新同步。ADG好处是只要同步过去的必然事物一致。】【babyblue：嗯，ADG切换过程中我们这没少出过lost
write的问题。】【清泉石：我的理解是CDP与数据库无关，它是基于操作系统的文件行备份，并不关心文件的内容和属性。】这个adg哪里不行啊？adg需要啥维护？CDP依赖于db，然后还能超越db本身的功能？adg是物理的，跟事物完全没关系。【Joseph：CDP怎么会依赖于db呢，他是底层块级别的。】要启动，需要check
apply。【Joseph：精确到微秒…可以指定没有io的时间点。】【清泉石：主要问题是在于如果被攻击，可能会渗透进数据库内部破坏数据文件或者控制文件。这样的话，任何实时同步都没用。】【Joseph：redo不算事物？log记录的在我看来都算。】当然不是，都是block直接apply。在玩Oracle的人看都知道redo
apply，只不过adg是数据库自己的block，大家不一个层次。【Joseph：block的apply就不算事务了……对于Oracle来说依然是他内部的事务。当然lunar说的ADG也有很大好处，比如有些平台和应用场景CDP做不了，ADG就可以应对几乎所有的场景。价值方面来说，不好判断，你说故障了，然后备份就立功了，你之前花的多少个十万八万的，根本就没差别。没事的时候，都是放在那，连花瓶都不如。】
情系天下：存储级别复制不知道备库能不能打开，这是个未知数。
陈渊：不同容灾软件或方法，都只能处理部分问题，不可能解决所有问题。
杨志洪：银行其实搞容灾搞得非常早，基本上到目前为止，主要搞的还是存储级容灾。上面其实有朋友说了，存储级Oracle数据库的灾备，有一个很大的风险点，就是灾备端数据库是offline的，真要起来的时候，很可能打不开。另外就是银监会通报的这种情况，源端的物理错误，目标端无法判断，只会照样的复制。【扣扣：所以很少有看到真实的切换救灾的，绝大多数，只要供电在、设备在、人在，都是在本地完成修复和救灾。】这中间有很多因素，不单纯是技术问题。【情系天下：灾备端的数据完整性不好验证。】【扣扣：所以存储产品都希望用快照来解决问题。可是，要保证快照的可用性，就必须让存储与应用能够通信，也就是说，要拍照前，存储会通过安装在主机上的通信agent，通知数据库，转为热备或其他暂停IO的动作。这个动作最大缺点就是对数据库的影响，不可能频繁去做。对未知且无保障的事情，没人愿意冒风险去做，所以存储复制的问题就是扩大性和传染性。如果只是一台数据库出了问题，是只切换一台？还是全部切过去？切换就意味着要上报领导主管层级，一般技术部门是无权做决策的。】【番薯藤：我的感觉，要做灾备就必须做到存储和逻辑复制两种方式才有可靠性。】【扣扣：正解！灾备方案难就难在全面性，因为永远无法预知未来可能发生的灾难类型，所以不能有死角。】【樊双贵：至于怎么实现，可以细化，同时也建议灾备系统上部分生产任务或只读任务。】在电信运营商，用DG/ADG方式来做容灾和应急的已经比较多了。一方面当然要做好切换演练；另一方面，备库可以分担一部分报表业务压力。
灾备，由于是一种保险性质的东西，因此常常不被企业所重视。许多企业的领导都会认为，天知道灾难什么时候会掉下来呢？这几千万甚至上亿的灾备成本何苦要去花？
尽管有些领导懂得灾备的重要性，或者是由于行业的硬性要求而做了灾备，但到底有没有效果往往是没有持续验证的。对于系统越复杂的企业来说，做灾备演练的难度也就越大。
有的企业就算做了验证，但是验证的角度不够广，只是采用固定的套路。因此灾备演练发现不了死角，没有起到应有的效果。
综上种种，都造成了灾备系统变成摆设的局面。
灾备系统建设到底应该怎么建？针对此问题，DBA+社群将会进行后续解析和分享，敬请持续关注我们的微信公众号：dbaplus。
在“DBA+社群”热议话题讨论活动中，得到了以下联合发起人以及群友们的积极参与和支持。在此，小编整理成文，并附上所有发表观点的人员头像汇总图（排名不分先后），特此鸣谢！
“DBA+社群”根据业内热点话题及DBA所遇疑难杂症，即时在各大城市群进行【热议话题】讨论，欢迎大家积极加入我们，各抒己见。想了解我们的小伙伴们可关注微信公众号：dbaplus。
来自各领域的牛逼DBA正在向我们汇聚
