master

主从模型   在Redis的集群当中，每个节点（实例）都有一个身份：Master或者Slave，Master：主要负责数据写入，Slave一般提供数据读取，Master与Slave之间是一对多关系，Master对应的Slave是其数据副本（replication），因此每次Master数据更新时同时要更新Slave中的内容。   但是在Master下属的Slave过多时，给对应的Slave分发数据更新请求会占用Master很多的带宽资源，因此在此基础上，需要一个Master-slave，其作为Master的下属Slave，功能除了和其他Slave一样提供数据读取服务之外，需要接纳一部分的Slave，为Master分担发送数据更新通知任务，减轻Master信息发送负担。 缺陷 一旦Master宕机失效，需要手动将Slave角色提升为Master，否则这个子集群将不可用。从自动性可用性角度来看，这个效果非常不尽人意。而在下一篇中将介绍Redis解决这个问题使用的哨兵（sentinel）机制。 Redis Cluster不保证强一致性（Strong Consistency），设想这样一个场景： 1.Master A从Client获取写请求WRITE_INFO并写入 2.Master A返回OK 3.Master A将写入（或者是更新）请求传播给Slave A1，A2，A3 其中2

1. 配置同步账号 create user 'sync'@'192.168.10.%' identified by 'sync'; grant replication slave on *.* to 'sync'@'192.168.10.%'; flush privileges; 2. 开启binlog # /etc/my.cnf增加一下配置 # open binary log mode log_bin = /mydata/binlog binlog-format = ROW 3. 初始化 mysqldump --single-transaction -uroot -hmaster -P3308 --master-data=2 -A |mysql -uroot -hslave -P3308 4. 配置主从同步 mysql -uroot -hmaster -P3308 -e " CHANGE MASTER TO MASTER_HOST='192.168.10.181', MASTER_USER='sync', MASTER_PASSWORD='sync', MASTER_PORT=3306; " 5. 启动服务 -- 开启主从 start slave; 6. 检查确认 show slave status\G; show master status\G; 来源： https://www

Gitlab 是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的 Git 项目仓库，可通过Web 界面进行访问公开的或者私人的项目 Gitlab 拥有与 Github 类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，他非常易于浏览提交过的版本并提供一个文件历史库。他还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找 一、环境准备 如果是测试环境，其内存建议2G及以上，可以去 清华开源镜像站 下载所需gitlab版本，其安装后，会自动安装nginx提供web界面，所以要避免80端口占用。 二、安装部署gitlab 1. 安装gitlab [root@git /]# mkdir git [root@git /]# cd git/ [root@git git]# wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-11.9.8-ce.0.el7.x86_64.rpm [root@git git]# rpm -ivh gitlab-ce-11.9.8-ce.0.el7.x86_64.rpm #当gitlab安装完毕后会有一个大狐狸头 #由于我不打算做域名解析，所以需要修改其配置文件 [root@git git]# vim /etc

MySQL主从复制与读写分离的实现 转载 2013年01月17日 18:20:12 MySQL主从复制与读写分离 MySQL主从复制(Master-Slave)与读写分离(MySQL-Proxy)实践 Mysql作为目前世界上使用最广泛的免费数据库，相信所有从事系统运维的工程师都一定接触过。但在实际的生产环境中，由单台Mysql作为独立的数据库是完全不能满足实际需求的，无论是在安全性，高可用性以及高并发等各个方面。 因此，一般来说都是通过 主从复制（Master-Slave）的方式来同步数据，再通过读写分离（MySQL-Proxy）来提升数据库的并发负载能力 这样的方案来进行部署与实施的。 如下图所示： 下面是我在实际工作过程中所整理的笔记，在此分享出来，以供大家参考。 一、MySQL的安装与配置 具体的安装过程，建议参考我的这一篇文章： http://heylinux.com/archives/993.html 值得一提的是，我的安装过程都是源码包编译安装的，并且所有的配置与数据等都统一规划到了/opt/mysql目录中，因此在一台服务器上安装完成以后，可以将整个mysql目录打包，然后传到其它服务器上解包，便可立即使用。 二、MySQL主从复制 场景描述： 主数据库服务器：192.168.10.130，MySQL已经安装，并且无应用数据。 从数据库服务器：192.168.10

一：主从复制 一：介绍 主从复制就是从库不断向主库要数据，来更新自身的数据库以便自身的数据库数据和主库相同。基于二进制日志完成的. 作用： 1、做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。 2、架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。 3、读写分离，使数据库能支撑更大的并发。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。 简单流程介绍：从库读取master.info 中最后一个二进制日志（例mysql-bin.000012）序号和主库连接信息去连接主库（构建的是长链接，会一直问主库要数据），主库通过show master status查看当前最新的二进制日志，假设是mysql-bin.000020，那么主库就会将12-20之间的二进制日志都通过dump线程发送给从库，然后从库进行一系列的更新。 简单搭建一个主从： 构建如下一个主从 Master slave 3307---->3308 1. 3307中创建复制用户 主库开启二进制日志 vim /data/3307/my.cnf log_bin=/data/3307/mysql

