windows vs
linux vscode

我是前面加了个数字 1-5 轮流来

默认链接先是动态库 然后是静态库
假如需要链接静态库 显式的写-l xxx/libcurl_7_26.a 试试

golang 都是值复制 没有引用

看你干什么的了 go 和 c++的学习成本完全不是一个等级的 假设你有操作底层的需求 或者写各种计算密集型应用 那 c++还是很强大的

不错的东西 本来 19 年打算做这个的 思路也差不多

mfc/qt/duilib

抽 maria 的 binlog 然后在 pg 里执行

开源的就是阿里的 otter 了 还有阿里运维团队的 drc，不过这个貌似不开源
其余开源的很少，基本都是公司基于业务自研的
因为涉及到数据一致性，必须在业务端做单元化才行，底层和应用层都要改造，不是那么简单的

我就在做这个 自研了一套同步系统 基于 binlog 的主主同步

我周围基本都是其它语言转 go 的 我们组主要是 c++ 用 go 的话 基本看半天就能上手写代码了
主要是 c++开发速度太慢 基本除了性能和内存要求很高的核心用 c++ 其余的服务都改用 go 了

然后我们所在的大部门，基本都从各种语言转到了 go，java php c#的都有，但是直接招主要语言是 go 的人貌似还没遇到过

goland 太臃肿了 不太喜欢
基本只用 vscode，只是配置比较麻烦，所以自己写了个小工具自动生成项目，直接把文件夹拉进去直接写

表空间文件刚创建的时候 初始大小是 96KB 一共有 6 页
page 0 是 file space header，用户管理 extend 信息，一共可以管理 512 个 extend(512M)，假设多了，那么会在后续多一个 extend descriptor
page 1 是 insert buffer bitmap
page 2 是 file segment inode，用于管理 segment 的
剩下 3 页都是空闲页

当创建表并添加一条记录的时候，page 3 会作为 leaf node 存储数据，此时会占用 2 个 inode （假设只有 1 个 primary key 和作为索引），一个用于记录 leaf 的 extend 信息，一个用于记录 non-leaf 的 extend 信息，在这里该 page 既是 leaf 也是 non-leaf。

在从 segment 分配 page 的时候，首先会去空闲页中寻找可用的空闲页，存入 inode 的尺寸为 32 的碎片页数组，当该数组满的时候，会单独分配 1 个 extend。

所以这本书上说的 32 个页的碎片页，不是指实际分配的碎片页，指的是当一个新表创建后，首先分配的是碎片页，当分配了 32 个碎片页之后，才会分配单独的完整的 extend，当然该 extend 会被记录到 inode 中。

@willychester 的确有中间件做这个 我负责的这块就是做这个的 基本思路就是伪装成从节点从 A 节点拉数据，根据 A 的表结构来生成 sql 语句，然后执行。

现成的工具的话，可以试试 tidb 自带的 syncer，应该满足你的使用场景。

我也是电气毕业的
那时候大三就有这个想法了 所以从大三开始 所有的业余时间都在自学
专业课程学了 c 和汇编
业余自学了 c++
现在一晃都当程序员 6 年了
有 c 语言基础 转行坚持下还是可以的

@moonjoin 木有 3w+的价格

c++出身 现在 c++和 go 都做
我们组主要是高性能的中间件会使用 c++写
目前的项目 分布式计算 计算和存储使用 c++ 其余的都用 go
c++开发周期太长 基础架构这儿使用的会比较多
但是从 c/c++学起来的，往往基础都会比较好