master

Please help to make Head point to master in git I tried to git rebase HEAD master and git checkout master Nothing of those helps. Updated: Strange I tried: git symbolic-ref HEAD refs/heads/master then git rev-parse refs/heads/master fc550e5ff2fe49d64ee1d8bf0da09b2b24bf2cd7 and then I got strange warning after the following command git rev-parse HEAD warning: refname 'HEAD' is ambiguous. fc550e5ff2fe49d64ee1d8bf0da09b2b24bf2cd7 New Update: There was HEAD branch in remotes -> origin . After removing it everything is ok. I do not have that warning anymore. VonC IF you don't have any local work in

第91课：SparkStreaming基于Kafka Direct案例实战和内幕源码解密 /* * *王家林老师授课 http://weibo.com/ilovepains */ 每天晚上20：00YY频道现场授课频道68917580 1、作业内容：SparkStreaming基于Kafka Direct方式实现，把Kafka Direct理解成为像hdfs的数据源，SparkStreaming直接读取数据进行流处理。 2、之前的spark集群环境： spark 1.6.0 kafka_2.10-0.9.0.1 3、java开发SparkStreamingDirected，读取topic SparkStreamingDirected中的数据。 4、kafka中创建topic SparkStreamingDirected161，生产者输入数据。 5、将SparkStreamingDirected 在ecliplse中export打成jar包，提交spark运行，准备从kafka中读取数据。 6、结果spark submit运行中报java.lang.ClassNotFoundException,踩坑记录 ： -com.dt.spark.SparkApps.SparkStreaming.SparkStreamingOnKafkaDirected

git基本文章，随手一记 【命令】 $ git init　　---初始化（在当前目录下创建.git目录，同时当前目录成为一个Git仓库） $ git status　　---查看当前状态 / 查看有何改动 $ git add .　　---添加需要追踪的新文件和待提交的更改 $ git commit -m '提交的备注（reMark）'　　---将暂存区里的改动给提交到本地的版本库 $ git pull origin master(分支名称)　　---拉取分支下的代码到当前分支并合并 $ git push origin master　　---将本地的master分支推送到origin主机 $ git remote show origin　　---查看当前仓库地址 $ git remote add origin Git地址　　---为当前文件夹添加远程仓库 $ git remote set-url origin Git地址　　---设置新的仓库地址 $ git log　　---查看提交历史 $ git reflog　　---查看版本号和提交 $ git reset --hard head(版本号)　　---回退到指定的版本代码 【冲突】 一般是在从远程主机拉取下来代码与本地代码(执行pull操作)合并时会产生冲突，表现： 《《《《《《 head ============== =|=|=|

一、概述 手工搭建 Kubernetes 集群是一件很繁琐的事情，为了简化这些操作，就产生了很多安装配置工具，如 Kubeadm ，Kubespray，RKE 等组件，我最终选择了官方的 Kubeadm 主要是不同的 Kubernetes 版本都有一些差异，Kubeadm 更新与支持的会好一些。Kubeadm 是 Kubernetes 官方提供的快速安装和初始化 Kubernetes 集群的工具，目前的还处于孵化开发状态，跟随 Kubernetes 每个新版本的发布都会同步更新, 强烈建议先看下官方的文档了解下各个组件与对象的作用。 https://kubernetes.io/docs/concepts/ https://kubernetes.io/docs/setup/independent/install-kubeadm/ https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/ 系统环境 系统 内核 docker ip 主机名 centos 7.6 3.10.0-957.el7.x86_64 19.03.5 192.168.31.150 k8s-master centos 7.6 3.10.0-957.el7.x86_64 19.03.5 192.168.31.183 k8s-node01 二、准备工作

以下内容来自： http://blog.microsuncn.com/?p=1978 恢复丢失的版本 丢失版本最常见的问题就是 比如使用了 git reset –hard HEAD^ 之类的操作，结果发现丢弃的版本还想恢复回来，但是已经没有任何分支能够reference到这个commit了。幸运的是，git 对各个分支的head还有一份log记录叫做reflog，你可以在.git/logs/refs/heads/ 目录下看到它们。 通过 git reflog 可以显示变更历史。使用类似 master@{1} master@{“2 days ago”}之类的格式，就能索引到你想要的commit。例如对应于git reset –hard HEAD^ 使用 git reset –hard HEAD@{1}即可恢复到reset之前的commit上。 出现 * (no branch)的处理 如果当前正工作在 （no branch）上： $ git checkout -b working，就会把（no branch）上的东西checkout到working分支 如果不小心从（no branch）branch切换到其他分支了，用git log不能查找到（no branch）的信息，不要担心，先用git reflog查到（no branch）的commit，然后： $ git checkout

