标签: percona

我完全没有想法，所以也许其他人可以回答我的问题。我们有一个来自 Percona 的高流量 MySQL 5.5 服务器。该应用程序是在 PHP 中并始终写入 master。我们同时有 4 个奴隶，我们只能从中读取。基本上它是标准的主从配置。上周发生在所有从站上的复制都被破坏了，所以我检查了数据库有什么问题。我发现的基本上是我的问题，这怎么会发生：其中一个表中的唯一键列（不是主键）在 2 行中具有相同的值。我试图找出这种情况是否发生过一次以上，但没有。它只发生过一次，但我会理解为什么或如何发生这种情况。为了更好地理解这里是我们数据库中的一些真实数据：

show create table registeredUsers;
| registeredUsers | CREATE TABLE `registeredUsers` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `userId` varchar(32) NOT NULL,
  `client` varchar(200) NOT NULL,
  `osVersion` varchar(10) NOT NULL,
  `deviceGroup` varchar(50) NOT NULL,
  `registrationDate` datetime NOT NULL,
  `lastAction` datetime NOT NULL,
  `cultureLanguage` varchar(2) NOT NULL,
  `cultureRegion` varchar(2) NOT NULL,
  `cultureCode` varchar(5) NOT NULL DEFAULT 'de-de',
  `lastPush` datetime DEFAULT NULL,
  `pushToken` mediumtext,
  `permaToken` varchar(74) DEFAULT NULL,
  `accessCount` int(11) …

我有一个 Percona MySQL 集群，有一个主节点和几个从节点。他们每个人都运行 MySQL 的“Ver 14.14 Distrib 5.5.40-36.1”。复制是基于行的。

我仅对从属设备的其中一张表运行了更改查询。计划是在所有从服务器上运行此查询，然后进行主切换，因为我们无法承受在主服务器上锁定表。

查询是：

ALTER TABLE order_item_units 
MODIFY parent_id BIGINT(20) unsigned ;

并在我使用检查从站时发布此信息show slave status，我看到复制被破坏并出现以下错误：

表“database_name.order_item_units”的第 3 列无法从“int”类型转换为“bigint(20) unsigned”类型

当我检查该列时，它确实转换为BIGINT.

现在我无法解决这个问题。我确实停止了奴隶并启动了奴隶，没有帮助。没有停止奴隶和 MySQL 重新启动，没有帮助。做了一个跳过计数器，也没有帮助。

要么该列不应该被转换，那么错误就是正确的，但可能根本不应该有任何错误。

如果列确实被转换了，那么为什么会出现错误？

任何线索我在这里错过了什么？

我找不到任何东西，所以我确定答案是否定的，你是什么，菜鸟？但我觉得无论如何都有必要问:)

是否有一个简单的实用程序可以允许在现有主服务器上启动新的从服务器，而无需在主服务器上执行转储？

我已经多次以传统方式设置奴隶，所以我并非不了解这个过程，但我很好奇是否有人和我有同样的感觉，一定有更简单的方法。

我希望这样的实用程序会使用类似于 Percona 的 Xtrabackup 的东西，但它不会输出到转储文件，而是将输出直接流式传输到从属，然后在提要结束后自动启用从属关系。

这是现实的吗？

我注意到 Xtrabackup 中的流选项，但在其仅将 tar 保存在另一台服务器上的能力之外找不到示例，这不是我想要的。我想要一个可以直接流入目标数据库的解决方案，而根本不需要使用转储文件。这在处理大型数据集时特别方便。

我已经通过 PerconaXtrabackup 工具创建了一个 MySQL 备份（感谢本指南）：

innobackupex --user=backupmysqluser --password=xyz --compress --stream=xbstream ./ > /var/backups/db/firstBackup.db

它成功创建了热备份。现在我想测试它的恢复情况，所以，首先，我解压它：

cd /var/backups/db
mkdir decompressed
xbstream -x -C decompressed

现在我试着准备它：

innobackupex --apply-log /var/backups/db/decompressed/

结果是这个错误：

160719 20:06:28 innobackupex: Starting the apply-log operation

IMPORTANT: Please check that the apply-log run completes successfully.
           At the end of a successful apply-log run innobackupex
           prints "completed OK!".

innobackupex version 2.4.3 based on MySQL server 5.7.11 Linux (x86_64) (revision id: 6a46905)
xtrabackup: cd to /var/backups/db/decompressed
xtrabackup: This target seems to be …

首先，我问这个的原因是因为我觉得我有一个数据库 - 根据我自己的估计 - 应该用大量 I/O 杀死磁盘，因为索引不适合内存，但在实际上它仍然表现良好。

让我们从相关表开始：