一：本章目录 Kubernetes介绍 所需组件功能介绍 环境规划与说明 部署流程 小结 二：Kubernetes介绍 1·概述 ：kubernetes，简称K8s，是用8代替8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。 传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。 2·Kubernetes 特点 ： 可移植: 支持公有云，私有云，混合云，多重云（multi-cloud） 可扩展: 模块化，插件化，可挂载，可组合 自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展 三：所需组件功能介绍 组件名称 组件作用 组件所在节点 ETCD etcd是Kubernetes提供默认的存储系统，保存所有集群数据，使用时需要为etcd数据提供备份计划。 Master kube-apiserver kube-apiserver用于暴露Kubernetes API。任何的资源请求/调用操作都是通过kube

简述项目中优化sql语句执行效率的方法，从哪些方面，sql语句性能如何分析？ （1）尽量选择较小的列； （2）将where中用的比较频繁的字段建立索引； （3）select中避免使用*； （4）避免在索引列上使用计算、not in和<>等操作； （5）当只需要一行数据时候使用limit1； （6）保证单表数据不超过200w，实时分割表； 针对查询较慢的语句，可以使用explain来分析该语句具体的执行情况。 sql语句应考虑哪些安全性？ （1）少使用root账户，应该为不同的动作分配不同的账户； （2）sql执行出错后，不能把数据库中显示的出错信息，直接展示给用户。防止泄露服务器和数据库相关信息； （3）防止sql注入，对特殊字符进行转义、过滤或者使用预编译的sql语句绑定变量 接下来重点说下Mysql半同步复制， 从MySQL5.5开始，MySQL以插件的形式支持半同步复制 。先来区别下mysql几个同步模式概念： 异步复制（Asynchronous replication） MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。 全同步复制（Fully synchronous

MySQL默认的复制都是异步的，在服务器崩溃时丢失事务是使用异步复制不可避免的结果。而5.5之后推出的一项新功能：半同步复制，可以限制事务丢失的数量。 MySQL5.7在5.6/5.5的基础上增强了几点功能： 1）无数据丢失 MySQL5.6/5.5 半同步复制的原理 ：提交事务的线程会被锁定，直到至少一个Slave收到这个事务，由于 事务在被提交到存储引擎之后才被发送到Slave上 ，所以事务的丢失数量可以下降到最多每线程一个。因为事务是在被提交之后才发送给Slave的，当Slave没有接收成功，并且Master挂了，会导致主从不一致：主有数据，从没有数据。如下面的情况：（ AFTER_COMMIT） 客户端执行一个事务，master接收到之后提交后并把事务发送给slave，在发送的期间网络出现波动，但要等待slave把binlog写到本地的relay-log，然后给master一个返回信息，等待以rpl_semi_sync_master_timeout参数设置的超时为准（默认为10秒）响应。在这等待的10秒里，其他会话查可以看到Master上的事务，此时一旦master发生宕机，由于事务没有发送给slave，而master已经提交了，导致数据不一致。 例子： A客户端执行的事务将字段Z从0修改为1。 1.A提交事务到master 2.master写binlog 3.master

1.1 主服务器配置 1.安装插件 2.mysql > INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; 3.查看全局变量 4.mysql > show global variables like '%semi%'; 设置主服务器的半同步复制全局变量 mysql > set global rpl_semi_sync_master_enabled=ON; 开启半同步复制 mysql > set global rpl_semi_sync_master_timeout=10000; 设置为10秒 vi /etc/my.cnf [mysqld] rpl_semi_sync_master_enabled=1 rpl_semi_sync_master_timeout=1000 # 1 second 4.2 设置从服务器 1.安装semi插件 2.mysql >install plugin rpl_semi_sync_slave soname 'semisync_slave.so'; vi /etc/my.cnf [mysqld] rpl_semi_sync_slave_enabled=1 relay_log_purge=0 read_only=1 slave_skip_errors=1396 3

l 安装配置: 略 l 机器分布 IP 作用 用途 192.168.15.3 master 主库 192.168.15.4 Slave1 备库 192.168.15.5 Slave2 备库 l 基本的MySQL主从配置 MySQL复制过程分成三步： master将改变记录到二进制日志（binary log）。这些记录过程叫做二进制日志事件，binary log events； slave将master的binary log events拷贝到它的中继日志（relay log）； slave重做中继日志中的事件，将改变应用到自己的数据库中。 MySQL复制是异步的且串行化的 Master配置 1)分配复制权限 主库和从库均需要执行 mysql> grant replication client,replication slave on *.* to 'replck1'@'192.168.15.%' identified by "replck1#!123"; mysql> flush privileges; 2)将master中的数据dump到slave1 slave2中 /opt/app/mysql/bin/mysqldump -uroot -p'' --opt --default-character-set=utf8 \ --triggers -R --master-data=2