mysql集群

# 分析 pod 首先，我们先从最小的调度单位pod开始。 我的k8s集群中目前有一个pod，它的name为admin-mysql-1d29997-5db458497c-h6rrs [root@k8s-master ~]# kubectl get pod admin-mysql-1d29997-5db458497c-h6rrs NAME READY STATUS RESTARTS AGE admin-mysql-1d29997-5db458497c-h6rrs 1/1 Running 0 5d23h 查看一下pod的详细内容： [root@k8s-master ~]# kubectl describe pod admin-mysql-1d29997-5db458497c-h6rrs Name: admin-mysql-1d29997-5db458497c-h6rrs Namespace: default Priority: 0 PriorityClassName: <none> Node: k8s-node1/192.168.0.247 Start Time: Fri, 01 Nov 2019 10:57:47 +0800 Labels: name=mysql pod-template-hash=5db458497c Annotations: <none> Status:

前面大家介绍了主从、主主复制以及他们的中间件mysql-proxy的使用，这一篇给大家介绍的是keepalived的搭建与使用！ 一、keepalived简介 1.1、keepalived介绍 　　　　Keepalived起初是为LVS设计的， 专门用来监控集群系统中各个服务节点的状态 ，它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态， 如果某个服务器节点出现异常， 　　或者工作出现故障，Keepalived将检测到，并将出现的故障的服务器节点从集群系统中剔除， 这些工作全部是自动完成的，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。 　　　　后来Keepalived又加入了VRRP的功能，VRRP（Vritrual Router Redundancy Protocol,虚拟路由冗余协议)出现的目的是解决静态路由出现的单点故障问题，通过VRRP可以实现网络不间断稳定运行， 　　因此Keepalvied 一方面具有服务器状态检测和故障隔离功能，另外一方面也有HA cluster功能，下面介绍一下VRRP协议实现的过程。 1.2、VRRP协议与工作原理 　　　　在现实的网络环境中。 主机之间的通信都是通过配置静态路由或者(默认网关)来完成的，而主机之间的路由器一旦发生故障，通信就会失效 ，因此这种通信模式当中，路由器就成了一个单点瓶颈

第1章 安装Nginx 环境： 系统：CentOS6.5 软件：nginx-1.6.3 mysql-5.5.49 php-5.5.32 1.1 Nginx官网 http://nginx.org/ 1.2 安装nginx 1.2.1 安装Nginx所需的pcre库 作用：实现伪静态的功能 yum install pcre pcre-devel -y 1.2.2 安装编译依赖包： yum install gcc gcc-devel -y yum install openssl openssl-devel -y 1.2.3 下载源码包： wget -q http://nginx.org/download/nginx-1.6.3.tar.gz 参数：-q 下载不提示。 1.2.4 解压 tar xf nginx-1.6.3.tar.gz cd nginx-1.6.3 1.2.5 查询yum仓库有没有rpm包 yum list |grep nginx 或yum list *nginx* 1.2.6 添加系统用户： useradd www -s /sbin/nologin -M 1.2.7 开始编译安装nginx 1.2.7.1 配置编译参数 ./configure --user=www --group=www --prefix=/application/nginx-1.6.3/ --with

Mysql的binlog日志是用来记录mysql内部增删等对mysql数据库有更新的内容的记录(对数据库 的改动)，对数据库的查询select或show等不会被binlog日志记录;主要用于数据库的主从复制以及增量恢复。 mysql的binlog日志必须打开log-bin功能才能生产binlog日志 1、开启MySQL的binlog日志 修改/etc/my.cnf [mysqld] log-bin=/var/lib/mysql/mysql-bin 【binlog⽇日志存放路路径】 binlog-format=ROW 【⽇日志中会记录成每⼀一⾏行行数据被修改的形式】 server_id=1 【指定当前机器器的服务ID(如果是集群，不不能重复)】 重启MySQL并通过命令验证 mysql> show variables like '%log_bin%'; 进入指定的binlog路径查看是否生产binlog cd /var/lib/mysql/ 2、安装Maxwell Maxwell是一个能实时读取MySQL二进制日志binlog，并生成 JSON 格式的消息，作为生产者发送给 Kafka，Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件或其它平台的应用程序。它的常见应用场景有ETL、维护缓存、收集表级别的dml指标、增量到搜索引擎

