ITPub博客

1.收到大量应用告警Could not retrieve cluster information. CLUSTER NODES returned with error.  - 172.23.17.57:6379 failed: Hostname must&n

mark一下

mark一下，写得很好https://www.cnblogs.com/ivictor/p/5979731.html

首先需要查看mysql的当前时区,用time_zone参数mysql> show global variables like '%zone%';+------------------+--------+| Variable_name    | Value  |+------------------+--------+| system_time_z

图画的很漂亮，说的也比较清除，mark一下

需求，现在需要将一个单机redis数据迁移至redis-cluster集群中，两遍都是开启了密码模式的，无密码模式直接import就可以了！现在带密码我试了下import工具发现并不支持密码模式，修改下redis-trib.rb脚本即可支持密码认证了修改地方为：def import_cluster_cmd(argv,opt)     source

1.收到150告警，rdb持久化失败15011:M 17 Sep 08:54:43.037 # Can't save in background: fork: Cannot allocate memory 15011:M 17 Sep 08

背景：不知道怎么搞得，某个复制集只剩一个secondery节点了，现在需要快速恢复复制集对外提供服务解决办法：1.将剩余的second节点修改配置文件为单节点模式，并且注释掉auth权限认证2.启动单节点并删除复制集信息use local db.system.replset.remove({"_id":"repset"});3.重新将单节点修改为

现有个需求是redis-cluster到redis-cluster的快速迁移，并且迁移过后两套redis-cluster都要独立使用无依赖方法一：使用前面redis迁移中的在线迁移工具redis-migration（劣势：不支持redis4.0） redis-migration-tools（劣势：不支持redis4.0） redis-sync-manage：redis-port封装版本（（劣势

在上一篇文章《MySQL 5.7中如何定位DDL被阻塞的问题》中，对于DDL被阻塞问题的定位，我们主要是基于MySQL 5.7新引入的performance_schema.metadata_locks表。提出的定位方法，颇有种"锦上添花"的意味，而且，也只适用于MySQL 5.7开始的版本。但在实际生产中，MySQL 5.6还是占绝不多数。虽然MySQL 8.0都已经GA了，但

更新字段为另一字段的值db.postMongo.find(过滤条件).forEach(   function(item){                        db.postMongo.update({"_id":ite

背景：现将hive 数据从aws迁移至阿里云1.登录目前hive，导出数据源端导出数据 export table collection_server to '/tmp/collection_server' ; 查看 [hadoop@ip-172-31-33-52 tmp]$ hadoop fs

文章目录摘要： MySQL的瓶颈，一般分为IO密集型和CPU密集型 CPU出问题的情况比较少，最近就遇到过一次比较大的故障，这个话题后面会有一篇专题介绍 今天主要聊聊IO密集型的应用中，我们应该如何快速定位到是谁占用了IO资源比较多 背景 环境1.MySQL的瓶颈，一般分为IO密集型和CPU密集型CPU出问题的情况比较少，最近就遇到过一次比较大的故障，这个话题后面会有一篇专题介绍今天主要

原文地址：https://mp.weixin.qq.com/s/lD2gjyUgt4pmWdVXqqXk3w在上篇文章《MySQL表结构变更，不可不知的Metadata Lock》中，我们介绍了MDL引入的背景，及基本概念，从“道”的层面知道了什么是MDL。下面就从“术”的层面看看如何定位MDL的相关问题。在MySQL 5.7中，针对MDL，引入了一张新表performance_schema.me

1 示列代码如下# -*- coding: utf8 -*- from aliyunsdkcore.client import AcsClient from aliyunsdkcore.acs_exception.exceptions import ClientException from&n

背  景某运营商搭建了一套 MongoDB 集群，承载了大大小小的几十个非计费类应用，1亿左右的用户量，随着访问量的增加，业务繁忙时期偶尔出现连接拒绝的错误。分  析为了搞清楚原因，先从mongo访问数据库的模式说起，如下图：我们发现客户端的请求是通过驱动连接到mongos或mongod的。如果有多个实例化的MongoClient，那么就会有多个对应的连接池

aof迁移开启现有 Redis 实例的 AOF 功能（如果实例已经启用 AOF 功能则忽略此步骤）。 # redis-cli -h old_instance_ip -p old_instance_port config set appendonly&nbsp

MongoDB从3.0开始引入可插拔存储引擎的概念。当前，有不少存储引擎可供选择：MMAPV1、WiredTiger、MongoRocks、TokuSE等等。每个存储引擎都有自己的优势，你需要根据性能要求及应用特征挑选最适合的一个。从3.2.x开始，WiredTiger成为默认的存储引擎。最为MongoDB目前最流行的存储引擎，WiredTiger与原先的MMAPV1相比有以下优势：性能&

大于等于3.2按这种写法[root@ip-172-31-33-43 conf]# more shard1.conf # where to write logging data.systemLog:  destination: file  logAppend: true  path: /data/shard1/log/shard1.log # ...

针对新版itpub系统做的备份博客脚本