CREATE TABLE `search` (
  `a` bigint(20) unsigned NOT NULL,
  `b` int(10) unsigned NOT NULL,
  `c` int(10) unsigned DEFAULT NULL,
  `d` int(10) unsigned DEFAULT NULL,
  `e` varchar(255) DEFAULT NULL,
  `f` varchar(255) DEFAULT NULL,
  `g` varchar(255) DEFAULT NULL,
  `h` varchar(255) DEFAULT NULL,
  `i` varchar(255) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

该a列是一个 8 字节的数字，其中编码了时间戳（以秒为单位）。该表有一个PARTITION BY RANGE (a), 将表分成每月分区。这是因为我们只在数据库中保留了 24 个月，其余的都被清除了。

该表每月增长约 2 亿行；整个表包含大约 50 亿行。

它运行的服务器有大约 360GB 的内存，其中 300GB 是为 MySQL …

我们使用 RocksDB 作为我们的引擎已经有一段时间了，现在我们正在尝试迁移到 WiredTiger。我们有一些相当大的数据库，大约有 4~12 TB 的数据，根据文档中描述的过程，我们添加了一个带有 WiredTiger 的新节点，并尝试让它从头开始复制。

对于数据量，复制时间非常长，很多时候我们遇到的情况是 WiredTiger 节点决定更改它从中复制的节点，只是删除所有数据并重新从头开始。只有一次我们成功完成了复制，但与 oplog 相比，节点最终落后了很多。

同样，对于如此大量的数据，拥有足够大的 oplog 来保存数周的事务变得令人望而却步，并且该过程也非常脆弱、单线程、缓慢且容易失败。

所以我的问题如下：

1. 是否有更好的方法来进行此迁移？

2. 有没有办法加速复制（即多线程复制）？

3. 有没有办法告诉新的 WiredTiger 节点在发生事故时停止丢弃所有数据？

我们正在使用 Percona MongoDB 3.4.13 版的 3 和 5 个节点副本集，并尝试迁移到开源 MongoDB 3.4.13（我们的想法是在 WiredTiger 中升级到 4.x 并完全放弃 RocksDB 和 Percona） .

我已阅读pt-online-schema-change文档并了解它的工作原理是创建触发器并在块时间秒内复制数据块（默认为 0.5 秒）

让我们考虑下面的情况。

我们有一个 5 GB 的表 TBL1，正在使用 PT-ONLINE-SCHEMA-CHANGE 进行更改

PT-ONLINE-SCHEMA-CHANGE 使用所需的更改创建了新表，在 TBL1 上添加了触发器并开始复制。

复制了 10 个数据块，并开始复制第 11 个数据块，其大小约为“X”MB。根据工具，该块最多可在 500 毫秒或 0.5 秒内复制

在第 11 个块复制期间，应用程序发出了一个 UPDATE，它必须修改属于第 11 个数据块的有效行。

我的问题是现在发生以下哪些事情。原始表现在发生？

A) Update will be blocked till the chunk be copied and then applied on original table 
   which gets updated through triggers on new one.

B) Update will be performed on original table and data chunk will be re copied all 
   over again.

如果选项 A 是答案，那么 PT-ONLINE-SCHEMA-CHANGE 如何实现无锁？ …

我们有一个 galera 集群，有 3 个节点，在 3 台不同的物理机器上，但都位于同一个数据中心。

据我了解，他们过去部署此功能的原因是为了提高可用性和可靠性，DC 故障不是问题。每个节点都安装在使用 12 个内核和 4Gb RAM 的 VM 上。（根据我所做的监控，我们可以将使用的内核数量减少到 4 个）

我们被要求将其迁移到 Google Cloup Platform 以摆脱操作任务。我可以创建 3 个计算引擎实例并部署 galera 集群，GCP 甚至有 Percona XtraDB Cluster 一键部署服务，但与具有复制和备份的 Cloud SQL 实例相比，我很难看到附加值。我对扩展重负载系统不是很熟悉。

托管在这些节点中的数据库非常关键，应确保最大的可用性和可靠性。

为了将此架构迁移到 GCP，我应该采用什么策略？

我们使用 Percona 的 pt-table-checksum 进行 MySQL 复制完整性检查。
是否可以使用某种配置文件传递部分或全部选项？

例如，我们可以在文件中写入我们想要检查的表列表吗？
我理解的手册没有讲这样的文件：http : //www.percona.com/doc/percona-toolkit/2.1/pt-table-checksum.html

我对 MySQL 复制（主从）几乎没有怀疑。表是否必须具有用于复制的主查询才能正常运行？

参考上面问题的这个 Percona 链接，因为它提到如果没有定义主键或唯一键，那么情况更糟，因为 INSERT 可能会被重新执行，并且您将获得具有相同数据的多行 – 这再次意味着您已经得到与主人不一致的数据

但是使用 InnoDB 作为存储引擎，如果表没有定义主查询或唯一查询，引擎本身会根据Jeremy Cole 的博客在包含行 ID 值的合成列上创建隐藏的聚集索引

因此，即使在主要或唯一不存在的情况下，复制也不应该有任何影响，它本身会创建一个聚集索引，以确保复制顺利进行，对吗？我不确定这部分。

如果有人可以了解主从复制设置中主键的需求，那就太好了。