从 SQL Server 到 MySQL(三):愚公移山 - 开源力量

201806/refactor.png

我们用了两章文章 从 SQL Server 到 MySQL(一):异构数据库迁移 / 从 SQL Server 到 MySQL(二):在线迁移,空中换发动机 介绍我们遇到问题和解决方案。 不管是离线全量迁移还是在线无缝迁移, 核心 ETL 工具就是 yugong。

Yugong 是一个成熟工具, 在阿里巴巴去 IOE 行动中起了重要作用, 它与 Otter / Canal 都是阿里中间件团队出品。 它们三者各有分工: Yugong 设计目标是异构数据库迁移; Canal 设计用来解决 MySQL binlog 订阅和消费问题; Otter 则是在 Canal 之上,以准实时标准解决数据库同步问题。 Otter 配备了相对 yugong 更健壮管理工具、分布式协调工具, 从而长期稳定运行。Yugong 设计目标则是一次性迁移工作,偏 Job 类型。 当然 yugong 本身质量不错,长期运行也没问题。 我们有个产线小伙伴使用我们魔改后 yugong, 用来将数据从管理平台同步数据到用户前台,已经稳定跑了半年多了。

more ...

从 SQL Server 到 MySQL(二):在线迁移,空中换发动机

flying-tanker

(image via https://pixabay.com/en/military-stealth-bomber-refueling-602729/ )

在上篇文章 从 SQL Server 到 MySQL (一):异构数据库迁移 - Log4D 中,我们给大家介绍了从 SQL Server 到 MySQL 异构数据库迁移的基本问题和全量解决方案。 全量方案可以满足一部分场景的需求,但是这个方案仍然是有缺陷的: 迁移过程中需要停机,停机的时长和数据量相关。 对于核心业务来说,停机就意味着损失。 比如用户中心的服务,以它的数据量来使用全量方案,会导致迁移过程中停机若干个小时。 而一旦用户中心停止服务,几乎所有依赖于这个中央服务的系统都会停摆。

能不能做到无缝的在线迁移呢?系统不需要或者只需要极短暂的停机? 作为有追求的技术人,我们一定要想办法解决上面的问题。

more ...


从 SQL Server 到 MySQL(一):异构数据库迁移

201803/migration-bird.png

背景

沪江成立于 2001 年,作为较早期的教育学习网站, 当时技术选型范围并不大: Java 的版本是 1.2,C# 尚未诞生,MySQL 还没有被 Sun 收购, 版本号是 3.23。 工程师们选择了当时最合适的微软体系,并在日后的岁月里, 逐步从 ASP 过度到 .net,数据库也跟随 SQL Server 进行版本升级。

十几年过去了,技术社区已经发生了天翻地覆的变化。 沪江的技术栈还基本在 .net 体系上,这给业务持续发展带来了一些限制。 人才招聘、社区生态、架构优化、成本风险方面都面临挑战。 集团经过慎重考虑,发起了大规模的去 Windows 化项目。 这其中包含两个重点子项目:开发语言从 C# 迁移到 Java, 数据库从 SQL Server 迁移到 MySQL。

本系列文章就是向大家介绍, 从 SQL Server 迁移到 MySQL 所面临的问题和我们的解决方案。

more ...

从 2017 到 2018

2017 年 2 月摄于瑞虹月亮湾

(2017 年 2 月摄于瑞虹月亮湾)

我有两年没公开年终总结了,原因很简单:年终结果无法让自己满意, 生活持续呈线性发展。那今年为什么又要将总结发出来呢? 并非是我的 2017 过得如何充实、有成就感,而是出于两个目的。 第一是我认识到 OKR 需要平和对待,我目前对自己的生活是缺乏完全掌控力的, 我无法既渴求爆炸性的增长,又期望在这一过程中低风险,我需要接受这种现状。 第二是曝光自己的目标,让回顾和计划透明化。 从社会心理学的角度上来看,公开的承诺有助于个体更努力地驱动目标的完成。

more ...

工作和热情

201712/work.jpg

最近和一位老朋友吃饭,他说他最近比较苦恼: 「开始有职业危机了,担心自己失去对工作的热情,似乎离油腻的中年人又进了一步」。 作为一名互联网工程师,我深知这个行业技术日新月异, 如果对工作都失去了兴趣,会将自己置于跟不上时代发展、自身得不到提升的危险境地; 从个人生活质量来看,工作占据了一天 1/3 ~ 2/3 的时间, 失去热情的工作会成为人生的桎梏,不是驾驭工作,而是被工作所奴役, 这会进而影响一个人的身心健康,得个抑郁症稀疏平常。

如何保持对工作的热情,当自己陷入困境时候如何重新调动工作热情? 这是职场人需要深思的问题。

more ...

服务性能监控:USE 方法(The USE Method)

本文首发在沪江技术学院公众号,小莞翻译,我做了校对。 由于微信公众号的封闭性,我担心未来文章不容易被发现。 为了避免沧海遗珠,特意转到这里。

英文原文:The USE Method


201711/performance.jpg

USE 方法是一种能分析任何系统性能的方法论。 我们可以根据能帮助系统分析的结构化清单,来迅速的定位资源的瓶颈和错误所在。 它通常会先以列出问题为开始,然后再寻找适合的指标,而不是给你制定一些固定的指标, 然后让你按部就班的执行下去。

more ...

Stack Overflow 的 HTTPS 化:漫漫长路的终点

Stack Overflow


今天,我们默认在 Stack Overflow 上部署了 HTTPS。目前所有的流量都将跳转到 https:// 上。与此同时,Google 链接也会在接下去的几周内更改。启用的过程本身只是举手之劳,但在此之前我们却花了好几年的时间。到目前为止,HTTPS 在我们所有的 Q&A 网站上都默认启用了。

在过去的两个月里,我们在 Stack Exchange 全网维持发布 HTTPS。Stack Overflow 是最后,也是迄今最大的的一个站点。这对我们来说是一个巨大里程碑,但决不意味着是终点。后文会提到,我们仍有很多需要做的事情。但现在我们总算能看得见终点了,耶!

友情提示:这篇文章讲述的是一个漫长的旅程。非常漫长。你可能已经注意到你的滚动条现在非常小。我们遇到的问题并不是只在 Stack Exchange/Overflow 才有,但这些问题的组合还挺罕见。我在文章中会讲到我们的一些尝试、折腾、错误、成功,也会包括一些开源项目——希望这些细节对你们有所帮助。由于它们的关系错综复杂,我难以用时间顺序来组织这篇文章,所以我会将文章拆解成架构、应用层、错误等几个主题。

more ...

一个关于 nolock 的故事:深入理解数据库隔离级别

sql-server.png

加入沪江不久,我就被扔到一个将集团 SQL Sever 的数据库迁移到 MySQL 的项目里, 同时伴随进行的还有 .net 系统迁移到 Java 系统。 在这个过程中我发现了一个很有趣的现象:历史遗留的 .net 项目中, 几乎所有的 SQL 中都会使用一个关键字:nolock。 这让我很困惑,nolock 的字面意思是对当前技术不使用锁技术,为什么要这样用呢?

more ...

当我们在聊监控,我们在聊什么?

最近在团队中给大家做了一个分享,泛泛地聊了一些有关「监控」的话题。 其实做分享对分享者的作用往往大于参与者。 这是一次将自己知识的梳理的过程,于是我将这次分享整理成这篇文章。

201706/stock-exchange.png

more ...