mysql集群

#master 配置参数 server_id 复制中唯一标示 log-bin binlog日志路径 log-bin-index binlog 日志索引文件 binlog_format binlog格式， Statement ，ROW MIXED max_binlog_size binlog日志文件大小 默认大小1G sync_binlog 多少个SQL以后调用fdatasync()函数刷新binlog to disk #fsync 是完全刷新到磁盘，fdatasync 只刷新数据，不刷新metadata expire_logs_days binlog 保留多少天 log_bin_trust_function_creators 开启binlog 时，是否允许创建存储程序（除非有super权限，或者指定deterministic reads sql data,no sql） auto_increment_increment #在数字表列auto_increment 每次增长的步长和幅度 auto_increment_offset # 在数字表列auto_increment 起始位置 binlog-do-db binlog记录的数据库 binlog-ignore-db binlog 不记录的数据库 log_bin_trust_function_creators 开启binlog

SequoiaDB 巨杉数据库 3.0 ，在产品GA发布后，经过近半年在金融级场景的测试、上线和稳定运行之后，于近期正式发布。 1. SequoiaDB 3.0 产品定位 SequoiaDB巨杉数据库是一款金融级分布式数据库，包括了分布式NewSQL、分布式文件系统与对象存储、与高性能NoSQL三种存储模式，分别对应分布式在线交易、非结构化数据和内容管理、以及海量数据管理和高性能访问场景。 根据Gartner的数据库报告，Multi-model多模是未来10年，下一代分布式数据库发展的最主要方向。从1.0的高性能分布式 NoSQL数据库，到2.0加入的分布式对象存储，再到3.0完整协议级兼容MySQL，SequoiaDB经过6年的不断迭代创新，全面支持企业级结构化、半结构化以及非结构化数据存储。 SequoiaDB 3.0 产品维度 2. MySQL 完整协议级兼容 SequoiaDB 3.0实现了100%的MySQL协议级兼容： · 全面兼容：全面支持MySQL协议与语法，用户可以直接使用MySQL客户端或任何管理、开发与监控工具对数据库进行操作； · MySQL语法：由于使用了MySQL原生的解析器，SequoiaDB 3.0 能够实现100%的MySQL语法兼容，支持语法包括基础CRUD操作，多表关联，跨节点事务操作，创建视图，存储过程，索引和访问计划等。 · 无缝切换：

第1章 引言 随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的 互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层 已经成为架构研发人员首选的方式。水平切分数据库，可以降低单台机器的负载，同时最大限度的降低了了宕机造成的损失。通过负载均衡策略，有效的降低了单台 机器的访问负载，降低了宕机的可能性；通过集群方案，解决了数据库宕机带来的单点数据库不能访问的问题；通过读写分离策略更是最大限度了提高了应用中读取 （Read）数据的速度和并发量。目前国内的大型互联网应用中，大量的采用了这样的数据切分方案，Taobao,Alibaba,Tencent，它们大 都实现了自己的分布式数据访问层（DDAL）。以实现方式和实现的层次来划分，大概分为两个层次（Java应用为例）：JDBC层的封装，ORM框架层的 实现。就JDBC层的直接封装而言，现在国内发展较好的一个项目是被称作“变形虫”(Amoeba)的项目，由阿里集团的研究院开发，现在仍然处于测试阶 段（beta版），其运行效率和生产时效性有待考究。就ORM框架层的实现而言，比如Taobao的基于ibatis和Spring的的分布式数据访问 层，已有多年的应用，运行效率和生产实效性得到了开发人员和用户的肯定

常规复制架构　 Master - Slaves 在实际应用场景中，MySQL复制90%以上都是一个Master复制到一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端 廉价扩展解决方案。因为只要Master和Slave的压力不是太大（尤其是Slave端压力）的话，异步复制的延时一般都很少很少。尤其是自从 Slave端的复制方式改成两个线程处理之后，更是减小了Slave端的延时问题。而带来的效益是，对于数据实时性要求不是特别Critical的应用， 只需要通过廉价的pcserver来扩展Slave的数量，将读压力分散到多台Slave的机器上面，即可通过分散单台数据库服务器的读压力来解决数据库 端的读性能瓶颈，毕竟在大多数数据库应用系统中的读压力还是要比写压力大很多。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大 型网站也在使用类似方案解决数据库瓶颈。 这个架构可以通过下图比较清晰的展示： 一个Master复制多个Slave的架构实施非常简单，多个Slave和单个Slave的实施并没有实质性的区别。在Master端并不Care 有多少个Slave连上了自己，只要有Slave的IO线程通过了连接认证，向他请求指定位置之后的BinaryLog信息，他就会按照该IO线程的要 求，读取自己的BinaryLog信息，返回给Slave的IO线程。

