我正在使用 PostgreSQL 热备份运行测试,有 1 个主站,正好有 1 个从站。
我正在使用本指南中的说明:http : //www.howtoforge.com/how-to-set-up-a-postgresql-9.0-hot-standby-streaming-replication-server-with-repmgr-on-opensuse -11.4
我使用的是 PostgreSQL 9.1 版、repmgr 1.1.0 和 Ubuntu 10.04 LTS。
我按照我跑的指南中的步骤进行了步骤 6
repmgr -D /var/lib/postgresql/9.1/main -d pgbench -p 5432 -R postgres --verbose standby clone pgmaster
Run Code Online (Sandbox Code Playgroud)
在 pgslave 上。
然后我做了一个
/etc/init.d/postgresql start
Run Code Online (Sandbox Code Playgroud)
在它上面,脚本(似乎)成功完成。
但是,执行 psql 会引发错误:
psql: FATAL: 数据库系统正在启动
欢迎任何有关进一步进行的帮助。
好吧,有点复杂:
选项:我应该...
是的,我在这个东西上搜索了很多,但我还没有看到以相同方式描述的这个问题。
感谢您的帮助或回答!
我们考虑从主从转移到MongoDBwith replica-set。现在我想知道MongoDB副本是否也像主-主农场一样设置,read-only slaves或者每个副本是否都mongos能够写入和同步其他副本?
这可能会减少单一错误源 ( master down) 并平衡write-load缩放与最佳性能(不仅对于读取,而且对于写入...)。
我有两个 RDS 实例:一个 R/W 主实例和一个只读副本。
6 月 29 日,副本停止注册复制数据 - 不确定这是否相关。
7 月 3 日,master 的 CPU 使用率开始单调增加,并且急剧增加:

现在几乎是 100% 的临界值。
据我所知,查询量并没有真正改变。当时唯一发生的事情是我的 web 层中的一个 django-celery 守护进程占用了整个 CPU 核心——强制杀死它似乎解决了 web 层上的问题,但似乎 DB 层问题可能与此相关。
同时数据库大小也开始单调增加:

进程列表中没有长查询,也根本没有插入,所以我不确定如何找出哪些表在增长,以及 CPU 的去向。
是否有 MySQL 诊断,同时可以显示表大小趋势?配置全局正在进行的查询?配置全局 CPU 使用率?
我已经重新启动了服务器几次,但无济于事。
服务器上显然还有很多空间,但是当 CPU 使用率达到 100% 时,事情会变得很糟糕,因此非常感谢任何帮助!
我在主数据库中有一个表,我想将其复制到一台从属服务器上的多个数据库。像这样:
masterDB.tableA -> slaveDB1.tableA
masterDB.tableA -> slaveDB2.tableA
Run Code Online (Sandbox Code Playgroud)
slaveDB1 和 slaveDB2 在同一个从服务器上。这可能吗?
我可以让 slaveDB1 的复制工作没有问题,但因为它忽略了 my.cnf 中用于 slaveDB2 的命令:
replicate-rewrite-db="masterDB->slaveDB1"
replicate-rewrite-db="masterDB->slaveDB2"
replicate-wild-do-table=slaveDB1.tableA%
replicate-wild-do-table=slaveDB2.tableA%
Run Code Online (Sandbox Code Playgroud)
我是否遗漏了什么,或者这不能通过 MySQL 复制来完成?
我在两个 postgres 服务器(主服务器:服务器 A,从服务器:服务器 B)之间进行了流式复制设置。我想知道当我触摸触发器文件并且从设备接管作为主设备时,引擎盖下实际发生了什么?我想知道的一件事是,在教程或文档中似乎没有人提到任何地方,如果我在完成后重新启动以前的奴隶(现在是主人)怎么办?事情不会变得一团糟,因为 .conf 文件仍然反映了旧的从站设置(例如 hot_standby = on)?在我可以安全地重新启动服务器之前,我应该更新那个 .conf 吗?
背景:我所处的情况让我想知道这一切是我需要更换我主控上的硬盘。这是我打算这样做的方式:
(顺便说一句。如果您对更好的工作流程有建议,请告诉我)
这是一个非常复杂的场景,但我认为最先进的挑战可能会对 dba.se 的许多高端用户感兴趣。
问题
我正在使用 Oracle GoldenGate 为文档生产系统开发洲际数据复制解决方案,有点类似于 wiki。主要目标是在全球范围内提高应用程序性能和可用性。
该解决方案必须允许从多个位置同时读/写访问同一个数据池,这意味着我们需要一些聪明的方法来防止或解决没有用户交互的冲突更新。
专注于碰撞预防,我们必须允许全局锁定对象(文档、插图、一组元数据等),从而防止多个用户同时编辑来自不同位置的同一对象 - 最终导致冲突。
类似地,对象必须保持锁定状态,直到任何用户连接的数据库收到该对象的更新数据,否则用户可能会开始编辑没有最新更新的旧对象。
背景
该应用程序对延迟有些敏感,这使得从远程位置访问中央数据中心的速度变慢。像许多以内容为中心的系统一样,读/写比率在 4 比 1 的范围内,使其成为分布式架构的理想选择。如果管理得当,后者还将努力确保站点或网络中断期间的可用性。
我使用了一种有点非常规的多循环双向复制拓扑。这将复杂性保持在可管理的级别 { 2(n-1) 方式},增加了站点中断的弹性,并允许相当简单地添加或删除站点。一个小缺点是,通过中央主数据库在最远程站点之间复制事务可能需要长达 30 秒的时间。
在所有站点之间直接复制的更传统的设计会将时间缩短一半,但也会显着增加配置 { n(n-1) 方式}的复杂性。
五个位置意味着 20 路复制,而不是我设计中的 8 路复制。
此图显示了我当前跨欧洲、亚洲和北美数据中心的测试环境。生产环境预计会有更多的位置。

