mysql集群

MySQL数据库优化 概览 软优化 1.优化查询语句 2.优化子查询 3.命中索引 4.分解表 5.增加中间表 6.增加冗余字段 7.分析表、检查表、优化表 硬优化 1.cpu、内存、磁盘 2.配置参数 3.分库分表 4.缓存集群 概览 软优化 ：1.优化查询语句；2.优化子查询；3.命中索引；4.分解表；5.增加中间表；6.增加冗余字段；7.分析表、检查表、优化表 硬优化 ：1.cpu、内存、磁盘；2.配置参数；3.分库分表+读写分离；4.缓存集群 软优化 1.优化查询语句 使用EXPLAIN或者DESCRIBE（可简写为DESC）命令分析一条查询语句的执行信息 输入： DESC SELECT * FROM user 显示： select_type：代表查询类型，分为简单查询、子查询等等 type：代表查询策略，分为全表扫描（ALL）、索引合并（index_merge）等等 possible_keys：可能用到的索引 key：实际用到的索引 Extra：额外信息，包含Using intersect（index1，index2）、Using where、Using index等等 2.优化子查询 应该尽量使用join查询代替子查询。子查询是一个嵌套的查询，外层查询嵌套内层查询，查询时会建立内层查询的临时表，查询完毕会删除该临时表，建立和删除会有较大的系统开销

PXC简介 PXC是 Percona XtraDB Cluster 的缩写，是 Percona 公司出品的免费MySQL集群产品。PXC的作用是通过mysql自带的Galera集群技术，将不同的mysql实例连接起来，实现多主集群。在PXC集群中每个mysql节点都是可读可写的，也就是主从概念中的主节点，不存在只读的节点。 PXC实际上是基于Galera的面向OLTP的多主同步复制插件，PXC主要用于解决MySQL集群中数据同步强一性问题。PXC可以集群任何mysql的衍生版本，例如MariaDB和Percona Server。由于Percona Server的性能最接近于mysql企业版，性能相对于标准版的mysql有显著的提升，并且对mysql基本兼容。所以在搭建PXC集群时，通常建议基于Percona Server进行搭建。 关于数据库集群方案的选择可以参考： 浅谈数据库集群方案 PXC的特点 同步复制，事务在所有集群节点要么全部提交完成，要么全部失败 多主复制，不存在主从角色的划分，可以在任意一个节点进行读/写操作 数据同步的强一致性，所有节点的数据是实时一致的 PXC集群节点越多，数据同步的速度就越慢，所以PXC集群的规模不能太大 PXC集群数据同步的速度取决于配置最低的节点，所以PXC集群中所有节点的硬件配置尽量保持一致 PXC集群只支持InnoDB引擎

目录 一、简介 1.1MHA角色 二、MHA的工具 三、MHA部署过程 3.1.1 配置 3.1.2 环境规划 3.1.3 配置一主多从 3.2 MHA配置 3.2.1 master权限授予 3.2.2 ssh互信 3.2.3 安装mha包 3.2.4 MHA管理节点配置 3.2.5 MHA节点检测 3.2.6 MHA启动 3.2.7 MHA模拟故障 3.2.8 修复已损坏的节点加入MHA中 MHA 问题集锦 一、简介 MHA的逻辑是，为了保证其MySQL的高可用，会有一个StandBy状态的master.在mysql故障切换的过程中，MHA 能做到在 0~30 秒内自动完成 数据库 的故障切换操作，并且在进行故障切换的过程中，MHA 能最大程度的保证数据的一致性，以达到相对意义上的高可用。 1.1MHA角色 如下图，整个 MHA 架构分为 MHA Manager 节点 MHA Node 节点 其中 MHA Manager 节点是单点部署，MHA Node 节点是部署在每个需要监控的 MySQL 集群节点上的。MHA Manager 会定时探测集群中的 Master 节点，当 Master 出现故障时，它可以自动将最新数据的 Standby Master 或 Slave 提升为新的 Master，然后将其他的 Slave 重新指向新的 Master。 二、MHA的工具

