mysql集群

1.测试MySQL连接 bin/sqoop list-databases --connect jdbc: mysql://192.168.1.187:3306/trade_dev --username 'mysql' --password '111111' 2.检验SQL语句 bin/sqoop eval --connect jdbc: mysql://192.168.1.187:3306/trade_dev --username 'mysql' --password '111111' --query "SELECT * FROM TB_REGION WHERE REGION_ID = '00A1719A489D4F49906A8CA9661CCBE8'" 3.导入hdfs 3.1 导入 bin/sqoop import --connect jdbc: mysql://192.168.1.187:3306/trade_dev --username 'mysql' --password '111111' --table TB_REGION --target-dir /sqoop/mysql/trade_dev/tb_region -m 5 --columns "code,name,category,farthercode,visible,regionlevel,region_id"

本文源码： GitHub·点这里 || GitEE·点这里 一、服务器性能简介 1、性能定义 服务器性能优化是一项非常艰巨的任务，当然也是很难处理的问题，在写这篇文章的时候，特意请教下运维大佬，硬件工程师，数据库管理，单从自己的实际开发经验来看，看待这个问题的角度起码是不全面的。 补刀一句 ：在公司靠谱少撕逼，工程师这个群体是很好交朋友的，互相学习一起进步，升职加薪他不好吗？ 服务性能定义：完成一个任务或者处理一次接口请求所需要的时间，这个时间是指响应完成时间，即请求发出，到页面响应回显结束，这是看待性能问题的基本逻辑。 2、分析性能 服务的基本过程一般如下图，这是一张最简单的前后端分离，加一台数据库存储的流程，但是想要说明一个复杂的逻辑。 从页面请求，到获取完整的响应结果，这个过程每个环节都可能导致性能问题，抛开网络，硬件，服务器，MySQL存储这些核心客观因素，单是下面这行代码就可以秒掉很多人的努力。 Thread.sleep(10000); // 仿佛整个世界都安静了。 影响性能的因素很多，一般说性能优化会从下面几个方面考虑： 网络传输，比如私有云和公有云的交互，接口传输内容过大； 应用服务，接口设计是否最简，没有逻辑问题，架构设计是否合理； 存储服务，MySQL的查询写入，表设计是否合理，连接池配置是否合理； 硬件设施，CPU和内存的利用是否在合理区间，缓存是否合理；

1、系统管理 1.1 连接MySQL 　　格式 ： mysql -h主机地址 -u用户名 －p用户密码 　　举例 ： 　　例1 ：连接到本机上的MySQL。 　　首先在打开DOS窗口，然后进入目录 mysqlbin，再键入命令"mysql –u root –p"，回车后提示你输密码，如果刚安装好MySQL，超级用户"root"是没有密码的，故直接回车即可进入到MySQL中了，MySQL的提示符是： mysql>。 　　例2 ：连接到远程主机上的MYSQL。假设远程主机的IP为：110.110.110.110，用户名为root，密码为abcd123。则键入以下命令： mysql -h 110.110.110.110 -u root –p abcd123 　　备注 ：u与root可以不用加空格，其它也一样。 　　退出MySQL命令： exit （回车）。 1.2 修改新密码 　　格式 ：mysqladmin -u用户名 -p旧密码 password 新密码 　　举例 ： 　　例1 ：给root加个密码ab12。首先在DOS下进入目录mysqlbin，然后键入以下命令： mysqladmin -u root -password ab12 　　备注 ：因为开始时root没有密码，所以-p旧密码一项就可以省略了。 　　例2 ：再将root的密码改为djg345。 mysqladmin -u

