🥇“专业，但不是集群”或者我们如何替换导入 DBMS

(ts) Yandex.Images

所有人物都是虚构的，商标属于其所有者，任何相似之处都是随机的，总的来说，这是我的“主观价值判断，请不要破门……”。

我们在将具有逻辑的信息系统从一个 DBMS 转移到另一个 DBMS 的数据库方面拥有丰富的经验。根据 1236 年 16.11.2016 月 XNUMX 日第 XNUMX 号政府法令，这通常是从 Oracle 到 Postgresql 的转移。我们可以单独告诉你如何尽可能高效、轻松地组织流程；今天我们将讨论使用集群的特点以及在构建流程和功能逻辑复杂的高负载分布式系统时会遇到哪些问题。

剧透 - 是的，cap、RAC 和 pg multimaster 是非常不同的解决方案。

假设您已经将所有逻辑从 plsql 转移到 pgsql。你的回归测试非常好，现在你当然正在考虑扩展，因为...... 对于非常不同的 DBMS，负载测试不会让您非常满意，尤其是在项目最初包含的硬件上。假设您从国内供应商“Postgres Professional”找到了一个解决方案，其中包含一个名为“multimaster”的选项，该选项仅在“Postgres Pro Enterprise”的“最大”版本中可用，并且根据描述 - 它与你需要，并且通过第一次肤浅的学习，我的脑海中就会出现这样的想法：“哦！就是这样，而不是 RAC！即使在我们的祖国也有技术管道！”

但不要急于高兴，我们将进一步描述为什么您需要了解这些细微差别，因为...... 即使在彻底阅读了产品文档之后，它们也很难预测。评估您是否准备好直接在生产站点上频繁更新 DBMS 版本，因为有些缺陷与工业用途不兼容，并且在测试过程中难以发现。
首先仔细阅读制造商网站上的“多主控”-“限制”部分。

您可能遇到的第一件事是所谓的交易工作方式的特殊性。 “两阶段”模式，有时除了重写程序的整个逻辑之外没有办法解决这个问题。这是一个简单的例子：

create table test1 (id integer, id1 integer);
insert into test1 values (1, 1),(1, 2);
 
ALTER TABLE test1 ADD CONSTRAINT test1_uk UNIQUE (id,id1) DEFERRABLE INITIALLY DEFERRED;
 
update test1
           set id1 =
               case id1
                 when 1
                 then 2
                 else id1 - sign(2 - 1)
               end
         where id1 between 1 and 2;

出现错误：

ОШИБКА:  [MTM] Transaction MTM-1-2435-10-605783555137701 (10654) is aborted on node 3. Check its log to see error details.

那么你可以在 10.5、10.6 版本中与死锁作斗争很长时间，唯一已知的杀死集群整体本质的解决方案是从集群中删除“问题”表，即执行 make_table_local，但这至少会允许它工作，并且不会因为挂起等待事务提交而搁置所有内容。好吧，或者安装 11.2 版本的更新，这应该会有所帮助，但也许不会，请不要忘记检查。

在某些版本中，您可以获得更神秘的锁：

username= mtm и backend_type = background worker

在这种情况下，只有将 DBMS 版本更新到 11.2 及更高版本才会对您有所帮助，也可能没有帮助。

某些索引操作可能会导致错误，这清楚地表明问题出在双向复制中；您将直接在 MTM 日志中看到 BDR。真的是第二象限吗？不...我们买了一个多主控，这只是一个巧合，这是该技术的名称。

[MTM] bdr doesn't support index rechecks
[MTM] 12124: REMOTE begin abort transaction 4083
[MTM] 12124: send ABORT notification for transaction  (5467) local xid=4083 to coordinator 3
[MTM] Receive ABORT_PREPARED logical message for transaction MTM-3-25030-83-605694076627780 from node 3
[MTM] Abort prepared transaction MTM-3-25030-83-605694076627780 status InProgress from node 3 originId=3
[MTM] MtmLogAbortLogicalMessage node=3 transaction=MTM-3-25030-83-605694076627780 lsn=9fff448

如果您使用临时表，尽管有这样的保证：“多主机扩展以完全自动的方式执行数据复制。您可以同时执行写入事务并使用集群中任何节点上的临时表。”

那么实际上您会发现复制不适用于过程中使用的所有表，如果代码包含临时表的创建，甚至使用 multimaster.remote_functions 也无济于事，您将不得不更新或重写您的逻辑步骤。如果您需要在“Postgres Pro Enterprise”v 10.5 的框架内同时使用两个扩展 multimaster 和 pg_pathman，请使用以下简单示例进行检查：

CREATE TABLE measurement (
    city_id         int not null,
    logdate         date not null,
    peaktemp        int,
    unitsales       int
) PARTITION BY RANGE (logdate);

