标签: master-slave-replication

我有一个主从复制设置，它看起来运行良好。下面是SHOW SLAVE STATUS命令的结果：

show slave STATUS\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: *.*.*.*
                  Master_User: repliV1
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 10726644
               Relay_Log_File: mysqld-relay-bin.000056
                Relay_Log_Pos: 231871
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: data1
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 10726644
              Relay_Log_Space: 232172
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:

我想进一步了解 …

我们一直在维护一个具有网络和移动应用程序平台的项目。该项目的后端使用Django 1.10开发并部署在AWS中。

一开始，当用户很少时，我们使用一个 EC2 实例和一个带有 PostgreSQL 数据库的 RDS 实例进行部署。一段时间后，用户数量增加，我们遇到了响应速度很慢、不同页面超时等问题。由于性能问题，我们采取了以下措施：

• 我们开始使用 Redis 缓存来存储频繁访问的数据（AWS 中的 ElasticCache）
• 我们部署在两个不同的 EC2 实例中（一个用于 Web 平台，另一个用于移动应用程序的 API）。
• 我们在RDS中创建了一个只读副本，并添加了一个数据库路由器，该路由器选择仅使用主数据库进行写入操作，所有读取操作都在只读副本数据库中执行。

该解决方案在短短几周内运行良好。一段时间后，所有读取操作都变得太慢。此时，与主数据库的数据库连接数量平均为 2-3 个，有时会激增至 5-7 个。但由于只读副本数据库中的查询执行速度较慢，30-50 个连接在只读副本数据库中很常见。

使用 JOIN 和聚合的查询经常失败，并在只读副本中出现以下错误：

canceling statement due to conflict with recovery DETAIL: User query might have needed to see row versions that must be removed.

但与主数据库相比，只读副本中的所有查询通常都非常慢，即使是最简单的 SELECT 查询也是如此。

为了确保问题不在于特定的只读副本实例，我们创建了另一个只读副本 RDS 实例（例如 read-replica-2）并将所有读取操作指向 read-replica-2 DB。此配置一开始表现良好，但一天内性能显着下降（对于第一个只读副本，需要 3-4 周）。

之后，我们修改了数据库路由器，以针对任何读取操作随机达到只读副本和只读副本 2 之一的峰值，但对这两个只读副本数据库的所有查询执行速度仍然非常慢。我们通过将读操作切换到master数据库进行检查，相同的读操作在master数据库中执行顺利，没有任何问题。

一些服务器负载相关信息：

• 在高峰时段，有 500-1000 个用户使用该系统，其中大多数来自移动应用程序（通过 API EC2 实例）。
• 在高峰时段，访问Web平台的用户很少。但它们经常执行繁重的数据库密集型任务（例如批量导入和导出数据）。
• 在非高峰时段（当地夜间的 6 小时窗口内），系统中会执行一些繁重的数据库密集型 cron 作业，以进行报告生成和维护。

考虑到这种情况，适合我们的架构应该是什么？我们是否遗漏了一些明显的东西？什么会导致相同的查询在 RDS …

我对数据库还很陌生，所以我希望这不是一个愚蠢的问题！

是否可以在同一台服务器上设置主/从复制？

我知道这在硬件利用/恢复目的方面没有任何优势，但这样的设置将有助于测试我正在开发的软件。

我最近意识到，--master-data当我真正想要的是时，我正在使用从复制从属转储备份--dump-slave。切换到 后--dump-slave，我发现这mysqldump将在备份期间停止从属 SQL 线程（这从文档中可以清楚地看出 - 这并不奇怪）。

我想知道是否有人可以解释为什么整个备份需要停止从属服务器的 SQL 线程？我正在使用--single-transaction，并且希望在备份开始时获得一致的快照。即使事务由 SQL 线程处理，这也应该是可能的。即使从属 SQL 线程由于已mysqldump获取某些锁而完全被阻塞，也应允许从属在备份期间继续（尝试）执行 SQL DML 语句。

我也可以理解希望至少暂停从属 SQL 线程，以便 get-slave-status 然后启动事务操作可以一致地发生，但是一旦转储操作开始，从属 SQL 线程就可以重新启动，对吧？

当--master-data与复制主机一起使用时，全局锁被获取一次然后释放，从而允许常规应用程序负载在转储操作期间继续。为什么不能以同样的方式在从属设备上完成此操作？任何人可以提供的任何信息都会非常有帮助。

