mongodb数据库迁移？如何备份,还原和迁移MongoDB数据库
大家好，今天给各位分享mongodb数据库迁移的一些知识，其中也会对如何备份,还原和迁移MongoDB数据库进行解释，文章篇幅可能偏长，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在就马上开始吧！
如何将MongoDB数据库的数据迁移到MySQL数据库中
在项目开发中，有时由于项目开始时候使用的数据库是SQL Server，后来把存储的数据库调整为MySQL，所以需要把SQL Server的数据迁移到MySQL。下面是小编日常整理的一种sqlserver数据库迁移的方法。
一、SQL Server中常用数据类型与MySQL不同的地方
二、将SQL Server数据迁移到MySQL需要注意的一些问题
1、唯一索引的不同，sql server的唯一索引的字段只能允许存在一个null值，而mysql，一直oracle中唯一索引对应的字段都允许存在多个null值。
2、存储过程的语法存在很大的不同，存储过程的迁移是最麻烦的，需要仔细修改。
3、程序中部分写的SQL语句由于语法的不同也要相应的修改。
三、将SQL Server数据迁移到MySQL的常见方法
1、使用 SQLyog迁移
如何备份,还原和迁移MongoDB数据库
mongodump是mongodb提供的用于创建数据库备份的实用程序。这是一个非常有用的实用程序，可以考虑非常有效地为实时服务器数据库进行备份。对于数据库还原，需要使用mongorestore命令。
1、备份mongodb数据库（mongodump）
有多种备份MongoDB数据库的方法。使用mongodump命令进行所有数据库备份、单个集合备份或者单个数据库备份。
备份单个数据库
使用此命令仅备份单个数据库（名为mydb）。将在/backup/db/目录中创建备份。
$ mongodump--db mydb--out/ backup/ db/-db-要备份的数据库名称
-out-数据库备份位置。这将创建具有数据库名称的文件夹。
可以为远程数据库连接备份指定主机，端口，用户名和密码，如下所示。
$ mongodump--host 10.0.1.7--port 27017--username admin--password somepassword--db mydb--out/ backup/ db/备份所有数据库
要备份所有数据库，只需按以下命令运行即可。这里/ data/ db/是你的mongodb数据目录的位置，/ backup/ db是备份目录的位置。
$ mongodump--out/ backup/ db/可以为远程数据库指定主机，端口。
备份单一集合
此命令将从数据库中备份单个集合。备份文件将在dump/ mydb/目录中创建。
$ mongodump--collection mycollection--db mydb--out/ backup/ db/2、使用mongorestore恢复MongoDB数据库
mongorestore是用于恢复mongodb数据库备份的命令行工具。这里/ data/ db/是你的mongodb数据目录的位置，/ backup/ db是备份目录的位置。
$ mongorestore--db mydb--drop/ backup/ db/ mydb-drop-如果已经存在，将删除数据库。
只需将备份文件移动到远程服务器并在那里运行相同的命令即可恢复备份。
3、MongoDB备份Shell脚本
可以在调度程序中轻松安排以下脚本，以定期备份数据库。创建如下文件
$ vi/backup/mongo-backup.sh将以下内容添加到文件中。相应地更新数据库主机名，数据库名称，用户名和密码。
#!/bin/sh
TODAY=`date+%d%b%Y`
BACKUP_DIR=/backup/db
mkdir-p${BACKUP_DIR}/${TODAY}
mongodump-h<DATABASE_HOST>-d<DATABASE_NAME>-u<USERNAME>-p<PASSWRD>--out${BACKUP_DIR}/${TODAY}/现在在crontab中配置它以便每天运行。
0 2***/backup/mongo-backup.sh本篇文章到这里就已经全部结束了，更多其他精彩内容可以关注PHP中文网的MySQL视频教程栏目！
为什么我从MongoDB迁移到PostgreSQL
我的第一个以 MongoDB作为主数据库开发的网站是 codecampo.com（2011年），第二个是 writings.io（2013年）。Campo在第 3版的时候重写（2014年）迁移到 PostgreSQL，而 writings.io已经关闭了，现在正在做的创业项目 selfstore.io也是使用 PostgreSQ
我的第一个以 MongoDB作为主数据库开发的网站是 codecampo.com（2011年），第二个是 writings.io（2013年）。Campo在第 3版的时候重写（2014年）迁移到 PostgreSQL，而 writings.io已经关闭了，现在正在做的创业项目 selfstore.io也是使用 PostgreSQL。PostgreSQL已经成为我的默认数据库，鉴于我曾经做过一段时间 MongoDB布道者，所以我想有必要总结一下。
我开发维护的都是流量很小的网站，所以不用期待我分享千万级数据管理的经验（我以前正式工作中倒是接触一个千万级使用 MySQL的网站，但优化工作不是我做的）。我也不会犯一些低级错误，例如项目开发到一半才困惑“MongoDB没有 JOIN查询怎么办？”，选型时已经知道将要面临怎样思维转换。
我不希望这篇文章被当作是“XX已死，YY永生”一类的噱头文章，这类文章大多带有偏见，并且对评论对象浅尝辄止。不同的工具有不同的应用场合，不能一概而论。
我从 MySQL转向 MongoDB，以及从 MongoDB转向 PostgreSQL的最大原因都是：有趣。Web开发一个优点就是你不用限定在某个平台某类技术上，最终用户看到的都是 HTML页面。
下面是一些我选择数据库的经验。
MongoDB优点
无模式
无模式是个双面刃。好的方面，它可以减少表的空余字段，减少拆表的必要，例如用户集合可以一条记录带有 admin: true属性，其他不带有这个属性，而在关系数据库中这类带来大量空余字段的属性最好拆表。PostgreSQL打开 HStore扩展后也可以实现这样的结构。如果觉得 admin: true的例子太简单，可以考虑下怎么储存 gemspec的内容并让它可索引。
无模式另一个好处是让代码逻辑管理起来更清晰，可以把属性定义和模型逻辑放在一起：
class Artist
include Mongoid::Document
field:name, type: String
end
类似 DataMapper的库虽然也能实现这样的语法，但始终需要维护一个迁移脚本，需要重复自己。用 Mongoid的时候我一直觉得打开 Model文件先看到属性定义很舒服。
无模式的最大坏处就是无法真正掌握数据库中有什么内容，实际上并不是经常需要储存无模式数据，多数是模式化数据。所以即使不需要管理模式迁移，还是要管理数据迁移，每次更改属性相关逻辑时要写数据迁移脚本。这里无模式是好是坏取决于应用场景。
数据类型
MongoDB支持的数据类型多于 MySQL，其中最主要是 Array，Hash类型。PostgreSQL原生或通过扩展可以支持 Array和 Hash，但是配套的操作不够 MongoDB简便。
例如 MongoDB对 Array有一个$addToSet方法，只有数组不存在某元素时进行插入：
update($addToSet:{ upvotes_ids: 1})
而 PostgreSQL要进行同样操作需要组合一些语句：
SET upvotes_ids= array_append(upvotes_ids,1) WHERE NOT(upvotes_ids@>array[1])
MongoDB的语句更简洁，也不排除 PostgreSQL以后也会添加同样的方法。
MongoDB缺点
不支持事务
也许需不需要数据库事务成了是否选择 MongoDB的决定性因素，MongoDB不支持数据库事务。
有很多应用对数据一致性其实要求不高，例如很多社交应用，大多数应用逻辑只是简单存取（发一段文字，上传一张照片），极少的不一致是不影响应用的。而一些严肃应用，例如交易系统，就很需要数据库事务的支持了，否则就需要在应用层自己实现一个粗糙的、充满 Bug的事务支持。如果有兴趣自己实现事务操作，可以看 MongoDB的文章 Perform Two Phase Commits。
如果有跨系统的事务操作，就不能完全依赖数据库事务，还要有应用层的重试或回滚操作（例如远程调用支付接口）。数据库层面支持事务的话，起码让维护系统内部数据一致性更轻松。
查询语法
MongoDB的原生查询语法是 JavaScript，JavaScript程序员可能对此欣喜若狂。我最初感觉也是很新鲜，但久了就觉得很烦躁。JavaScript太多的括号和花括号，在组合多个查询条件的时候作括号匹配很费神。SQL是一个查询 DSL，虽然看起来有点古老，但是在查询这个特定领域上做得很好。
如果应用使用 ORM，可能很多时候不需要写原生查询语句。除了 PHP社区外，其他社区也不推荐写原生查询。不过少数情况下，复杂查询还是原生语句更高效，而且数据库终端也是调试查询错误的最终手段，所以查询语法至少不能让人难受。
默认不安全
MongoDB的开发者假设你是一个资深系统管理员，并且把 MongoDB部署在安全的内部网络当中，所以他们官方安装包内含的配置没有设置任何安全验证，接收任何来源的访问，结果就是一些初级系统管理员（例如我）把 MongoDB直接暴露到了公网，造成数据泄漏。
这不仅是 MongoDB的问题，Redis、Elasticsearch也是这样，姑且把这认为是一种设计“哲学”。Ubuntu的软件源管理者不认同这个“哲学”，从软件源安装的 MongoDB的默认只接受本地连接，这保护了一些初级系统管理员，但如果追新使用数据库开发方的安装包就会中招。顺便一提，PostgreSQL默认配置只接受本地连接。
无论用什么数据库都好，使用前一定要完整读一遍文档，特别是设置和安全相关的章节，同时设置系统防火墙。
库
MongoDB的官方驱动更新没有问题，不过一般不会直接使用驱动写程序（写过，很繁琐），而是使用 ODM（对象-文档映射）工具，在 Ruby中就是 Mongoid。
Mongoid已经做得很好，提供了类似 ActiveRecord的 API，并且很好的利用了 MongoDB的特性，但在关注度和社区规模上还不及 ActiveRecord。ActiveRecord作为 Rails的默认组件，每次都是跟随 Rails的更新同时更新的，Mongoid则要滞后一段时间。所以如果你希望紧跟 Rails的更新，那么最好使用 ActiveRecord和关系数据库。
为什么是 PostgreSQL而不是 MySQL/MariaDB
今年开始，我的精力投入到一个交易网站的开发，所以一开始就打算迁移到关系数据库。至于为什么用 PostgreSQL而不是 MySQL/MariaDB，有几个理由：
有趣，我还没用过 PostgreSQL。
PostgreSQL的数据类型更多，我主要需要 Array和 HStore。这些数据类型可以减少开发量，在 MySQL实现 Tag属性需要多两张表。
过去的工作中让我接触到 MySQL不好的一面，例如因为 JOIN性能不好（我没验证过），不允许用 includes方法，基本上只做主键查询，所以我之前那么容易接受 MongoDB。
MySQL被 Oracle收购后社区出现分裂（MariaDB），我对 Oracle印象也不好，前公司旗下一个网站因为域名带有 Java而收到律师函，所以我尽可能避开 Oracle的产品。
PostgreSQL的社区热度在增加，ActiveRecord对其特性的支持也在完善。
基于以上理由，我选择了 PostgreSQL，目前为止工作得很好。
这几年间我接触了 3个数据库（不包括 Redis的话），SQL-NoSQL-SQL的切换让我对数据库有了更深刻的理解，也认识到还有很多类型数据库我没试过，关系数据库不是唯一选择。我的几个项目都是只是玩具规模，没什么说服力，但以免被误解，还是提几条建议：
如果当前数据库用得很好，就没必要更换。
如果没有明确的数据库需求，那么用关系数据库。
如果要开发新的项目，推荐 PostgreSQL。
最终，选择要取决于你的应用场景。
原文地址：为什么我从 MongoDB迁移到 PostgreSQL,感谢原作者分享。
好了，关于mongodb数据库迁移和如何备份,还原和迁移MongoDB数据库的问题到这里结束啦，希望可以解决您的问题哈！