准备做新版本
› MySQL 5.5 Community Server
› MySQL 5.6 Community Server
› Percona Configuration Wizard
› XtraBackup 搭建主从复制
Great Sites on MySQL
› Percona
› MySQL Performance Blog
› Severalnines
推荐管理工具
› Sequel Pro
› phpMyAdmin
推荐书目
› MySQL Cookbook
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
This topic created in 644 days ago, the information mentioned may be changed or developed.
 |
1
netnr Dec 24, 2024
MySQL 8.0/8.4 执行 DDL 会丢数据？是，但影响有限
https://mp.weixin.qq.com/s/RwAzDdicYWl1cdDq-I0Jsg |
 |
2
pigeon2049 Dec 24, 2024
用就不要怕
9.1.0 直接冲 哪里报错改哪里 |
 |
3
realpg Dec 24, 2024
不用 innodb cluster 的话 没必要上 lts
用 innodb cluster 的话 router 坑不少 但是都能解决 |
 |
4
qW7bo2FbzbC0 Dec 24, 2024  3
8.4 版本 master/slave 关键词因为政治正确，改成了 primary/replica 了吧，之前工具可能都不适配，可以从 8.0 开始用，慢慢等生态工具支持新关键词
|
 |
5
hetal Dec 24, 2024
我们公司就用的 8.4 的 innodb cluster+mysql router ，另外还是用的 docker+swarm 运行的~~~
|
 |
6
flyqie Dec 24, 2024 via Android
|
 |
7
vczyh OP @pigeon2049 牛逼
|
|
9
realpg Dec 25, 2024
@vczyh #8
router 可靠性比较差 经常自己就无了 而且 router 默认生成器是 init.d 启动 不会自己重启 不知道什么草台班子写的 甚至不是 systemd router 得日志功能形同虚设 崩了 死了 都不会写日志 有时候进程正常 内存也没泄露 对外服务就不好使了 然后自身还正常上报自己正常 反正这个 router 的可靠性和逻辑 像是大专生课程作业 从 8.3 到现在 一直这样 版本我们一直滚动升级 问题常态存在 |
|
10
realpg Dec 25, 2024
@hetal #5
你们 router 自己改造没 router 的可靠性如何 其他都好 就 router 的坑我们踩了几百次了 现在甚至已经整了一帮人研究 router 结构 自己重写一个 router |
|
11
vczyh OP |
|
13
hetal Dec 25, 2024
@vczyh 我们在正式使用前做了很多压力测试，主要实测如下：
1. Docker 的版本会比普通版本 qps 少 10%左右 2. MGR 比普通单台性能平均少 30%左右，写入和读取平均一下 好处是： 1. 解决了单点故障问题，高可用性 2. 扩容、迁移、升级更简单了 |
|
14
realpg Dec 25, 2024
|
 |
17
datafeng Dec 26, 2024
@qW7bo2FbzbC0 当年是哪群傻 B 提出 master 改 main 的？就为了这么个东西浪费多少的资源。
|
 |
