@vczyh #29
挂了就不用了啊 你的程序都不是分布式的 就没必要上这个

你没发现他们这个设计图都没给你做交叉吗

或者换句话说 router 是不应该挂的 只有 app 能挂

这也是我遇到的问题 这个 router 高负载下是真的不稳

@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]

@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 莫名其妙进入一个随机的故障状态

@inza9hi #9
固定带宽阿里给你几折？

@locoz #16
跟灰黑产关系不大
公司这个实体，你税务失联三个月，基本这个公司资质就趋近失效了。
满大街欠债的人一躲几十年，身份也不能失效。

需要公司资质，只是为了找得到人来负责，其实跟灰黑产的关系不大。
灰黑产都不差钱，公司壳子有都是，要不就搞更邪门的套路。

@Hozoy #13
谁告诉你个体户不开票可以不进行税务登记的？

我就一个问题
我的显示器是个投影仪 请 OP 帮我实现这个尺子

@hetal #12
大概是我们的 mysql 负载太重的原因 轻负载可能无法复现

@vczyh #11
你不使用 router 那就不要用这个 cluster 直接回归原始主从

另外看我问#12 的 因为用这玩意生产的企业真的不多 我们的 mysql 集群是充分设计利用效能的，负载非常重，并发很高，数据量也非常大，但是不会搞死数据库引擎

可能只有到很重负载的 很高并发的规模才会 router 不稳定
这个仅供参考

@hetal #5
你们 router 自己改造没 router 的可靠性如何
其他都好 就 router 的坑我们踩了几百次了
现在甚至已经整了一帮人研究 router 结构 自己重写一个 router

@vczyh #8
router 可靠性比较差
经常自己就无了
而且 router 默认生成器是 init.d 启动 不会自己重启 不知道什么草台班子写的 甚至不是 systemd

router 得日志功能形同虚设 崩了 死了 都不会写日志
有时候进程正常 内存也没泄露 对外服务就不好使了 然后自身还正常上报自己正常

反正这个 router 的可靠性和逻辑 像是大专生课程作业

从 8.3 到现在 一直这样 版本我们一直滚动升级 问题常态存在

不用 innodb cluster 的话 没必要上 lts
用 innodb cluster 的话 router 坑不少 但是都能解决

@freaks #21
所以 其实是火狐不安全

@fawkes233 #36
没啥啦
其实是我个人对现实世界 how it works 比较感兴趣
发现了新东西 正好就顺势问问 补充一下自己的知识库

做个商城，投给谁需要微信支付 1 块钱买谁的名字商品，计票结束后退款退还。

世界加钱可及

昨天就看到了 因为有渠道问了下创维的人

他们也辗转问了一下给了我一个准信

我们是尊贵的甲方，所以他们的人比较尽心尽责给辗转跨部门跨业务问了详细情况

------------------
这个没啥坑，基本就是字面意义的，比较稳，厂商是创维集团的下属，落地公司是当地国资委的公司

给的建议是：
农村地区，不建议个人一户安装
如果你们村有十几个人都安装了 组团安没啥毛病 至少政策不大改下 不会有坑
整个链上就那个落地公司有一定民资（都是关系户，白手套）
而且，浙江当地国资很重视光伏诈骗问题，合同条款上基本写的都比较白话方便农民理解


唯一的可能的坑是

假如国家上层政策有变，导致七八年后政策问题付不出钱来，不要自作主张小孩子斗气似的 你们不给钱 我就擅自拆除光伏板，这样没准会触发你们先违约导致扯皮上法院，更不要随便丢弃或者卖了。其他基本没啥坑。至少要抗几年他们没付钱然后整个比较正式的告知书最后通牒然后再干