CREATE TABLE measurement_y2019m06 PARTITION OF measurement FOR VALUES FROM ('2019-06-01') TO ('2019-07-01');
insert into measurement values (1, to_date('27.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (2, to_date('28.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (3, to_date('29.06.2019', 'dd.mm.yyyy'), 1, 1);
insert into measurement values (4, to_date('30.06.2019', 'dd.mm.yyyy'), 1, 1);

DBMS 节点上的日志中开始出现以下错误：

…
 PATHMAN_CONFIG doesn't contain relation 23245
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt//…/ent-10/lib/pg_pathman.so"
> ОТЛАДКА:  find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman"
> find_in_dynamic_libpath: trying "/opt/…/ent-10/lib/pg_pathman.so"
> PrepareTransaction(1) name: unnamed; blockState: PREPARE; state: INPROGR, xid/subid/cid: 6919/1/40
> StartTransaction(1) name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0
> switched to timeline 1 valid until 0/0
…
Transaction MTM-1-13604-7-612438856339841 (6919) is aborted on node 2. Check its log to see error details.
...
[MTM] 28295: REMOTE begin abort transaction 7017
…
[MTM] 28295: send ABORT notification for transaction  (6919) local xid=7017 to coordinator 1

这些错误你可以在技术支持里查出来，你没白买。

该怎么办？正确的！升级到“Postgres Pro Enterprise”v 11.2

另外，您需要知道序列作为复制数据库的对象，在整个集群中没有端到端值，每个序列对于每个节点来说都是本地的，如果您有具有唯一限制的字段并使用序列，那么你只能增加相当于集群中节点数的增量，因为集群中的节点越多，sequence 和 int 的增长速度就会比你预期的要快。为了简化产品中序列的使用，您甚至可以找到 alter_sequences 函数，该函数将为所有节点上的每个序列进行必要的增量，但请注意该函数并非在所有版本中都有效。当然，你可以自己写，以github上的代码为基础，或者直接在DBMS中自己修改。在这种情况下，serialbigserial 类型的字段将工作得更正确，但要使用它们，您很可能需要重写过程和函数的代码。也许有人会发现 monotonic_sequences 函数很有用。

在 Postgres Pro Enterprise 11.2 版本之前，复制仅在存在唯一主键的情况下才有效，开发时请考虑到这一点。

另外，我想提一下 npgsql 在集群解决方案中工作的特殊性；这些问题不会出现在单个节点上，但在多主机中却很常见。
在某些版本中您可能会遇到错误：

Exception Details: Npgsql.PostgresException: 25001: команда SET TRANSACTION ISOLATION LEVEL 
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

可以做什么？您只需不要使用某些版本即可。你需要了解他们，因为... 该错误出现在多个版本中，即使在第一次修复后，您以后也可能会遇到它。您还需要为此做好准备，最好覆盖所有已识别的 DBMS 缺陷，这些缺陷由制造商通过单独的回归测试进行纠正。可以这么说，信任，但要验证。

如果应用程序使用 npgsql 并在认为它们都是相同的节点之间切换，那么您可能会收到错误：

EXCEPTION:Npgsql.PostgresException (0x80004005): XX000: cache lookup failed for type ...

出现此错误是因为绑定正在进行中

(NpgsqlConnection.GlobalTypeMapper.MapComposite<SomeType>("some_composite_type");)

应用程序启动时所有连接的复合类型。结果，我们从一个节点获取了一个标识符，而在另一个节点上请求时，它不匹配，因此返回错误，即对于某些应用程序来说，如果没有额外的应用程序端重写（如果您设法这样做），则无法在集群中透明地使用复合类型。

众所周知，对集群状态的整体评估对于运行期间的诊断和操作措施非常重要，在产品中您可以找到一些应该让您的生活更轻松的功能，但有时它们可能会给出与实际完全不同的东西您甚至制造商本身对他们的期望也是您所期望的。

例如：

select mtm.collect_cluster_info();
на каждой ноде выдает одинаковый результат:
(1,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(2,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:06")
(3,Online,0,0,0,2,3,0,0,0,1,0,0,1,1,3,7,0,0,0,"2018-10-31 05:33:09")

但是为什么LiveNodes字段到处都包含数字2，尽管根据多主控操作的描述它应该对应于数字AllNodes=3？答：需要更新DBMS版本。

并准备收集所有节点的日志，因为...... 通常你会看到“错误在另一个节点的日志中”。技术支持将接受您发现的所有缺陷，并通知您下一个版本已准备就绪，有时需要在服务停止的情况下安装，有时需要很长时间（取决于您的 DBMS 的大小）。您不应该希望操作问题会极大地困扰供应商，并且由于已识别的缺陷而进行的更新将在供应商代表的参与下进行，或者更确切地说，您甚至不需要供应商代表的参与，因为在最终，您可能会在生产中得到一个已拆卸的集群，而无需备份。

事实上，在商业产品的许可证中，制造商诚实地警告说：“该软件是按“原样”提供的，Postgres Professional Limited Liability Company没有义务提供维护、支持、更新、扩展或更改。”

如果您还没有猜到我们在谈论哪个产品，那么所有这些经验都是经过一年的 Postgres Pro Enterprise 数据库操作而获得的。你可以得出自己的结论，太潮湿了，蘑菇就长出来了。

但如果及时采取行动并及时消除新出现的问题，情况也不会那么糟糕。

但这恰恰没有发生。显然制造商没有足够的资源来及时消除已发现的错误。

只有注册用户才能参与调查。登录拜托

您是否有从国外/专有 DBMS 切换到免费/国内 DBMS 的经验？

21,3%是的，积极10
10,6%是的，负面5
21,3%否，DBMS 未更改10
4,3%DBMS 已更改，但没有任何更改2
42,6%查看结果20

47 位用户投票。 12 名用户弃权。

来源： habr.com

“专业，但不是集群”或者我们如何替换导入的 DBMS

您是否有从国外/专有 DBMS 切换到免费/国内 DBMS 的经验？