0、引言 MySQL主从复制的原理及搭建，故障分析 一、MySQL 主从同步的架构及原理 原理： 1）Slave连接到master，主从数据一致，开启同步，开始同步数据 2） 用户在主上写入数据，日志储存到binlog，master上IO thread读取主库binlog，然后把信息传递给从库上的IO thread 3）从库上的IO thread再把部分信息存储在master.info（存储连接位置信息）和relay log里（存储binlog信息） 4）从库上的SQL thread监测到relay log有更新，把更新的信息恢复到从库，然后把位置点信息记录下来 二、MySQL 实现主从同步的几种方式及使用价值 1、MySQL主从复制的几种实现方式 l 基于binlog+position的传统复制 l 基于事务的GTID复制 l 多源复制 l Group replication（5.7新特性） l 半同步 2、MySQL主从复制的使用价值 l 利用从库做高可用 l 利用从库做读写分离 l 利用从库做升级 三、MySQL 基于binlog 三种模式下的复制 1、基于statement格式的复制 优点：binlog文件小，节省磁盘IO，只记录执行的SQL，方便阅读统计 缺点：对MySQL特殊函数不能复制，可能会导致主从不一致 2、基于row格式的复制 优点：详细记录每一行的修改信息

一. 创建Redis的deployment和service 1. 创建Redis deployment redis-master-deployment.yaml apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2 kind: Deployment metadata: name: redis-master labels: app: redis spec: selector: matchLabels: app: redis role: master tier: backend replicas: 1 template: metadata: labels: app: redis role: master tier: backend spec: containers: - name: master image: k8s.gcr.io/redis:e2e # or just image: redis resources: requests: cpu: 100m memory: 100Mi ports: - containerPort: 6379 执行： kubectl create -f redis-master-deployment.yaml 查看执行结果： deployment "redis-master"

MySQL 5.6开始主从赋值有两种方式： 　　1：基于日志binlog 　　2：基于GTID 全局事务标识符 本文只涉及基于日志 binlog 的 主从配置。 主从复制的工作流程 　　MySQL通过操作主要通过三个线程实现，基本步骤如下、 　　　　1：Master服务器将数据的更新记录到二进制（binary log）中，用于记录二进制日志时间，这一步由Master服务器完成。 　　　　2：Slave服务器将Master服务器的二进制日志复制到本地的中继日志（Relay log），这一步由Slave服务器IO线程完成。 　　　　3：Slave服务器读取中继日志中的事件，将其重放在数据中，这一步由Slave服务器SQL线程完成。 主从模式的优点 　　1：一般的工作模式下，Master服务器负责增删改操作，查询工作由Slave服务器完成。 　　2：异地容灾备份，主要就是可以把Master服务器的数据同步到异地服务器上，提高数据的安全性。 　　3：高可用，Master服务器挂了，Slave可以充当Master继续提供服务。 　　4：高扩展性 　　　　1：纵向扩展，我可以更换机器更好的配置，因为有多台服务器，所以不用担心停机。 　　　　2：横向扩展，就是加机器咯，可以分散各个服务器的压力。 主从模式的缺点 　　1：成本增加，增加服务器就不说了，主要还需要开启二进制日志

Linux运维跳槽必备的40道面试精华题 1、 什么是运维？什么是游戏运维？ 1）运维是指大型组织已经建立好的网络软硬件的维护，就是要保证业务的上线与运作的正常， 在他运转的过程中，对他进行维护，他集合了网络、系统、数据库、开发、安全、监控于一身的技术 运维又包括很多种，有 DBA运维、网站运维、虚拟化运维、监控运维、游戏运维等等 2）游戏运维又有分工，分为开发运维、应用运维（业务运维）和系统运维 开发运维：是给应用运维开发运维工具和运维平台的 应用运维：是给业务上线、维护和做故障排除的，用开发运维开发出来的工具给业务上线、维护、做故障排查 系统运维：是给应用运维提供业务上的基础设施，比如：系统、网络、监控、硬件等等 总结：开发运维和系统运维给应用运维提供了 “工具”和“基础设施”上的支撑开发运维、应用运维 和系统运维他们的工作是环环相扣的 2、在工作中，运维人员经常需要跟运营人员打交道，请问运营人员是做什么工作的？ 游戏运营要做的一个事情除了协调工作以外还需要与各平台沟通，做好开服的时间、开服数、用户导量、活动等计划 3、现在给你三百台服务器，你怎么对他们进行管理？ 管理 3百台服务器的方式： 1）设定跳板机，使用统一账号登录，便于安全与登录的考量。 2）使用salt、ansiable、puppet进行系统的统一调度与配置的统一管理。 3）建立简单的服务器的系统、配置

I switch to master and it says I am ahead by 40 commits: $ git checkout master Switched to branch 'master' Your branch is ahead of 'origin/master' by 40 commits. But when I then do a pull it says I am up-to-date: $ git pull origin master From https://github.com/dmcouncil/dmWorkflow * branch master -> FETCH_HEAD Already up-to-date. However I can resolve this (remove the 40 commits msg) with: Michaels-MacBook-Pro-2:dmWorkflow durrantm$ git push origin master Everything up-to-date and now the ' 40 commits ' message is gone: $ git status # On branch mdd_play_settings_and_topics_reports nothing to