NoSQL 入门与概述 为什么用 NoSQL? 什么是单机 MySQL? 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。 Memcached（缓存）+MySQL+垂直拆分 MySQL 主从读写分离 由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。MySQL 的 Master-Slave 模式成为这个时候的网站标配了。 分表分库+水平拆分+MySQL集群 在 Memcached 的高速缓存，MySQL 的主从复制，读写分离的基础之上，这时 MySQL 主库的写压力开始出现瓶颈，而数据量的持续猛增，由于 MyISAM 使用表锁，在高并发下会出现严重的锁问题，大量的高并发 MySQL 应用开始使用 InnoDB 引擎代替MyISAM。 同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL 推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然 MySQL 推出了 MySQL Cluster 集群，但性能也不能很好满足互联网的要求，只是在高可靠性上提供了非常大的保证。 MySQL 的扩展问题 MySQL

本帖最后由 osdba 于 2011-04-21 16:33 编辑 特性 MySQL PostgreSQL 实例 通过执行 MySQL 命令（mysqld）启动实例。一个实例可以管理一个或多个数据库。一台服务器可以运行多个 mysqld 实例。一个实例管理器可以监视 mysqld 的各个实例。 通过执行 Postmaster 进程（pg_ctl）启动实例。一个实例可以管理一个或多个数据库，这些数据库组成一个集群。集群是磁盘上的一个区域，这个区域在安装时初始化并由一个目录组成，所有数据都存储在这个目录中。使用 initdb 创建第一个数据库。一台机器上可以启动多个实例。 数据库 数据库是命名的对象集合，是与实例中的其他数据库分离的实体。一个 MySQL 实例中的所有数据库共享同一个系统编目。 数据库是命名的对象集合，每个数据库是与其他数据库分离的实体。每个数据库有自己的系统编目，但是所有数据库共享 pg_databases。 数据缓冲区 通过 innodb_buffer_pool_size 配置参数设置数据缓冲区。这个参数是内存缓冲区的字节数，InnoDB 使用这个缓冲区来缓存表的数据和索引。在专用的数据库服务器上，这个参数最高可以设置为机器物理内存量的 80%。 Shared_buffers 缓存。在默认情况下分配 64 个缓冲区。默认的块大小是 8K。可以通过设置

K8S的搭建在 https://www.cnblogs.com/xuziyu/p/11725976.html 可以查看 我们要在K8S上启动Mysql服务分为以下几步 1.1为MySQL服务创建一个RC定义文件mysql-rc.yaml，下面给出完整的内容和解释 apiVersion: v1 kind: ReplicationController metadata: name: mysql spec: replicas: 1 selector: app: mysql template: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql ports: - containerPort: 3306 env: - name: MYSQL_ROOT_PASSWORD value: "123456" 解释 图片来源：《Kubernetes权威指南》第四版 1.2 文件创建好了以后为了将它发布到Kubernetes集群中，我们需要在Master上执行命令 [root@docker001 yum.repos.d]# kubectl apply -f mysql-svc.yaml接下来查看刚刚创建的RC[root@docker001 yum.repos.d]# kubectl get rc

一、MHA 简介 MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案， 它由日本 DeNA 公司的 youshimaton 员工（现就职于 Facebook 公司）开发，是一套优秀的作 为 MySQL 高可用性环境下故障切换和主从角色提升的高可用软件。在 MySQL 故障切换过程 中，MHA 能做到在 0~30 秒之内自动完成数据库的主从故障切换操作，并且在进行故障切换 的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA 由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节 点上。MHA Node 运行在每台 MySQL 服务器及 Manager 服务器上，MHA Manager 会定时探 测集群中的 master 节点，当 master 出现故障时，它可以自动将拥有最新数据的 slave 提升 为新的 master，然后将所有其他的 slave 重新指向新提升的 master。整个故障转移过程对应 用程序层面完全透明。 在 MHA 自动故障切换过程中，MHA 会试图从宕机的主服务器上保存二进制日志，最大 程度的保证数据不丢失

MHA 简介 MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案， 它由日本 DeNA 公司的 youshimaton 员工（现就职于 Facebook 公司）开发，是一套优秀的作 为 MySQL 高可用性环境下 故障切换 和 主从角色提升 的高可用软件。在 MySQL 故障切换过程 中，MHA 能做到在 0~30 秒之内自动完成数据库的主从故障切换操作，并且在进行故障切换 的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA 由两部分组成： MHA Manager（管理节点） 和 MHA Node（数据节点） 。MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节 点上。MHA Node 运行在每台 MySQL 服务器及 Manager 服务器上，MHA Manager 会定时探 测集群中的 master 节点，当 master 出现故障时，它可以自动将拥有最新数据的 slave 提升 为新的 master，然后将所有其他的 slave 重新指向新提升的 master。整个故障转移过程对应 用程序层面完全透明。 在 MHA 自动故障切换过程中，MHA 会试图从宕机的主服务器上保存二进制日志，最大

1 介绍 MySQL Group Replication（简称MGR）是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案。MySQL组复制提供了高可用、高扩展、高可靠的MySQL集群服务。 高一致性，基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提供一致数据安全保证； 高容错性，只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制； 高扩展性，节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息； 高灵活性，有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。 MGR是MySQL数据库未来发展的一个重要方向。 2 环境准备 操作系统centos7 192.168.200.111　　mysql-5.7 181 192.168.200.112　　mysql-5.7　　182 192.168.200.113　　mysql-5.7　　183 2.2 二进制安装MySQL 省略 2.3 设置hostname和ip映射 [root@server2 ~]# vim /etc