好记忆也需烂博客

回到服务器查询，发现MongoDB 版本是 4.0.2 (很多服务器我已安装了4.2.8 版本，开始没想到还有一台旧服务器还是4.0.2)查询问题：当 maxDistance 参数加大时，返回值并不会变大，但在不用地图点距离进行查询时，是可以返回更多值的。查找了很多资料，当看到D 4.2 版本官方资料中提到$limit 参数已取消时，怀疑可能是版本问题。（limit 默认值为100，但返回值在50左右后，就不返回更多值，所以开始也没往这里想）

部署 MySQL -> ES 数据同步（mysql 同步到 ES 是支持 多表查询 后把结果同步到ES 中的同一个索引中的）1.服务器：内网ip：192.168.0.60登录name+key实现功能： canal、kafka、es7；canal同步预生产polardb数据到es72.ES7 kafka服务es web 管理url：http://[internet ip]:9800es:公网： [internet ip] 9201内网： 192.168.0.60 9201kaf

**elasticsearch7.9.2 安装配置**1.downloadwget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.9.2-linux-x86_64.tar.gz查看日志：curl 172.16.1.204:9200/_cat/nodes?v2、JDK环境配置。。。省略注意：ElasticSearch对jdk版本要求很严格，我用的jdk11对应ES7.23、修改配置文件：/opt/es

**概述**现在的项目数据量越来越大，全文检索功能使用场景也越来越普遍。而我们一般的生产数据是在mysql，或其它一些数据库，我们的产品数据就是mysql,而又要使用全文检索，所以要把mysql 数据同步到es,再进行全文检索功能。现在简单把数据同步的配置及遇到的问题罗列如下:数据流程图mysql -> adapter -> es安装步骤不再累述，需要安装以下软件。1.安装 es,2.安装 canal.adapter3.安装 canal.deployer4.安装 zo

MongoDB数据量大于2亿后遇到的问题 及原因分析一、数据增长情况    每月增长量最大达到了1.9亿，每天增长约300W-500W    （增长数据具体可看页尾）二、遇到的情况及解决方法    1.数据量过大，并且都集中在一个表，所以此表数据插入变慢。        表索引越多越明显，        优化处理方法：        

集群节点间的延迟问题mongoDB 一个弱点，就是最终一致性，这也是所有NoSQL 的一个问题。在CAP 理论中，数据库在 (C)onsistency、(A)vailability和(P)artition-tolerance三者只能满足两个。比如MongoDB 有更好的 高可用性，分布式。就不可避免的牺牲了 [一致性]前段时间开发组的反映说一条记录在插入后，再查询，没有

环境：4个分片，各个分片3个节点。6台服务器，每台服务器都有2-3个 MONGOD （或 mongos) 进程计划把硬盘，内存及MongoDB 从3.0.3 升级到 3.2.8                                         方法：新添加了一台服务器，逐步把每台机子进行硬盘，内存添加，再安装系统，再从要升级的服务器中，拷贝数据文件