所有数据库都是 Oracle 11.2.0.3 和 Oracle GoldenGate 11.2.1。
到目前为止我的想法
我一直在思考通过在中央数据库的数据库链接上将一行插入到“锁定”表中来进行锁定,同时让解锁(前面提到的行的更新或删除)与更新的行一起复制数据。
在获取锁和打开对象进行编辑之前,我们必须代表用户检查中央和本地数据库中锁的可用性。编辑完成后,我们必须释放本地数据库中的锁,然后通过中央数据库将更改和锁的释放复制到所有其他位置。
但是,对高延迟数据库链接的查询有时会非常慢(测试显示单个插入需要 1.5 秒到 7 秒),而且我不确定我们是否可以保证删除锁的更新或删除语句是要复制的最后一条语句。
调用远程 PL/SQL 过程进行检查和锁定至少会将操作限制为单个远程查询,但 7 秒仍然是很长的时间。像两秒钟这样的事情会更容易接受。我希望可以以某种方式优化数据库链接。
还可能存在其他问题,例如在从中央数据库成功复制本地锁定表中的行之前尝试删除或更新该行。
从好的方面来说,使用这种解决方案,如果与中央数据库的通信中断,让应用程序进入只读状态,或者在数据中心不可用时重定向客户端,应该相对简单。
有没有人做过类似的事情?解决这个问题的最佳方法是什么?
就像我最初说的那样,这是一个相当复杂的解决方案,请随时询问任何不清楚或遗漏的地方。
我们在主服务器上的 Ubuntu Linux 12.04 上使用 PostgreSQL 9.1.7,在副本服务器上的 FreeBSD 9.0-RELEASE 上使用 PostgreSQL 9.1.7。副本服务器和主服务器对同一 SQL 查询返回不同的结果。查询计划显示使用索引(BTree 索引,我们根本不使用哈希索引)来获取结果,因此看起来索引在副本服务器上处于不一致或不完整状态。主服务器上的查询:
db1=# select id from users where email='xxxx@xxxx.net';
id
---------
1698116
(1 row)
db1=#
Run Code Online (Sandbox Code Playgroud)
在副本服务器上的查询:
db1=> select id from users where email='xxxx@xxxx.net';
id
----
(0 rows)
db1=> select created_at from users where id=1698116;
created_at
----------------------------
2013-03-04 10:40:05.221214
(1 row)
db1=>
Run Code Online (Sandbox Code Playgroud)
正如您所看到的,副本数据库已经包含一个具有正确 ID 的用户,因此数据已就位,但由于某种原因尚未编入索引。我们仔细检查了副本是否处于接收/重新应用状态,因此这不是暂时中断。用户从未被编入索引。我们也曾在 CentOS 5.6 上使用 PostgreSQL 9.0 遇到过类似问题,因此我们认为这不是 FreeBSD 或 PostgreSQL 9.1 特定的问题。
我们使用副本服务器运行大量繁重的 SQL 查询,这可能是问题的根源吗?无论如何,我们如何才能有效地检测和防止将来发生此类情况?副本今天没有停机,日志中没有任何错误行,所以我们只是偶尔检测到这种不一致。
我们有一个基于 ROW 的复制的主从设置。即使没有活动在 master 或 slave 上运行,我们也看到了 salve 的巨大延迟。
当我们查看时,我们观察到 SQL 线程看起来像是挂了。自过去 3 小时或更长时间以来,它一直处于“从中继日志中读取事件”状态。
baleaf:(none)> show processlist ;
+--------+-------------+-----------+------+---------+-------+----------------------------------+----- -------------+
| Id | User | Host | db | Command | Time | State | Info |
+--------+-------------+-----------+------+---------+-------+----------------------------------+----- -------------+
| 217159 | system user | | NULL | Connect | 1039 | Waiting for master to send event | NULL |
| 217160 | system user | | NULL | Connect | 10045 | Reading event from the relay log …Run Code Online (Sandbox Code Playgroud) 我有一个 AWS RDS MySQL 数据库。我不是 DBA,所以我的知识有限。
我希望在复制或数据备份方面设计策略以在发生故障时实现零数据丢失。
我知道它们是不同的术语。(并且忽略错误的删除语句可以删除数据,在这种情况下复制可能没有用)。
我希望做的就是在出现数据库故障时实现零数据丢失。AWS 维护快照,但这可能需要几个小时。所以有数据丢失。
我应该考虑在 AWS 之外设置数据库服务器吗?或者是什么?我应该进行复制还是定期备份?
DBA 有什么其他策略吗?
replication ×10
mysql ×4
postgresql ×3
amazon-rds ×2
backup ×1
failover ×1
goldengate ×1
locking ×1
mongodb ×1
oracle ×1
performance ×1
repmgr ×1