服务器在客户厂里, 客户没有机房, 就放在厂子机器旁边.
每天下班后, 客户员工从来不会去关闭电脑, 都是直接拉闸整厂断电.
系统稳定运行了大半年后, 从最近开始, 每隔几个月, mysql 就报 redo 日志异常无法启动, 需手动删除日志后才能启动, 这有点恶心了.
有没有在同样场景下, 试过 oracle, sqlserver, postgresql, sqlite 这些的同学, 这些数据库存不存在这个问题?
101
Karte 32 天前
除非硬件损坏. 这时候你可以将整个系统备份到 U 盘, 在硬件损坏的情况下也能立即恢复生产.
影子系统也支持保留部分盘符的文件修改, 下次开机时文件依旧存在. |
102
sl0000 32 天前
既然日志可以随便删, 那说明数据不是那么敏感(重要)
低成本解决方案, 定时在下班点或拉闸前一分钟自动关机. |
103
reeco 32 天前 2
服务装在笔记本上不就完事了吗
|
104
luziafy 32 天前
在电闸旁边装一个关机键
|
105
git00ll 32 天前
能联网吗、数据量大吗。开机检测不通过则自动从远程数据重建。
|
106
nuk 32 天前 1
每次开机先把 redo 给删了,反正数据都不重要
|
107
JingW 32 天前
给客户一套纸笔,保证不受断电影响
|
108
thtznet 32 天前 1
说句实话:“员工多是五六十岁的老人, 甚至大量聋哑工人”,这种就不应该是信息化的目标客户,说简单点,连电力都无法正常供应的企业还处于"第二次工业革命"的初期,你们公司就不应该为了赚点小钱去强行推"第三次工业革命"的体系。如果你们公司一意孤行,提前建议你:能"跑"就行。
|
109
huangsijun17 32 天前
小型设备,上锂电池?数据是缓存,用处不大,上 tmpfs ?
|
110
RockShake 32 天前
把删除日志的操作做成自启动脚本不就好了
|
111
cheese 32 天前
走一条单独的电线
|
112
wujianhua22 32 天前 1
买个远程关机的开关控制器,放到他们电闸的旁边,让他们先关远程的开关,再关电闸就好了。
|
113
raysonlu 32 天前
redo 日志删掉就可以是吧?那就写个脚本开机判断自动处理,不就解决问题?
|
114
guanhui07 32 天前
UPS
|
115
nicholasxuu 32 天前
每分钟 sql dump 一次。
启动时如果发现 db 有任何报错,直接重新用 dump 覆盖。 最多损失 1-2 分钟数据。 |
116
kinkin666 32 天前
那就 sqlite 呗,原始版本留一份,隔几个小时复制一下,起不来了就探个框,点确认就用之前能用的版本
|
118
Karte 32 天前
我记得好像有种 SSD 比较适合这种场景, 就是自带电容的。这些电容中的电量足够在断电情况下保持文件不会损坏 (前提都在 pagecache).
你可以搜一搜 "SSD PLT" 的硬盘. |
119
supermama 32 天前
ups 不是很便宜么? 或者直接跑云服务好了。
|
120
ouqihang 32 天前 via Android
就算上 UPS ,每天使用一次的频率,换电池也是几个月一次的事。到时候又要头疼换电池,一般 UPS 电池还不好换。
|
121
leegoo 32 天前
如果你的数据不是特别重要,并且在软件层面有处理这个机制(你可以理解为重试)
那么可以把 mysql 的事务保存的开关关闭。 之前简单测试过,关掉这个之后 最起码在断电情况下,数据库是可以启动的。而不是数据库直接损坏等.. 然后 mysql 有一个 redo 日志的保留个数把,可以搞短一点。 这个前提是你的数据不是特别重要,并且在软件层面有处理这个机制(你可以理解为重试) 这是最简单的做法 |
122
funky 32 天前 via iPhone
PostgreSQL 带有 checkpoint recovery 的推荐用这个
|
123
auhah 32 天前
先把锅甩出去再说。。服务跑得起来,硬件天天这么搞也受不了
|
124
hwb 32 天前
考虑到你的场景,难道不是买出去之后,在某个时间段人为出点 bug ,然后排查两天后反馈给用户,然后顺便卖个 UPS ?
|
125
cxdLand 32 天前
开机删除 redo
|
126
Ghostisbored 32 天前
开机脚本删除
|
127
ming159 32 天前
同样的场景, 我现在换成 PostgreSQL 了. 暴力断电的情况下,数据库起不来的情况比 MySQL 好那么一丢丢丢.
另外既然只需要删除 redo log 就行的话,其实你可以这么干 1. 软件上增加检测机制,启动时,检测 MySQL 是否正常启动, 2. 当 MySQL 未正常启动时,给个提示框,让人选择是否删除指定的 redo 日志. 然后重启 MySQL 服务 只要你有弹框提示,他们点几次就会操作了 |
128
glcolof 32 天前
一台 UPS 才几百块钱,性价比很高呀。
|
129
jimrok 32 天前 1
你这个场景就是 sqlite ,你知道 sqllite 是怎么发明的吗?写这个数据库的人就是军舰上的炮手,他们原来用的是 informix 数据库,经常演习的时候出故障。如果开一炮,硬盘就坏了的话,那军舰就直接等着被嘎了。所以这个哥们想能不能把数据都加载到内存里,硬盘嘎了至少军舰还能开火。你可以试试把生产数据直接落入文件里,每次启动时候载入,运行的时候,直接用 sqlite ,只要文件还能读取,系统起来就没事。
|
130
lrh3321 32 天前
启动 MySQL 前,先去检查 Redo Log ,不完整就删掉一部分。ExecStartPre
|
131
cnbatch 32 天前
既然是在这种工厂使用数据库,那么性能要求应该不高,笔记本电脑大概够用
不如告诉你的老板,买些笔记本电脑回来,替换掉现有的机器,然后把换下来的机器卖掉换钱,这样“以一换一”只要控制好价格就不会亏损,价格敏感的话还可以从二手商家买二手笔记本电脑 记得设置好通电自启、合盖不待机不休眠 |
132
Lynntox 32 天前
现在看来是数据有点问题,但是长远来看,硬件会不会坏啊,以后坏了怎么说啊,他们掏钱还是你们掏钱,比较好的解决就是要么服务器放在一个别的地方,业务去访问数据就可以,要么就是单独拉一路电和生产隔离(哪家工厂没电工啊,他们闲的要死)
|
133
felixcode 32 天前 via Android
不是正常关机的话,再启动软件就需要问你要授权码
|
135
syubo2810 32 天前
最优解:ups ,大概 300-500 成本
贴膏药:每次系统其他执行一个触发式脚本,删了 redo 日志 |
136
ntedshen 32 天前
不担心数据完整性的话。。。
感觉开个 myisam 然后每次开机都先执行一次全表检查和修复,理论上就能解决大部分问题。。。 没有事务那自然也就避免了靠日志保证数据完整然后日志又崩了这种事。。。 话说如果规模不大的话甚至可以自己整个像数据库的库吧,随便序列化一下往个文件一存不就完了。。。 |
137
zhujinliang 32 天前 via iPhone
弄一个带电池的小主机,把数据库装这个机器上面
|
138
zhangeric 32 天前
上个 ups 的事.
|
139
roundgis 32 天前 via Android
|
140
esile 32 天前 via Android
关闭缓存可能会好点吧
|
141
jimrok 32 天前
@roundgis 你说的对,读 sqlite 的故事时间太久了,记忆混乱了,是外包商。
“SQLite 诞生的契机就是典型的程序员开发的故事剧本。作者 Richard 最开始在一艘军舰上做 contractor (就是我们说的外包)。他们程序跑在军舰安装的电脑上,电脑上装的是 informix 。Richard 的工作就是把 informix 的数据拿出来进行计算然后展示到电脑屏幕上(这和我们今天的 CRUD 工作类似)。比较令人恼火的是 informix 很不稳定,经常崩溃连不上。部队里的铁拳长官可不懂啥 TCP/IP 或者数据库系统知识。他们只看到软件的报错 dialog (对话框) 经常弹出来,而这个 dialog 又是 SQLite 的作者 Richard 写的软件画出来的,锅自然从天而降。于是 Richard 决定自己从头写一个无需外部连接的数据库来解决这个问题。 当时恰逢布什政府消减政府预算,Richard 作为外包商没法获得订单,不得不暂停在军舰上的开发。这让 Richard 有了几个月的时间去构思并从头实现 SQLite 。那时时间是 2000 年初,软件开发没有现在这么多参考资料,没有维基百科,google 还没完全起来, 美国只有 1% 家庭有宽带。 而 Richard 也没有数据库开发经验,只有编译器开发经验。他最初的构想非常简单,把每条 sql 语句看成一个独立的执行程序。于是他首先实现了 bytecode 执行器,然后把 sql 语句转化成 bytecode 执行。一开始 SQLite 并没有替换掉他们在军舰上的 informix ,尽管他们每个开发者都恨透了 informix ,但客户指定要用又不得不继续使用(好熟悉的场景)。就这样 SQLite 一直做为 Richard 的 side project 在开发。 为了验证一些想法和测试其中的代码,Richard 开始把 SQLite 发布到网上,接下来的故事和 Linux 诞生有点类似了。很多人看到一个数据库居然能运行在 palm 这种性能非常弱的掌机上都大为惊叹。” |
143
fds 32 天前
问了 GPT ,回答:如果你的应用场景需要处理较大的数据和高并发,PostgreSQL 可能是最佳选择。PostgreSQL 使用一种高效的写入前日志( WAL )系统,即使在断电或系统崩溃的情况下也可以保证数据完整性。对于小型应用或嵌入式系统,SQLite 可能已足够,使用回滚日志或写入前日志( WAL ),可以在断电后自动恢复到一致状态。
跟前面大家的主流意见一致。 |
144
byte10 32 天前
可以考虑加一个 4G 无线 wifi ,十几块,搞远程数据库吧。或者加几十块的那些啥开发板做底层的数据库存储,充电宝就能保护它了。
|
145
TellMeWHY 32 天前
用无盘系统、瘦客户机,每次都从云服务器上下载启动镜像,业务数据都放云端,除了开机时间长点,断电不怕
|
146
windyboy 32 天前
|
148
doyel 32 天前
300 块的 UPS ,够带服务器 Shutdown 的时间就够了,写个 cron ping 网关,掉了就执行关机。。。
|
149
ltyj2003 32 天前 via Android
有带很多电容的固态硬盘,主板掉电时硬盘自己能完成保护,避免坏数据和固件。
|
150
loveour 32 天前
经常断电硬盘一定会坏。记得常备份。
|
151
Rorysky 32 天前
硬件层面可以选择带电容的 ssd ,断电基本不会有问题,会有缓冲时间让系统写入
系统层面选择 日志文件系统,并做好 raid |
152
szx300 32 天前 via iPhone
ups 又不贵,小型的啊
|
153
kwater 32 天前
检测到断电 ups 通知系统安全关机,这是民用 ups 都可以的,这种方式工作应该至少可以撑 3 年。
一台核心生产机器三四百都觉得会破产,那还是。。。。 |
154
afeiche 31 天前
没有事务的数据库估计好恢复,sqlite 吧
|
155
kid1412621 31 天前 via iPhone
按理说消防用电应该是单独走线的…
|
156
zhangeric 31 天前
如果数据不重要,直接上文件类型的数据库,比如 sqlite,access 一类,每天生成一个新的数据库.当天的损坏了,不影响其他.
|
157
james122333 31 天前 via Android
买大型可以带多台机器的 ups 不正常断电机器坏更伤的 看到有蛮多带 15 台要价 1300 的
|
158
james122333 31 天前 via Android
应该还有性价比更高的 ups
|
159
james122333 31 天前 via Android
抱歉 没注意看 原来是客户机房 那说实话量也不大 直接硬盘储存就好
|
160
spritecn 31 天前
云数据库
|
161
yanxu4780 31 天前
建议把服务器迁移到云服务器上去,别在他们工厂里面。
|
162
thtznet 31 天前
@bthulu 我没见过会断电的工厂。我所待过的工厂只有会配置无间断电源和柴油发电机组的,没听过工人有权限能拉闸的,配电房不是基础设施运维岗位都没有权限进入。如果你的项目所在的工厂真的连电力都无法保证供应,而且连电力这么重要的供应管理任何一个工人都可以接触到足以说明你的这个项目的工厂真的还处于初级阶段,这种级别的工厂不建议去设施信息化项目。
|
164
julyclyde 31 天前
既不,又不
我觉得说白了还是业务不值钱 直接拒绝修复才是最便宜的选择 |