1
ys0290 2017-02-01 14:40:27 +08:00 via iPhone 1
各个数据库密码不要一样😂
|
2
ixinshang 2017-02-01 14:43:53 +08:00 via Android
关注一下 有几个数据库 要看下怎么弄
|
3
dikcen 2017-02-01 14:54:04 +08:00 via Android
双人双锁
|
4
tywtyw2002 2017-02-01 14:58:45 +08:00
这个问题我们之前还真的讨论过,如果不差钱的话,直接在存储设备上备份最安全高效,但是真的很贵,非常的贵。
Bank of America 之前的一套存储系统+X 年技术支持,我没记错的话是 0.2 B 。 目前在研发的存储设备能支持 time machine 了,可以回到之前任意一分钟的数据。( cow 嘛,但不仅仅是 cow , 100TB 数据需要大概 500TB 的实际空间去支持 1 个月的 time machine ) |
5
msg7086 2017-02-01 15:47:06 +08:00
不就是 MySQL Replication 嘛,多标准化的手续……
其他的软件环境就看造化了。 |
6
precisi0nux 2017-02-01 16:09:07 +08:00
我们用 aws 的 snapshot 从来没出过问题。
|
7
matrix67 2017-02-01 16:17:14 +08:00 1
todo list 不错
1. Sid: shared a public link to this document from @gitlabstatus, https://twitter.com/gitlabstatus/status/826591961444384768 2. Update sentry DSN to production as it ’ s updated for staging to point to a different project 3. Try to restore webhooks 4. Remove the users we removed earlier today due to spam/abuse. 5. Create outage issue 6. Create issue to change terminal PS1 format/colours to make it clear whether you ’ re using production or staging (red production, yellow staging) 7. Show the full hostname in the bash prompt for all users by default (e.g., “ db1.staging.gitlab.com ” instead of just “ db1 ”) 8. Somehow disallow rm -rf for the PostgreSQL data directory? Unsure if this is feasible, or necessary once we have proper backups 9. Add alerting for backups: check S3 storage etc. 10. Consider adding a last successful backup time in DB so admins can see this easily (suggested by customer in https://gitlab.zendesk.com/agent/tickets/58274) 11. Figure out why PostgreSQL suddenly had problems with max_connections being set to 8000, despite it having been set to that since 2016-05-13. A large portion of frustration arose because of this suddenly becoming a problem. 12. Upgrade dbX.cluster to PostgreSQL 9.6.1 as it ’ s still running the pinned 9.6.0 package (used for the Slony upgrade from 9.2 to 9.6.0) 13. Flush Redis cache once the DB has been restored 14. Add server hostname to bash PS1 (avoid running commands on the wrong host) |
8
wenymedia 2017-02-01 16:47:00 +08:00 via Android
懒人方案 服务器数据盘快照备份…
|
9
param 2017-02-01 16:48:58 +08:00
求可以免費的備份方案。。。配合 docker 使用
|
10
param 2017-02-01 16:49:39 +08:00
我想到的免費方案是用網盤自動同步。。
用 docker 的話就網盤同步,備份 volume |
11
ZE3kr 2017-02-01 16:53:27 +08:00 via iPhone 1
以后不用 rm ,用 mv ,把文件 mv 到 /trashed 之类的文件夹,然后配置个定期清理 /trashed 下老文件的脚本。禁止远程执行 rm 之类的?或者用.bash_profile 禁用 rm 指令?
然而发现 macOS 和 Windows 早已经解决了误删除的问题“废纸篓”、“回收站”。 |
12
ETiV 2017-02-01 17:59:41 +08:00 via iPhone
用的阿里云 RDS ,它自带了个备份但还没用过
除此之外办公室内网有个实时的 slave 在跑,每分钟检查两个 RUNNING 是否为 Yes 。如有异常,微信推送给我告警。 还有我们数据库读写压力很小很小,就直接在生产机器上做了每 15 分钟的 mysqldump | 7za 。然后每天把前一日的 7z 丢到禁用了公开访问的 upyun 空间上去 |
13
66450146 2017-02-01 18:05:45 +08:00
https://news.ycombinator.com/item?id=8522127
首先呢要保证你的冗余系统的冗余意味着像肾脏那样的冗余,而不是像阑尾那样 然后实际演练一遍——如果你说你的防弹衣能挡子弹,最好的测试方法就是对它射几枪。如果你觉得你的服务器能在被清空数据之后恢复回来,那就清空一遍试试看。 |
14
ebony0319 2017-02-02 01:01:28 +08:00 via Android
GitLab.com 有五重多备份机制:常规备份( 24 小时做一次)、自动同步、 LVM 快照( 24 小时做一次)、 Azure 备份(只对 NFS 启用,对数据库无效)、 S3 备份。总有一样好使,所以大家不要担心,只是时间问题。
|