通俗点介绍Github是什么?
发布网友
发布时间：2022-04-25 01:09
共3个回答
懂视网
时间：2022-04-15 16:24
基于这三点总结就抛出了三个问题：
1. 现有的HA软件是否可靠，可信？是否在正确的时候做了正确的判断和操作？
2. 没有集中管理机的HA架构（即内部投票）是否可靠？
3. HA的Failover过程是否要考虑数据预热？
以下是对于这三个问题的一些分析和个人看法：
问题一：现有的HA软件是否可靠，可信？是否在正确的时候做了正确的判断和操作？
GitHub团队认为：The automated failover of our main production database could be described as the root cause of both of these downtime events.
而对于这个问题，我的想法和 Xaprd的观点 一致：事故的关键在于现有的HA软件都没法照顾到所有可能发生的情况，以至于在某些情况下的行为是不可预测的，或者非我们所想的。
因此一味的将切换操作置成手工模式，虽然避免了风险，但显然没有很好的使用HA软件所提供的service。
个人想法是，对于一些原因明确且有明确cookbook的事故，可以让HA去完成failover。而对于那些需要人工介入分析故障原因的事故，做手工切换，如果github遇到的timeout等。
问题二： 没有集中管理机的HA架构（即内部投票）是否可靠？
从目前的流行程度来看，MMM，MHA这些使用Manager管理模式的架构，已经逐渐替代 Heartbeat + LVS/ Pacemaker 等投票模式的架构。
其主要原因就是在没有仲裁机的情况下，发生网络partition会造成脑裂，从而导致active角色的互相争抢，最后使整个cluster瘫痪。
Github再次用血的教训告诉我们脑裂是无仲裁架构的致命缺陷。
问题三：HA的Failover过程是否要考虑数据预热？
这个问题显然是引起本次问题的关键：没有预热的切换才是万恶之源。脑裂只是连锁反应而已。
而貌似整个社区的blog中对于这个问题的讨论却是少之又少，也许是重视程度不够？
会造成切换后压力剧增可能的情况，我总结为以下三种：
1. stand-by-master完全作为冗余，BufferPool 基本没有热点数据
2. stand-by-master提供read-only服务，但read-only 和 acitve master 的请求业务类型不同，导致热点数据不同
3. 原本active的MySQL宕机后重新回归，此时重启后的MySQL是处于完全Cold 状态
但目前众多HA软件中都没有考虑预热的因素，毕竟所有的failover都希望尽快的将业务转移至stand-by master，而预热则需要尽可能多的时间来获取业务的请求。
也许这是一个无解命题？
bitsCN.com
热心网友
时间：2022-04-15 13:32
是一个分布式的版本控制系统，比如，你在开发一个程序时，需要多个人同时进行开发，但是如果多个人同时开发一个文件，可能会有覆盖的情况，但是用git或svn就会不出现这种问题。
GitHub可以托管各种git库，并提供一个web界面，但它与外国的SourceForge、Google Code或中国的coding的服务不同，GitHub的独特卖点在于从另外一个项目进行分支的简易性。
为一个项目贡献代码非常简单：首先点击项目站点的“fork”的按钮，然后将代码检出并将修改加入到刚才分出的代码库中，最后通过内建的“pull request”机制向项目负责人申请代码合并。已经有人将GitHub称为代码玩家的MySpace。
基本功能：
作为开源代码库以及版本控制系统，Github拥有超过900万开发者用户。随着越来越多的应用程序转移到了云上，Github已经成为了管理软件开发以及发现已有代码的首选方法。
如前所述，作为一个分布式的版本控制系统，在Git中并不存在主库这样的概念，每一份复制出的库都可以独立使用，任何两个库之间的不一致之处都可以进行合并。
热心网友
时间：2022-04-15 14:50
Git 是一个分布版本控制系统。版本控制系统可以保留一个文件集合的历史记录，并能回滚文件集合到另一个状态（历史记录状态）。另一个状态可以是不同的文件，也可以是不同的文件内容。在一个分布版本控制系统中，每个人都有一份完整的源代码（包括源代码所有的历史记录信息），而且可以对这个本地的数据进行操作。分布版本控制系统不需要一个集中式的代码仓库。