我们有一个应用程序，我们每隔几秒接收一次信息，我们将这些信息记录在一个称为事件的表中，该表目前重达 240 GB，这是迄今为止我们拥有的最大的。

前段时间我们删除了记录以保留特定日期的记录。不久前我们发现存储数据库的服务器正在填满磁盘，删除数百万条记录后，磁盘空间保持不变。

在网上搜索我们发现执行以下查询 ALTER TABLE tablename ENGINE = Innodb; 将释放已删除记录的已用空间。

但是我们遇到的问题是，由于我们有大于200G的表，所以该命令执行时间较长，导致新信息因阻塞而无法及时插入。

我们找到的选项如下：

• 制作数据库的副本（主 - 从），从我们在这里看到的情况来看，我们必须对主数据库进行备份并将其传递给从数据库，以便它开始从发生的地方进行复制，为此我们有详细信息是的，我们不想关闭当前的服务器，以便我们的服务保持功能，但我们也不希望丢失任何信息。我们在前一天对服务器进行了备份，我们可以使用它，但是我们如何恢复一天内未插入的信息，如果创建了该备份，那么该备份有什么内容以及从服务器是从哪里配置的？
• 备份我们当前的数据库并将其上传到新服务器，以免使用 ALTER TABLE tablename ENGINE = Innodb 命令，为此我们必须关闭服务器。
• 执行 ALTER TABLE tablename ENGINE = Innodb 命令，我们执行测试，在我们作为测试的 10 GB 表中，执行了大约 25 分钟。

有没有更优化的方法来释放空间，而不必取消我们的服务并且不会丢失信息？或者如果必须在最短的时间内完成？

此查询 ALTER TABLE tablename ENGINE = Innodb 知道它是否锁定表。

生产中的环境信息： Ubuntu Ubuntu 16.04.3 LTS mysql Distribution 10.1.21-MariaDB 所有表的类型均为 Engine = Inodb

非常感谢

我目前有一个 PostgreSQL 从属节点存在问题，但在主节点中不会出现这些问题。似乎与节点同步过程有关。

完整的堆栈跟踪：

org.postgresql.util.PSQLException: ERROR: canceling statement due to conflict with recovery
  Detail: User query might have needed to see row versions that must be removed.
    at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2103)
    at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1836)
    at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:512)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:388)
    at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:273)
    at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:82)
    at org.apache.tomcat.dbcp.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:82)
    at cl.waypoint.mailer.reportes.BasicReport.getSingleColumn(BasicReport.java:542)
    at cl.waypoint.mailer.reportes.BasicReport.getSingleColumn(BasicReport.java:518)
    at cl.waypoint.mailer.reportes.StatusSemanalClientes.updateIgnicion(StatusSemanalClientes.java:448)
    at cl.waypoint.mailer.reportes.StatusSemanalClientes.access$2(StatusSemanalClientes.java:447)
    at cl.waypoint.mailer.reportes.StatusSemanalClientes$TempAndDoorLocator.call(StatusSemanalClientes.java:414)
    at cl.waypoint.mailer.reportes.StatusSemanalClientes$TempAndDoorLocator.call(StatusSemanalClientes.java:1)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
    at java.util.concurrent.FutureTask.run(FutureTask.java:166)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)

数据库版本：

PostgreSQL 9.4.9 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit

操作系统版本：

Distributor ID: …

我有一个 MySQL 8.016 主数据库和一个 MariaDB 10.2 从数据库，它们都在 AWS RDS 上运行。直到今天，这一切都工作得很好，当我想我想做链复制时，就像这样

MySQL 8.016 -> MySQL 8.016 -> MariaDB 10.2

然而，在更改我的 MariaDB 实例上的 master 后，我遇到了可怕的Error 'Character set '#255' is not a compiled character set错误。然后我尝试改回旧的master，但仍然出现此错误！几个月前，当我第一次让我的设置工作时，我遇到了这个问题，第一次，我通过utf8mb4_0900_ai_ci从 MySQL 实例中清除排序规则来解决这个问题，据我所知，它们仍然被清除。

我的 MySQL 8.016 主实例的输出

mysql> SHOW GLOBAL VARIABLES LIKE '%char%';
+--------------------------+-------------------------------------------+
| Variable_name            | Value                                     |
+--------------------------+-------------------------------------------+
| character_set_client     | utf8mb4                                   |
| character_set_connection | utf8mb4                                   |
| character_set_database   | utf8mb4                                   |
| character_set_filesystem | binary                                    |
| character_set_results    | utf8mb4                                   | …