一、工作原理 MHA工作原理总结为以下几条： （1） 从宕机崩溃的 master 保存二进制日志事件（binlog events）； （2） 识别含有最新更新的 slave ； （3） 应用差异的中继日志(relay log) 到其他 slave ； （4） 应用从 master 保存的二进制日志事件(binlog events)； （5） 通过Manager控制器提升一个 slave 为新 master ； （6） 使用其他的 slave 连接新的 master 进行复制。 概念 二、实现过程 MHA 对 MYSQL 复制环境有特殊要求，例如各节点都要开启二进制日志及中继日志，各从节点必须显示启用其read-only属性，并关闭relay_log_purge功能等，这里对配置做事先说明。 机器名称 IP配置 服务角色 备注 Manager 10.0.0.44 Manager控制器 用于监控管理 Master 10.0.0.41 数据库主服务器 开启bin-log relay-log 关闭relay_log_purge Slave1 10.0.0.42 数据库从服务器 开启bin-log relay-log 关闭relay_log_purge Slave2 10.0.0.43 数据库从服务器 开启bin-log relay-log 关闭relay_log_purge 1

################## 数据储存与缓存相关 ####################### mysql数据库， redis数据库， 9. MySQL的索引一般是怎么实现的？ B-Tree(一般是B+Tree)和Hash，然后再简单介绍一下。 存储 存储可能包含rdbms，nosql以及缓存等，我以MySQL,redis举例。 mysql相关 mysql 是流行的RDBMS 关系型数据库 1.谈谈mysql字符集和排序规则？ 2.var char与char的区别是什么？大小限制？utf8字符集下varchar最多能存多少个字符 char的长度是不可变的，而varchar的长度是可变的，也就是说，定义一个char[10]和varchar[10],如果存进去的是‘csdn’,那么char所占的长度依然为10， 除了字符‘csdn’外，后面跟六个空格，而varchar就立马把长度变为4了，取数据的时候，char类型的要用trim()去掉多余的空格，而varchar是不需要的。 尽管如此，char的存取数度还是要比varchar要快得多，因为其长度固定，方便程序的存储与查找；但是char也为此付出的是空间的代价，因为其长度固定，所以难免会有多余的空格占位符占据空间，可谓是以空间换取时间效率，而varchar是以空间效率为首位的。 再者，char的存储方式是，对英文字符

参考： CDH 5.1.5(parcels)集群中hive1.1.0升级到hive-1.2.1步骤全，升级hive元数据库，数据不丢失（亲测可用） 操作步骤： 下载 hive-1.2.1-bin 解压： [ root@node01 ~ ] # cd /opt/software/ [ root@node01 software ] # ls apache-hive-1.2.1-bin.tar.gz cloudera-manager-centos7-cm5.14.2_x86_64.tar.gz jdk-8u231-linux-x64.tar.gz maxwell-1.22.1.tar.gz apache-phoenix-4.14.0-cdh5.14.2-bin.tar.gz flink-1.9.1-cdh-5.14.2.tar.gz kafka-manager-1.3.1.6.zip mysql-connector-java.jar [ root@node01 software ] # tar -zxf apache-hive-1.2.1-bin.tar.gz -C /opt/module/ [ root@node01 software ] # cd /opt/module/ [ root@node01 module ] # mv apache-hive-1.2.1-bin hive-1

导航： 一、前提 1.版本信息-2.查看方法-3.查看k8s集群节点状态-4.配置docker仓库下载加速 二、安装部署helm 1.下载软件包-2.安装helm-3.初始化 三、使用helm安装mysql 1.搜索mysql的helm包-2.准备后端存储-3.准备docker image-4.配置集群内的kube-dns-5.安装mysql的helm包-6.查看mysql的有状态应用、pod、svc、pvc等k8s资源-7.客户端验证 四、故障排除 五、参考资料 一、前提 使用helm安装有状态应用mysql主备集群，首先确保你已经搭建好一个3节点的k8s集群(如何搭建k8s集群、k8s集群网络配置flannel请参考百度)。 1.版本信息 k8s: v1.5.2 docker: 1.13.1 flannel:0.7.1 helm: v3.0.0 2.查看方法 kubectl version docker version flanneld --version helm version 3.查看k8s集群节点状态 [root@master ~]# kubectl get node NAME STATUS AGE master Ready 4d node2 Ready 18h node3 Ready 4m [root@master ~]# 4.配置docker仓库下载加速