18
kapr1k0rn Dec 26, 2024
我帮客户在 k8s 上用官方 mgr operator 部署的集群，跑了一年了目前没什么问题。不过要让我再选，一律不建议 mysql 集群，遇到问题明明官方文档有解决方案但是因为没有买 oracler 服务还看不了，太恶心人了。
router 确实坑多，最好不要用，我是换成 proxysql 了。 |
|
19
vczyh OP |
|
22
realpg Dec 26, 2024
@vczyh #19
router 前面为啥要挂 lb 啊 router 是跟 client 绑定的末端设施 他自身是分配的 @hetal #15 无任何日志 它自己根本不输出任何东西 router 的日志是我二十多年运维生涯见过的最干净的日志 跟没有日志没啥区别 包括但不仅限于 自己就 exit 了 日志里啥也没有 还有它跟 cluster 的通讯一切正常 keepalive 什么都正常发 然后对下面的应用就不提供服务了 还有它提供服务 socket 正常 tcp 就 connection refused 以及反过来 当然我们自己在 router 以外做了一些东西去解决这个事情 暂时影响不大了 ---------- router 的版本，我们最开始跑这个集群时候 是 8.3 那时候第一个 lts 还没发布 我们每一个小版本都跟着滚动更新 现在是 8.4 lts 最新 lts 更新我们延迟两周就跟着滚动更新 这些问题在任何版本都是一样的发生 其实看了他们 router 代码 这玩意压根也没怎么更新过多少代码 我们现在从 router 以外的 app 侧做了很多处理 同时对 router 外挂了检测机制 基本 2 秒内解决 router 的故障 目前 router 的抽风频率大概是一个 6 个 backend 6 个 router 的系统 每 55 小时左右 大概就会有一只 router 莫名其妙进入一个随机的故障状态 |
|
25
hetal Dec 26, 2024
我们生产是 8.4.2 ，测试环境是 8.4.3
|
|
28
realpg Dec 26, 2024
@vczyh #27
额。你看看文档吧，你没理解 innodb cluster 的架构。 @hetal #26 随便找一个 256G 内存 3TB 左右存储空间 每日高峰综合负载 40%左右 日产生新行数约千万 删除也差不多这么多 写占比 78% 90%字段整数类型 索引充分 非 DDL 慢查询阈值 1 秒 [DEFAULT] name=system user=mysqlrouter keyring_path=/var/lib/mysqlrouter/keyring-39-1 master_key_path=/etc/mysqlrouter/mysqlrouter-39-1.key connect_timeout=3 read_timeout=45 dynamic_state=/var/lib/mysqlrouter/state-39-1.json client_ssl_cert=/var/lib/mysqlrouter/router-cert-39-1.pem client_ssl_key=/var/lib/mysqlrouter/router-key-39-1.pem client_ssl_mode=PREFERRED server_ssl_mode=PREFERRED server_ssl_verify=DISABLED unknown_config_option=error max_idle_server_connections=240 router_require_enforce=1 [logger] level=INFO [metadata_cache:bootstrap] cluster_type=gr router_id=44 user=node-router-main-39-1 metadata_cluster=HB2DB39 ttl=0.5 auth_cache_ttl=-1 auth_cache_refresh_interval=2 use_gr_notifications=0 [routing:bootstrap_rw] bind_address=127.0.0.1 bind_port=6446 socket=/run/mysqlrouter/mysql-39-1-main.sock destinations=metadata-cache://HB2DB39/?role=PRIMARY routing_strategy=first-available protocol=classic [routing:bootstrap_ro] bind_address=127.0.0.1 bind_port=6447 socket=/run/mysqlrouter/mysql-39-1-ro.sock destinations=metadata-cache://HB2DB39/?role=SECONDARY routing_strategy=round-robin-with-fallback protocol=classic [http_server] [rest_api] |
|
29
vczyh OP |
|
30
realpg Dec 26, 2024
@vczyh #29
挂了就不用了啊 你的程序都不是分布式的 就没必要上这个 你没发现他们这个设计图都没给你做交叉吗 或者换句话说 router 是不应该挂的 只有 app 能挂 这也是我遇到的问题 这个 router 高负载下是真的不稳 |
|
31
vczyh OP @realpg
这个和应用程序是否是分布式没关系，mysql 高可用就是要求每个组件有一定的容错能力，比如 master 挂了，slave 后变成新主，多个 router 只要有一个没挂就能继续为应该程序提供服务。 如果 router 挂了应用程序就不可用的话，为什么要用 MGR ，我用单节点不行吗，不会只是为了多一份数据备份吧。 |
|
32
vczyh OP @realpg
正如你说的 router 确实不应该挂，部署多个 router 并且配合 keepalived 可以实现高可用。 https://medium.com/@makhshif.tanvir/configuring-mysql-router-and-keepalived-for-high-availability-in-a-mysql-cluster-3589e40d5dd6 |
|
33
hetal Dec 26, 2024
@realpg 我没有配置[routing:xx]，让其内部操作，可以禁用连接池试式
[DEFAULT] max_idle_server_connections=0 router_require_enforce=0 [metadata_cache] use_gr_notifications=1 |
|
34
hetal Dec 26, 2024
@vczyh 我们是用的 docker swarm ，启动的多个 mysql router replicas ，只启用了 use-gr-notifications 这个参数，其它都是默认参数，比较稳定
|
|
36
hetal Dec 26, 2024
目前看官方的 changelog ，连接池和读写分离的 bug 比较多，我们这 2 个都没有使用，应用端根据端口来区分的；
https://dev.mysql.com/doc/relnotes/mysql-router/8.4/en/news-8-4-3.html |
|
37
realpg Dec 27, 2024
@hetal #36
内部操作？ 你不指定，默认就所有读写操作都在 PRIMARY 上面 除非你指定 SPLIT 的入口 我们现在不考虑副本 最小的集群上是 1 个 PRIMARY4 个 SENCONARY ，最多的 1 个 PRIMARY 三十多个 SENCODARY 才能扛得住请求数 都扔给 PRIMARY 启动后 100 毫秒整个集群就死了 |
|
38
realpg Dec 27, 2024
@vczyh #32
额 别把野鸡攻略当回事吧 你要是认定一种做法 什么地方都找得到跟你想法一样的人 @hetal #36 补充一下 我用的根本不是你给的 changlog 里说的 Read-Write splitting 那玩意指的是 [routing:bootstrap_rw_split] destinations=metadata-cache://HB2DB161/?role=PRIMARY_AND_SECONDARY 而我用的只是指定连接 PRIMARY 还是 SENCODARY 因为 INNODB CLUSTER 是不保证一致性的，甚至可以说，高负载下他是一定不一致的。 冷数据才可以连 SENCODARY 而且 spilit 这玩意纯属娱乐功能 源代码写的一坨屎 ---- 从 8.3.0 到 8.4.4 router 基本就没修复过任何正经的 bug 我公司有 oracle 的商业支持(mysql) 不过是比较便宜的 已经不再续了 他们商业支持认为我们反馈的问题是在骗他们 是在 joking 然后就不管了 他们认为 router 能自己 exit 还没有日志是我们在骗他 他们给我们这个问题定的结论是： 我们没管理好服务器 被人登上去手动 service mysqlrouter stop 了 |
|
39
hetal Dec 27, 2024
@realpg 多看看文档吧
By default, generated bind_port values are as follows: For the classic protocol, Read-Write uses 6446 and Read-Only uses 6447, and for the X protocol Read-Write uses 6448 and Read-Only uses 6449. https://dev.mysql.com/doc/mysql-router/8.0/en/mysqlrouter.html |
Select Language