欢迎观看 {无双}(wushuang) 的读书笔记，您可以通过订阅 无双的公众号或微博或头条号 持续关注最新的文章。 头条号ID：1656865998770190 微信公众号：落叶飞翔的蜗牛 开源中国博客： https://my.oschina.net/zhouguanya QQ：3190976240 MySQL数据库区别于其他数据库的最重要的一个特点是其插件式的存储引擎。 MySQL各类存储引擎 InnoDB存储引擎 从MySQL数据库5.5.8版本开始，InnoDB存储引擎是默认的存储引擎。 InnoDB存储引擎支持事务，其设计目标主要是面向在线事务处理（OLTP）的应用。其特点是行锁设计、支持外键，支持类似于Oracle的非锁定读，即默认读取操作不会产生锁。 InnoDB通过使用多版本并发控制MVCC来获取高并发性，并且实现了SQL标准的4种隔离级别，默认为repeatable级别。同时，使用一种称为next-key locking的策略避免幻读现象的产生。除此之外，InnoDB存储引擎还提供了插入缓冲、二次写、自适应哈希索引、预读等高性能和高可用的功能。 对于表中存储的数据，InnoDB存储引擎采用聚集的方式，每张表的存储都是按照主键的顺序进行存放的。如果没有显示的在定义时指定主键，InnoDB存储引擎会为每一行生成一个6字节的ROWID作为主键。 MyISAM存储引擎

本文源码： GitHub·点这里 || GitEE·点这里 一、服务器性能简介 1、性能定义 服务器性能优化是一项非常艰巨的任务，当然也是很难处理的问题，在写这篇文章的时候，特意请教下运维大佬，硬件工程师，数据库管理，单从自己的实际开发经验来看，看待这个问题的角度起码是不全面的。 补刀一句 ：在公司靠谱少撕逼，工程师这个群体是很好交朋友的，互相学习一起进步，升职加薪他不好吗？ 服务性能定义：完成一个任务或者处理一次接口请求所需要的时间，这个时间是指响应完成时间，即请求发出，到页面响应回显结束，这是看待性能问题的基本逻辑。 2、分析性能 服务的基本过程一般如下图，这是一张最简单的前后端分离，加一台数据库存储的流程，但是想要说明一个复杂的逻辑。 从页面请求，到获取完整的响应结果，这个过程每个环节都可能导致性能问题，抛开网络，硬件，服务器，MySQL存储这些核心客观因素，单是下面这行代码就可以秒掉很多人的努力。 Thread.sleep(10000); // 仿佛整个世界都安静了。 影响性能的因素很多，一般说性能优化会从下面几个方面考虑： 网络传输，比如私有云和公有云的交互，接口传输内容过大； 应用服务，接口设计是否最简，没有逻辑问题，架构设计是否合理； 存储服务，MySQL的查询写入，表设计是否合理，连接池配置是否合理； 硬件设施，CPU和内存的利用是否在合理区间，缓存是否合理；

在Kubernetes中，几乎所有的概念，包括Master、Node、Pod、Label、Namespace、Volume等都可以看作是一种“资源对象”。 从这个角度上来说， Kubernetes是一个高度自动化的资源控制系统 ， 它通过对比etcd中保存的“资源期望状态”和当前环境的“资源实际状态” ， 以此来实现自动控制和自动纠错的功能。 1.Master Master是Kubernetes集群的控制节点，每个kubernetes集群至少有一个Master节点， 它负责整个集群的控制和管理 ，几乎所有的kubectl的命令都是同时Master节点来执行的。 Master节点也可以参与实际任务的执行，但是并不建议这样做，因为master节点必须保证高可用， 一旦master节点宕机，那么整个集群都会处于停滞状态。生产环境建议使用3台独立的服务器作为Master节点。 Master节点的主要组件包括：APIServer、Controller-Manager、Scheduler，还有kubelet、kubectl、etcd等组件。 这些组件会以进程的形式展开。 　　 APIServer ：整个集群的唯一入口，也是连接etcd的唯一入口，所有对资源对象进行的操作都必须通过这个组件来展开。 　　　　所有组件的操作也必须通过APIServer这个组件来实现。 　　 Controller