[root@hadoop001 ~]# visudo [root@hadoop001 ssh]# useradd hadoop SSH免密 [hadoop@hadoop001 ~]$ ssh-keygen [hadoop@hadoop001 ~]$ cd .ssh [hadoop@hadoop001 .ssh]$ pwd /home/hadoop/.ssh [hadoop@hadoop001 .ssh]$ cat id_rsa.pub >> authorized_keys [hadoop@hadoop001 .ssh]$ chmod 700 ~/.ssh [hadoop@hadoop001 .ssh]$ chmod 600 ~/.ssh/authorized_keys [hadoop@hadoop001 .ssh]$ ssh hadoop001 The authenticity of host 'hadoop001 (172.31.36.137)' can't be established. ECDSA key fingerprint is SHA256:AAM1VixV4qWn6aVj1liWEOFzmsYKTYxqOFKokwPIPwI. ECDSA key fingerprint is MD5:2d:1b:1d:d2:c2:32:34:ea:fe:ba:52:37:c4:a3

文章来源： https://www.cnblogs.com/php826291930/p/11242436.html 因为看了觉得通俗易懂，就转载了次文章，以做备份，如果侵犯原作者相应权利，请第一时间联系我进行删帖 1、what 什么是读写分离？ 读写分离，基本的原理是让主数据库处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。 2、why 为什么要读写分离呢？ 因为数据库的“写”（写10000条数据到oracle可能要3分钟）操作是比较耗时的。 但是数据库的“读”（从oracle读10000条数据可能只要5秒钟）。 所以读写分离，解决的是，数据库的写入，影响了查询的效率。 3、when 什么时候要读写分离？ 数据库不一定要读写分离，如果程序使用数据库较多时，而更新少，查询多的情况下会考虑使用，利用数据库主从同步 。可以减少数据库压力，提高性能。当然，数据库也有其它优化方案。memcache 或是 表折分，或是搜索引擎。都是解决方法。 4、主从复制与读写分离 在实际的生产环境中，对数据库的读和写都在同一个数据库服务器中，是不能满足实际需求的。无论是在安全性、高可用性还是高并发等各个方面都是完全不能满足实际需求的。因此，通过主从复制的方式来同步数据

在今天的文章中，我们来详细地描述如果使用Filebeat把MySQL的日志信息传输到Elasticsearch中。为了说明问题的方便，我们的测试系统的配置是这样的： 我有一台MacOS机器。在上面我安装了Elasticsearch及Kibana。在这个机器里，我同时安装了一个Ubuntu 18.04的虚拟机。在这个Ubunutu机器上，我安装了MySQL及Filebeat。它们的IP地址分别显示如上。针对你们自己的测试环境，你们的IP地址可能和我的不太一样。 准备工作 安装Elasticsearch 如果大家还没安装好自己的Elastic Stack的话，那么请按照我之前的教程“ 如何在Linux，MacOS及Windows上进行安装Elasticsearch ” 安装好自己的Elasticsearch。由于我们的Elastic Stack需要被另外一个Ubuntu VM来访问，我们需要对我们的Elasticsearch进行配置。首先使用一个编辑器打开在config目录下的elasticsearch.yml配置文件。我们需要修改network.host的IP地址。在你的Mac及Linux机器上，我们可以使用: $ ifconfig 来查看到我们的机器的IP地址。针对我的情况，我的机器的IP地址是：192.168.0.100。 我们也必须在elasticsearch