PXC搭建详细步骤，适合小白 PXC搭建步骤 第一步，下载PXC组件 共包含三个安装包，Percona XtraDB Cluster，Percona XtraBackup， Percona Release。 1：登录官网：https://www.percona.com/downloads/ 国外域名， 访问速度较慢，需要耐心等待，有条件的可自行想办法提高访问及下载速度（手动捂脸） 2：下载Percona XtraDB Cluster 如图，选择要安装的MYSQL 版本（以5.7为例），点击进入 如图，这里可以继续选择mysql的详细版本，选择完mysql版本后，选择操作系统的版本，如果不知道操作系统的版本，可选择通用版本：Linux-Generic ，选择完操作系统版本后，下边会展示出对应可选的下载链接，根据自己操作系统的位数，点击下载链接进行下载即可。一般这里会展示多个版本，随便选择一个就行。需要注意的是，这里需要下载整个包（Download Packages Separately），这里我下载到的文件名称为：Percona-XtraDB-Cluster-5.7.25-rel28-31.35.1.Linux.x86_64.ssl101.tar.gz 3，下载Percona XtraBackup 2.4 这里的操作和第二步基本类似，需要注意的是

官方文档： http://galeracluster.com/documentation-webpages/index.html 一、 Galera Cluster的工作原理 主要关注点是数据一致性。 事务既可以应用于每个节点，也可以不全部应用。 所以，只要它们配置正确，数据库保持同步。 Galera复制插件不同于传统的MySQL复制，可以解决多个问题，包括多主写入冲突，复制滞后和主从不同步。 在典型的Galera集群实例中，应用程序可以写入集群中的任何节点，然后通过基于认证的复制将事务提交（RBR事件）应用于所有服务器。 使用组通信和事务排序技术，基于认证的复制是同步数据库复制的另一种方法 二、Galera集群安装 说明：Galera集群至少需要三个节点的服务器硬件。 node-12:10.71.11.12 node-13:10.71.11.13 node-14:10.71.11.14 操作系统: centos7 内核版本: 3.10.0-693.21.1.el7.x86_64 开始安装 说明：为集群中的每个节点执行以下步骤。文档以node-12配置为例 1.编辑/etc/hosts文件，配置节点互相解析 [root@node-12 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4

1、主从复制概述 　　MySQL主从复制也可以称为MySQL主从同步，它是构建数据库高可用集群架构的基础。它通过将一台主机的数据复制到其他一台或多台主机上，并重新应用relay log中的SQL语句来实现复制功能。MySQL支持单向、双向、链式级联、异步复制，5.5版本之后加入的半同步复制，5.6版本之后的GTID复制，MySQL5.7的多源复制、并行复制、loss-less复制。 1.1 常见的几种主从架构 　　1）单向主从模式：Master ——> Slave 　　2）双向主从模式：Master <====> Master 　　3）级联主从模式：Master ——> Slave1 ——> Slave2 　　4）一主多从模式 　　5）多主一从模式 1.2 主从复制功能 　　1）实时灾备 　　2）读写分离 　　3）高可用 　　4）从库数据统计 　　5）从库数据备份 　　6）平滑升级 1.3 主从复制原理 　　主从同步过程中主服务器有一个工作线程I/O dump thread，从服务器有两个工作线程I/O thread和SQL thread。 　　主库把外界接收的SQL请求记录到自己的binlog日志中，从库的I/O thread去请求主库的binlog日志，并将binlog日志写到中继日志中，然后从库重做中继日志的SQL语句。主库通过I/O dump thread给从库I/O

