mysql主从同步, 谁搞过, 昨天搞到晚上11点多, 卧槽
本帖最后由 largecat 于 2024-12-28 12:31 编辑主库在A那里, 我看不到, 无法控制,
他的数据要同步给我.
目前replicate都配置到位, 记录可以正常同步过来, 但是他那边增加一个表列, 等结构上的变动, 就没法同步过来, 也不报错.
目前已知:
为了避免问题都采用的MYSQL 8.4.3版本
对方是在Microsoft Azure上部署的MYSQL, 用的 binlog_format=Row, 并且他说他还没法改这个参数. (我不解)
我这边的从库是云下MYSQL, 我单独的VM机, 自己安装的MYSQL, 有完整的控制权, 只是单纯的同步, 不做任何其他事, 这个库以后也只是同步拿数据, 我这边不会额外对这个库进行任何增删改的动作.
谁碰到过类似的问题. :lol:没搞过 帮不了你实在搞不定
让他给你开个远程读的账号权限得了 你遇到的这种主从库结构变动不同步的情况比较常见，原因和解决办法如下：
问题原因
binlog 格式限制：对方使用 binlog_format = Row，这种格式下，MySQL 只会记录数据行的变更，而非完整的 SQL 语句。当表结构发生变化，例如新增列时，从库没办法从行变更日志里解析出表结构的修改信息，所以不会同步这类变更。
权限与配置冲突：虽然你这边复制链路（replicate）配置好了基础的记录同步，但结构变动同步往往需要额外的权限或更精细的配置。有可能对方 Azure 环境的一些默认设置、安全策略，限制了结构变更向从库传递的相关操作 。
解决办法
手动同步表结构：最简单直接的办法，每次得知对方新增表列或者有结构变动时，手动在你这边的从库执行对应的 ALTER TABLE 语句，保持两边结构一致。不过这依赖人工监控，容易出错且效率低。
利用 pt-online-schema-change：这是 Percona Toolkit 里的一个工具。即使无法修改对方的 binlog_format，你可以在自己的从库这一侧，用这个工具间接达成类似效果。安装好 Percona Toolkit 后，运行类似如下命令：
bash
pt-online-schema-change --alter "ADD COLUMN new_column VARCHAR(255)" D=your_database,t=your_table --execute
它会在不锁表的情况下，安全地更改表结构，后续同步的数据也能适配新的结构。
3. 和 Azure 运维沟通权限：尝试跟 Azure 平台的运维人员或者负责该 MySQL 实例的团队进一步沟通，解释同步结构变动的必要性，看能否调整部分权限，或者在 Azure 端设置一些触发器、事件，当有表结构变动时，给你这边发送通知，方便及时手动干预 。
4. 检查复制过滤规则：仔细查看两边数据库的复制过滤设置，也许存在某些过滤条件，不经意间把表结构变动的同步过滤掉了。确认 replicate-wild-ignore-table、replicate-wild-do-table 这些参数的设置，保证相关表结构变更不在过滤范围内。 你的问题描述表明，主库在结构（例如添加新列）上发生变动时，同步无法处理这些变动，但数据同步正常。这种情况可能是由于 MySQL 的复制机制 和 表结构同步方式 有限制造成的。
以下是分析与解决方案：
1. 原因分析
1.1 binlog_format=ROW 的影响
binlog_format=ROW 的优势是只记录实际行数据变更，而不是 SQL 语句或表结构相关信息。
但是，表结构的变更（如 ALTER TABLE）不会被同步到从库，因为 ROW 格式的 binlog 不记录结构性变化。
1.2 Azure MySQL 的限制
Azure 上的 MySQL 服务通常会限制某些参数的更改，比如 binlog_format，并且无法通过管理员权限调整。
这是为了确保多租户环境下的安全性与稳定性。
1.3 从库同步机制
从库的 replicate-do-db 或 replicate-do-table 规则通常用于选择性同步表或库的变动，但它们不会处理主库的表结构变化。
如果从库没有手动调整表结构，结构差异会导致同步中断或数据无法正常写入。
2. 解决方案
2.1 手动同步表结构
每当主库发生结构变更（如添加列、修改数据类型），需要在从库手动执行相同的结构变更语句。
定期与主库管理员沟通，获取表结构的变化信息。
例如，主库执行：
sql
复制代码
ALTER TABLE your_table ADD COLUMN new_column VARCHAR(255);
则需要在从库上执行相同语句。
2.2 自动检测结构变化
使用工具自动化检测主库和从库之间的表结构差异，及时调整从库：
工具推荐：
pt-table-sync：Percona Toolkit 中的一个工具，用于表结构和数据的同步。
自定义脚本（Python 或 Shell）：定期比较主从库的 information_schema 中的表结构，发现差异后生成 ALTER TABLE 语句。
2.3 使用触发器同步结构变化
如果有主库的 SQL 执行权限，可以在主库通过触发器记录 DDL 操作（表结构变更），然后将这些操作通过其他渠道传递到从库执行。
注意：这种方式需要额外的开发工作，可能引入复杂性。
2.4 考虑切换到 binlog_format=MIXED
理论上，MIXED 格式的 binlog 会在 DDL 操作时记录 SQL 语句，有助于从库同步结构变化。
但是由于 Azure MySQL 无法更改 binlog_format，此方法仅供参考。
2.5 主动备份并恢复结构
如果表结构变更频繁，可以定期对主库表结构进行全量导出，并覆盖从库表结构：
从主库导出表结构：
bash
复制代码
mysqldump -h 主库地址 -u 用户名 -p --no-data 数据库名 > structure.sql
在从库上执行导出的结构文件：
bash
复制代码
mysql -h 从库地址 -u 用户名 -p 数据库名 < structure.sql
2.6 考虑使用更高级的同步工具
如果预算允许，考虑使用 企业级同步工具，它们通常支持主从表结构的动态同步，例如：
MySQL Enterprise Edition 的复制功能
第三方工具如 Debezium 或 MaxScale，它们支持结构和数据的实时同步。
3. 优化步骤建议
确认需求：明确主库表结构变动的频率。如果变动较少，手动调整结构可能是最简便的。
搭建检测机制：构建主从库 information_schema 的定期对比脚本，及时发现差异。
备份与测试：任何涉及表结构调整的操作，务必在从库备份后测试，确保不影响数据同步。
文档化流程：制定操作流程（表结构变更的通知机制、调整步骤等），提高协作效率。 几年前urlos流行的时候有看过相关文章，好像是读写分离 问题解决了。
配置都没问题。
问题出在对方的低代码平台上了，坑人 mark了。 syxxz 发表于 2025-1-3 00:39
mark了。
不用mark, 上面AI回答的统统都是错误的。
Row模式是可以的 光做主从，不定时打包一份完整的么
页:
[1]