我有一主一奴。假设master的IP改变了，但物理服务器是相同的。现在我想在从服务器上更新（主服务器的）新IP。在从服务器上master_info_repository设置为TABLE。我想从由于 IP 更改而暂停的位置恢复复制过程。这个怎么做？从服务器的 mysql 版本是：14.14 Distrib 5.7.30操作系统是ubuntu 18.04.

我们有一个 PostgreSQL 9.4.9 生产服务器，它正在复制到一个从属实例，但今天我发现该实例不同步！

显而易见的操作是重新创建从属节点，为复制活动设置指标和适当的警报，因此我们可以有效地监控主节点和从属节点之间的同步状态。

但是，由于同步失败，我想首先诊断问题并尝试确定其根本原因，因为这将是大约 6 个月内第二次发生这种情况。

问题：如何诊断复制过程中失败的内容，以便这次可以以更好的方式完成？

版本说明：

PostgreSQL 9.4.9 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 4.9.2-10) 4.9.2, 64-bit

从从节点，在/var/log/postgresql/postgresql-9.4-main.log我可以看到：

2017-07-18 19:43:55 UTC [12816-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1
2017-07-18 19:43:55 UTC [12816-2] FATAL:  could not receive data from WAL stream: ERROR:  requested WAL segment 000000010000125D00000068 has already been removed

2017-07-18 19:44:00 UTC [12817-1] LOG:  started streaming WAL from primary at 125D/68000000 on timeline 1 …

在 MySQL 中，我们在复制过程中使用了 Replication-do-db/replicate-ignore-db，我们可以在其中复制或限制特定数据库从 Master 到 Slave。

以类似的方式，在MongoDB复制中是否有任何特定的配置或解决方法来限制数据同步期间的特定数据库和集合。

如果没有，是否有任何其他方法可以仅将特定数据库或集合从 Master 同步到 Slave。

我正在使用 MongoDB 3.6

我在一台服务器上有数据库和表 collection_city 。它有 21 行。我在第二台服务器上有数据库和表 collection_city 。它也有 21 行。

他们都有这一行：

tinker=# table collection_city;
 id |     name      |    alias     | postal_code | region_id 
----+---------------+--------------+-------------+-----------
  2 | Obrenovac     | obrenovac    |             |         1

id 列是主键。

我在第一台服务器上创建了发布：

CREATE PUBLICATION tinkerpub FOR ALL TABLES;

tinker=# \dRp[+]
                      Publication tinkerpub
  Owner   | All tables | Inserts | Updates | Deletes | Truncates 
----------+------------+---------+---------+---------+-----------
 postgres | t          | t       | t       | t       | t
(1 row)

我在第二台服务器上创建了订阅：

CREATE SUBSCRIPTION tinkersub CONNECTION 'dbname=tinker host=192.168.150.5 user=postgres password=test port=5432' …

我们考虑了一些选项来将我们的 Postgres 服务器从当前 ( 10) 版本升级到最新 ( 14) 版本。我们决定不在主服务器上做任何事情 - 因为我们需要使用链接选项（所以就地，而不是复制），并且如果我们在新的 postgres 服务器启动后看到问题，我们无法回滚。我们认为首先进行复制会更安全。

pg_upgrade因此，我们计划使用复制来进行升级。这是我们到目前为止的计划：

1. 在主和复制之间设置逻辑复制（因此从当前的流式复制更改）
2. 复制完成并且它们同步后，停止复制 postgres 服务器 - 运行 Postgres 10。
3. 执行pg_upgrade复制，然后启动它（逻辑复制将继续）
4. 复制更新后，将复制切换到主复制，并将主复制切换到复制。
5. 现在，所有客户端都将连接到 Postgres 14 上的复制
6. 对新的复制\旧的主数据库执行相同的步骤（停止、pg_upgrade、启动，最后再次切换回来）

在继续之前我有一些问题：

1. 是否可以从升级前的机制转移streaming replication到logical replication升级前的机制？在这样做之前有什么需要考虑的吗？
2. 我们正在考虑即使在升级后也保持复制机制的逻辑性。这是可取的吗？
3. 该操作预计需要多长时间才能pg_upgrade完成？我知道这取决于各种参数，但是根据数据大小约为 600 GB 的事实进行粗略估计吗？由于这是复制所需的停机时间 - 所以没有备份。
4. 这是一个好的策略吗？还是有更好的（安全、停机时间最短）选择？

在继续升级之前，请寻求有关这些问题的一些指导。