今天一位跨界老码农不知咋回事，兴奋过了头，一不小心把数据库给删掉啦，然后问我咋恢复，然后我告诉他基于 binlog 可以恢复，谁成想没有开启 binlog，最后只能躲在角落里伤心。 爱情 36 技系列，好久没更新啦，真是苦了追逐爱情系列的那些朋友们。 好了，请忘记上面的一切，因为我们的爱情故事系列又要更新啦。 自从 Java 那小子喜获 Python 菇凉的芳心之后，两人就迈入了柴米油盐酱醋茶的生活，但是锅碗瓢盆难免磕磕碰碰， 生活中吵吵闹闹甚是正常 。 不过每次小吵小闹，Python 菇凉都会忍不住想删除存储在 MySQL 上的旅途记忆（不是想删库，就是想跑路）。但是老话说的好：天上月亮圆圆的，小两口吵架总是闹着玩的，况且小两口没有隔夜的仇，所以每次花好月圆之时，Java 那小子总会凭自己精湛的技艺把 Python 菇凉放在 MySQL 上的记忆给恢复如初。 另外 Java 那小子为了帮助其他家庭能够快速重建美好记忆，考虑到家庭稳固，特意把秘诀分享给大家，希望大家拿去使用，估计会屡试不爽。 秘诀一： 记录日志，让你有迹可查 第一步：确认 binlog 日志是否处于开启状态 ？ show variables like 'log_%'; 第二步：开启 MySQL binlog 日志 首先找到 my.cnf 文件。 mysql --help | grep 'Default

下载 ssl101 的 安装包上传服务器对应安装目录 /usr/local 目录。 [root@localhost ~]# yum -y install openssl openssl-devel perl-Time-HiRes perl-DBD-MySQL.x86_64 perl-IO-Socket-SSL.noarch [root@pxc2 ~]# rpm -ivh libev-4.15-1.el6.rf.x86_64.rpm warning: libev-4.15-1.el6.rf.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 6b8d79e6: NOKEY Preparing... ########################################### [100%] 1:libev ########################################### [100%] [root@pxc2 local]# yum install percona-xtrabackup-24-2.4.9-1.el6.x86_64.rpm -y Loaded plugins: fastestmirror, refresh-packagekit, security Loading mirror speeds from

根据文档搭建... https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-production-deployment.html 环境准备: 1 下载和安装需要的软件(本人的软件版本--都是mysql Community中的Linux Generic版本) mysql-server(mysql-8.0.17-linux-glibc2.12-x86_64.tar.xz) mysql-router(mysql-router-8.0.17-linux-glibc2.12-x86_64.tar.xz) mysql-shell(mysql-shell-8.0.17-linux-glibc2.12-x86-64bit.tar.gz) 安装(以mysql server为例，其他类似,以下都是Mysql_tar操作系统用户操作): cd /home/mysql_tar tar -xvf mysql-8.0.17-linux-glibc2.12-x86_64.tar.xz ln -s mysql-8.0.17-linux-glibc2.12-x86_64 mysql_install(方便升级) ...mysql-router... ....mysql_shell... 编辑环境变量: vim /home/mysql_tar/.bash

互联网已经发展多年，其中不乏脱颖而出者，这些网站多数都已存在了接近 10 年或 10 年以上，在如此长时间的发展过程中，除了业务上面临的挑战，在技术上也面临了很多的挑战。 我挑选了一些 Alexa 排名较前的网站 （ 排名截止到 2012 年 4 月 21 日），看看它们在技术上是如何应对业务发展过程中的挑战的。 Google 目前 Alexa 排名第 1 。它诞生于 1997 年，当时是一个研究性项目，每个月 build 一次索引， build 出来的索引通过 sharding （ shard by doc ）的方式分散到多台服务器（ Index Server ）上，具体的网页数据同样通过 sharding 的方式分散到多台服务器（ Doc Server ）上，当用户提交请求时，通过前端的一台服务器将请求提交给 Index Server 获得打了分的倒排索引，然后从 Doc Server 提取具体的网页信息（例如网页标题、搜索关键词匹配的片段信息等），最终展现给用户。 随着索引的网页增加，这个结构可通过增加 Index Server 以及 Doc Server 来存储索引以及网页的数据，但仍然会面临其他很多方面的问题，于是在这之后的十多年的时间里， Google 做了很多事情来改进上面的结构。 1999 年， Google 增加了一个 Cache Cluster ，用来