ObjectId("52cbab42231dea1e819b2a37"),ObjectId("52cbab5b231dea1e819b2a38"),ObjectId("52cbab70231dea1e819b2a39

使用mongoDB 是从2.4 版本开始的，但那时的权限管理相对比较简单。也就没有去弄这个。现在再回头看几个版本的权限管理，看到各个版本间都在变化。并且集群与单机也有很大的不同，下面是以2.6版本来简单配置了一个环境进行测试。建立一个集群环境： config={_id:'test1',members:[{_id:0,host:'192.168.2.11

环境：mongoDB2.6.8 集群，下午突然发现4个从节点，挂了3个，全都都出现以下提示：2016-03-11T16:53:02.483+0800 [conn312773] Assertion: 13548:BufBuilder attempted to grow() to 134217728 bytes, past the 64MB limit.经分析， [conn3127

一个关于使用 $month，$dayOfMonth 进行按月/日统计的BUG情景如下：按月，日进行统计分组：db.test_tbl.aggregate([{"$match":{"CreateTime":{$gte:ISODate("2016-03-10T00:00:00.000+0800"),$lt:ISODate("2016-03-11T00:00:00.000+08

MongoDB本身不支持增量备份，所以这里介绍几种我找到的，或者是自己使用代码实现的方法：我的环境：集群环境，如果是分片集群，只好各【分片集群】和【配置服务器集群】分开备份处理，因为使用了Oplog 所以不适合单机环境一、 Delay server + Oplog replay(延迟节点+Oplog 重现)二、使用mongosync 同步工具，    它的功能有：

mongodb  索引建立问题1.主从库索引建立不是同步建立：    MONGODB 2.6.6 版本，索引建立并不是同步的，而是主库建立完成后，从库接着建立索引。    不知是3.0版本是否也一样，以前使用3.0版本也没去监控主从日志情况。这坑太大了。    5：00开始建立，以为主库完成即OK.        官方说明：        Backg

特点：         1. 键值存储， 内存 + 闪存(SSD) 存储数据，官方从诺查询 速度99% 达到1ms          2. 数据结构相对简单（意思是说没有REDIS丰富）          3.可以把索引放在内存，数据放在SSD。          4.与纯内存数据库（如REDIS,SSDB)对比，扩展上性价比会高些（SSD的价格还是比内存便宜的）

关于从节点 延迟的测试：使用手工设置延迟时间的方法，在两个数据库中测试了主从 写/读的延迟时间，主从节点的延迟时间大约 在 0.3秒 。这个测试比我想象中的要大很多，开始以为延迟也就在10 -30 毫秒左右或许这个测试只能说： ”延迟0.3秒后，能在从节点中查询到所插入的数据比例越大“ 更贴切点。如果是插入后要即刻返回数据的，暂时只能指定从主节点读取数据。

> db.serverStatus();{    "host" : "localhost.localdomain", --hostname    "version" : "2.4.9",        --版本    "process" : "mongod",        --进程名称    "pid" : 5099,            --进程ID    "upti

Mongo3.0  开始包含了支持B+和LSM的 Wired Tiger引擎。许多关系数据库可以配置索引结构，使用不同的文件格式。这里对几种存储引擎做一个比较，以加深了解：1、Hash存储引擎代表数据库：redis、memcache等通常也常见于其他存储引擎的查找速度优化上。 Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tr

SQL Terms, Functions, and Concepts                                      MongoDB Aggregation OperatorsWHERE                               $matchGROUP BY

mongodb与mysql命令对比传统的关系数据库一般由数据库（database）、表（table）、记录（record）三个层次概念组成，MongoDB是由数据库（database）、集合（collection）、文档对象（document）三个层次组成。MongoDB对于关系型数据库里的表，但是集合中没有列、行和关系概念，这体现了模式自由的特点。 MySQL

使用Prometheus+Grafana 监控MySQL/MONGODB 之前就久仰 Prometheus 大名，因为有用zabbix 进行监控，就没去安装它。现在正好用上监控MONGO+MYSQL。服务器端组件： prometheus #服务端alertmanager #预警Grafana #前端展示，客户端组件： node_exporter

现有方法：          开始时间 [@start_dt ]   结束时间 [@end_dt ]         其它条件 [      ]查询数据总量：[XXXX]

在同一个集群中，两个从节点 db117,db118 都各出现了1次 “serverStatus was very slow” db117出现 very slow:2017-09-14T18:55:49.599+0800 [conn13113916] serverStatus was very slow: { after basic: 0, after asserts:

Elastic search(ES) is a pop-star for recording and analyzing data, andMongodb is a famous NoSQL database for storing and querying data. With our web infrastructure improving, how can we export dat

Dataguru培训

一个日志库数据量过大，以前3.2 版本的MongoDB oplogsize=50G 也没法初始化新节点。在把版本升级到3.4,磁盘选择高效云盘后。再做新节点初始化数据同步。时间已从以前的3天多，到现在的15小时左右了。主是节省的时间是在索引建立这块。数据同步时，索引也在处理，oplog 数据也在同时同步。以下是分析日志的一点观点，因只是基于日志，可能有不足之处。看过源码的

以下内容是有关MongoDB的单个集合在硬件和软件上的限制。BSON文档单个Bson文档最大为16M。该限制是为了保证单个文档不会占用过多RAM、在网络传输过程中不会占用过多带宽。MongoDB提供了GridFS来保存超过该限制的文档。具体可参考mongofiles。Bson文档的最深内嵌深度为100。 命名空间(namespaces)每个命名空间长度必须小于123 byt

redis 3 集群安装配置

mongodb config server

调整原因：1.原有分片是两个SECONDARY，查询时开发人员也很少设置成const string RP_SECONDARY = "secondary" ;const string RP_SECONDARY_PREFERRED = "secondaryPreferred" ;此类读优化2.昨天出现误操作，把一个表的部分数据删除了。3.正好手头上多了一台用来备份的

[mongo@localhost ~]$ cat mongo_back.sh#!/bin/sh#su - oraclesource /home/mongo/.bash_profile#lock db/opt/mongodb/mongodb-linux-x86_64-2.5.5/bin/mongo-start.sh  db.fsyncLock()EOF

MongoDB 常用故障排查工具1.profileprofiling levels：         0,关闭profile；1，只抓取slow查询；2，抓取所有数据。启动profile并且设置Profile级别：     可以通过mongo shell启动，也可以通过驱动中的profile命令启动，启动后记录会被保存在system.profile collecti

我们在设计表结构时，往往会自己加一个字段，记录数据生成时间，比如我会建议一个 create_dt 其实在mongodb 中，如果你使用了默认的 _id ，且你要记录的时间只要到秒级。那这个字段是没有必要的。可以从 字段 _id中得到此日期时间。下面的_id 字段的内容，大家都知道的：01234567891011

问题： 今天PHP 测试端出错。不知是否为1.vi /etc/rc.local#!/bin/sh## This script will be executed *after* all the other init scripts.# You can put your own initialization stuff in here if you don't

在查询一个表的数据时发现查询返回的数据中_id 字段的值的排序是乱的。并没有按整数数据进行排序，这里做一些说明:  在MONGODB 中，如果没有加sort，返回的是数据原始存储的顺序，和下面的代码一致： db.test.find().sort({$natural:1}) （原始存储顺序） 而指定排序顺序如下：db.test.find().sort({_

在学习MONGODB 遇到以下问题：函数 getNextSequence 生成序列号，官方方法：建立一张表，记录某一个表的_ID 当前值。后面调用此函数生成下一个序列号，在测试此函数时，遇到以下问题：(url:http://docs.mongodb.org/manual/t ... incrementing-field/)> function getNextSe

1.1 修改配置文件         [root@ractdg3 redis-2.8.4]# cp redis.conf redis_master.conf        [root@ractdg3 redis-2.8.4]# cp redis.conf redis_slave.conf        [root@ractdg3 redis-2.8.4]# vi redis_slave

象我这样使用了关系型数据库很长时间的码农来说，对一些新的数据类型，比如：集合，链表，的使用场景，感到有种莫名的恐惧。不知有什么用。在这里，我把几种REDIS数据类型的应用场景 文章转载如下：Redis中7种集合类型应用场景-------------------------------------------------------------------------

安装repcached，并且测试其双向复制是否成功，抓图安装和测试过程作为作业内容提交 1.安装libevent-devel包[root@ractdg3 nosql]# tar zxvf libevent-1.4.13-stable.tar.gz[root@ractdg3 nosql]# cd libevent-1.4.13-stable[root@ractdg3 libeve

安装redis，使用一种你熟悉的高级语言（例如ruby，python等）在redis里创建数据并成功访问作为测试=======================================================================================================1.安装    [root@ractdg3 downl

Resid命令参考：http://redis.readthedocs.org/en/latest/index.html连接操作相关的命令quit：关闭连接（connection）auth：简单密码认证持久化save：将数据同步保存到磁盘bgsave：将数据异步保存到磁盘lastsave：返回上次成功将数据保存到磁盘的Unix时戳shundown：将数据同步保存到磁盘