近日工作任务较轻，有空学习学习技术，遂来研究如果实现读写分离。这里用博客记录下过程，一方面可备日后查看，同时也能分享给大家（网上的资料真的大都是抄来抄去，，还不带格式的，看的真心难受）。 完整代码： https://github.com/FleyX/demo-project/tree/master/dxfl 1、背景   一个项目中数据库最基础同时也是最主流的是单机数据库，读写都在一个库中。当用户逐渐增多，单机数据库无法满足性能要求时，就会进行读写分离改造（适用于读多写少），写操作一个库，读操作多个库，通常会做一个数据库集群，开启主从备份，一主多从，以提高读取性能。当用户更多读写分离也无法满足时，就需要分布式数据库了（可能以后会学习怎么弄）。   正常情况下读写分离的实现，首先要做一个一主多从的数据库集群，同时还需要进行数据同步。这一篇记录如何用 mysql 搭建一个一主多次的配置，下一篇记录代码层面如何实现读写分离。 2、搭建一主多从数据库集群   主从备份需要多台虚拟机，我是用 wmware 完整克隆多个实例，注意直接克隆的虚拟机会导致每个数据库的 uuid 相同，需要修改为不同的 uuid。修改方法参考这个： 点击跳转 。 主库配置 主数据库（master）中新建一个用户用于从数据库（slave）读取主数据库二进制日志，sql 语句如下： mysql> CREATE USER

本文由云+社区发表 作者：数据库 版权声明： 本文由腾讯云数据库产品团队整理，页面原始内容来自于severalnines英文官网，若转载请注明出处。翻译目的在于传递更多全球最新数据库领域相关信息，并不意味着腾讯云数据库产品团队赞同其观点或证实其内容的真实性。如果其他媒体、网站或其他任何形式的法律实体和个人使用，必须经过著作权人合法书面授权并自负全部法律责任。不得擅自使用腾讯云数据库团队的名义进行转载，或盗用腾讯云数据库团队名义发布信息。 原文链接：https://severalnines.com/blog/mysql-performance-benchmarking-mysql-57-vs-mysql-80 在Oracle MySQL团队的推动下，MySQL 8.0发生了巨大的变化和修改。 物理文件已更改。例如， .frm， .TRG， .TRN和 .par 不再存在。添加了大量的新特性，如通用表表达式(Common Table Expressions CTE)，窗口函数（Window Functions），不可见索引（ Invisible Indexes），正则表达式（regexp） -MySQL8.0现在已经完全支持Unicode，且具有多字节安全特性。数据字典也发生了变化。它现在与一个事务性数据字典合并，该字典存储有关数据库对象的信息。与以前的版本不同

0.导读 本文讲诉滴滴在分布式Nosql存储Fusion之上构建NewSQL的实践之路。详细描述Fusion-NewSQL的特性，应用场景，设计方案。 1.背景 Fusion-NewSQL是由滴滴自研的在分布式KV存储基础上构建的NewSQL存储系统。Fusion-NewSQ兼容了MySQL协议，支持二级索引功能，提供超大规模数据持久化存储和高性能读写。 ▍我们的问题 滴滴的业务快速持续发展，数据量和请求量急剧增长，对存储系统等压力与日俱增。虽然分库分表在一定程度上可以解决数据量和请求增加的需求，但是由于滴滴多条业务线（快车，专车，两轮车等）的业务快速变化，数据库加字段加索引的需求非常频繁，分库分表方案对于频繁的Schema变更操作并不友好，会导致DBA任务繁重，变更周期长，并且对巨大的表操作还会对线上有一定影响。同时，分库分表方案对二级索引支持不友好或者根本不支持。鉴于上述情况，NewSQL数据库方案就成为我们解决业务问题的一个方向。 ▍开源产品调研 最开始，我们调研了开源的分布式NewSQL方案：TIDB。虽然TIDB是非常优秀的NewSQL产品，但是对于我们的业务场景来说，TIDB并不是非常适合，原因如下： 我们需要一款高吞吐，低延迟的数据库解决方案，但是TIDB由于要满足事务，2pc方案天然无法满足低延迟（100ms以内的99rt，甚至50ms内的99rt） 我们的多数业务