哪个平台可以复制大数据库，支持大数据传输的平台有哪些帮介绍几个

来源：整理时间：2024-01-17 06:59:30 编辑：黑码技术手机版

本文目录一览

1，支持大数据传输的平台有哪些帮介绍几个
2，数据库管理系统有哪些
3，如何用sql复制一个数据库
4，什么软件可以实现数据库备份
5，有什么可以把网站数据库COPY下来的小马
6，mysql能不能通过直接拷贝mysql文件夹的方式
7，如何复制大数据量的sqlserver
8，数据库怎么复制

1，支持大数据传输的平台有哪些帮介绍几个

如果是企业的话，可以直接买一个360企业云盘百度云云风速QQ传企业自己搭建数据平台

支持大数据传输的平台有哪些帮介绍几个

2，数据库管理系统有哪些

数据库管理系统软件（DBMS）有SYBASE、DB2、ORACLE、MySQL、ACCESS、Visual Foxpro、MS SQL Server、Informix、PostgreSQL等。1、SYBASE是一种典型的UNIX或WindowsNT平台上客户机/服务器环境下的大型数据库系统。 Sybase提供了一套应用程序编程接口和库，可以与非Sybase数据源及服务器集成，允许在多个数据库之间复制数据，适于创建多层应用。系统具有完备的触发器、存储过程、规则以及完整性定义，支持优化查询，具有较好的数据安全性。2、DB2DB2主要应用于大型应用系统，具有较好的可伸缩性，可支持从大型机到单用户环境，应用于所有常见的服务器操作系统平台下。 DB2提供了高层次的数据利用性、完整性、安全性、可恢复性，以及小规模到大规模应用程序的执行能力，具有与平台无关的基本功能和SQL命令。DB2采用了数据分级技术，能够使大型机数据很方便地下载到LAN数据库服务器，使得客户机/服务器用户和基于LAN的应用程序可以访问大型机数据，并使数据库本地化及远程连接透明化。 3、SQL ServerSQL Server 是Microsoft 公司推出的关系型数据库管理系统。具有使用方便可伸缩性好与相关软件集成程度高等优点，可跨越从运行Microsoft Windows 98 的膝上型电脑到运行Microsoft Windows 2012 的大型多处理器的服务器等多种平台使用。Microsoft SQL Server 是一个全面的数据库平台，使用集成的商业智能 (BI)工具提供了企业级的数据管理。Microsoft SQL Server 数据库引擎为关系型数据和结构化数据提供了更安全可靠的存储功能。4、AccessMicrosoft Office Access是由微软发布的关系数据库管理系统。它结合了 MicrosoftJet Database Engine 和图形用户界面两项特点，是 Microsoft Office 的系统程序之一。MS ACCESS以它自己的格式将数据存储在基于Access Jet的数据库引擎里。它还可以直接导入或者链接数据(这些数据存储在其他应用程序和数据库)。5、Visual FoxProVisual FoxPro简称VFP，是Microsoft公司推出的数据库开发软件，用它来开发数据库，既简单又方便。Visual FoxPro源于美国Fox Software公司推出的数据库产品FoxBase，在DOS上运行，与xBase系列相容。FoxPro原来是FoxBase的加强版，最高版本曾出过2.6。之后，Fox Software被微软收购，加以发展，使其可以在 Windows 上运行，并且更名为 Visual FoxPro。目前最新版为 Visual FoxPro 9.0，而在学校教学和教育部门考证中还依然延用经典版的 Visual FoxPro 6.0。

数据库管理系统有哪些

3，如何用sql复制一个数据库

creat table 新表 as (select * from 旧表);这样会新建一张表，并且把老表的所有数据导入新表。

如何用sql复制一个数据库

4，什么软件可以实现数据库备份

数据备份是数据容灾的最后一道防线，即便有着两地三中心的架构，备份也依然重要。如果备份出问题，备份时影响了交易业务，备份数据无法恢复，这些也是企业难以承受的。所以选择合适的备份工具尤为重要。每个企业级数据库都会有配套的备份工具，MEB(MySQL Enterprise Backup)就是MySQL企业版中非常重要的工具之一，是为企业级客户提供的数据备份方案。Xtrabackup一直作为MEB 开源版备胎而存在，从MySQL 8.0开始情况可能会变得有所不同。在 MySQL 8.0的Backup Lock、Redo Log Archiving、Page Tracking等新特性的加持下，MEB备份/恢复体验会更好，目前xtrabackup还不支持这些特性。MySQL 企业版还有哪些功能？特性1：Backup Lock8.0之前使用xtrabackup或MEB做物理备份，为了保证备份时InnoDB引擎表与其他引擎数据文件、及binlog日志的一致性会上全局读锁，再拷贝非InnoDB文件，这期间MySQL会变成只读，数据无法写入。表数量越多，可能加上时间越长，如果使用的xtrabackup 不小心没加rsync参数，逐个拷贝frm文件，锁定时间会更长，对业务影响较大。我曾遇到过部署在虚拟机的实例有12000多张表，当时使用的xtrabackup，备份脚本中没加rsync参数，结果锁了十几分钟，而MEB就没有这样的问题。MySQL 8.0支持轻量级备份锁 LOCK INSTANCE FOR BACKUP，数据字典也重构了由InnoDB存储。若不创建非InnoDB表，MEB默认使用备份锁获取binlog日志一致性位置，并阻止DDL操作，但不影响DML操作。只有InnoDB表，仅上备份锁请点击输入图片描述若有非InnoDB表，上全局锁请点击输入图片描述特性2：Redo Log ArchivingMEB能做到在线热备，备份时不影响数据库读写，这是利用了InnoDB事务日志，在备份期间持续监视redo log的变化，读取增量变化，写入到ibbackup_logfile，也就不需要上锁来保障备份一致性。(对非InnoDB的文件需要上读锁拷贝)如果备份期间数据库写入负载特别大，而写入ibbackup_logfile速度较慢，redo log size也不大，很可能会出现ibbackup_logfile的写入速度跟不上redo log记录生成速度，redo log 空间不够时需要覆写日志文件，那么来不及写入ibbackup_logfile的记录会丢失，导致备份失败。MEB 4.1对此做了优化，将redo log处理线程拆分成多线程分工合作，提高处理redo log的效率，降低了redo log覆写造成备份失败的概率，但redo log新增速度和ibbackup_logfile写入速度悬殊太大，问题依然会发生。MySQL 8.0.17支持了redo log archiving 彻底解决了此问题，备份前设置innodb_redo_log_archive_dirs，指定redo log归档目录。MEB备份时自动开启日志归档，当checkpoint时会将旧记录归档到此目录，后续从归档文件中读取redo日志记录，避免了覆写可能导致的redo记录丢失。请点击输入图片描述注意：innodb_redo_log_archive_dirs 不能在数据目录下，目录权限要求是700特性3：Page TrackingPage Tracking 是为优化增量备份效率，减少不必要的数据页扫描。增量备份当前有3种扫描模式：page-track：利用LSN精确跟踪上次备份之后被修改页面，仅复制这些页面，效率最快。optimistic：扫描上次备份之后被修改的InnoDB 数据文件中，找出并拷贝修改的页面。依赖系统时间，使用存在限制。full-scan：扫描所有InnoDB数据文件，找出并拷贝自上次备份之后修改的页面，效率最慢1、利用page-track增量备份，需先安装备份组件mysql> INSTALL COMPONENT "file://component_mysqlbackup";2、在全备前开启page-trackSELECT mysqlbackup_page_track_set(true);3、全备之后，做增量备份时指定若满足page tracking条件，默认会使用page-track模式，否则会使用full-scan模式，也可以指定--incremental=page-track。mysqlbackup --incremental-backup-dir=backup_incr --trace=3 --incremental=page-track --incremental-base=history:last_full_backup backupincremental-base有3种选择last_backup：基于前一次备份做增备，前一次备份可能是增备，也可能是全备。这种方式全备之间可能会有多个增备，每次增量可能比较小，但恢复时需要逐个合并。last_full_backup：基于前一次全备做增备。这种方式增备会越往后体积可能越大，但恢复时只需要合并最后一次增量备份。dir：基于前一次的备份目录，前一次备份可能是增备，也可能是全备。测试对比full-scan 和page-track ，在变更页小于总体50%的情况下，备份效率至少能有1倍的速度提升。page-track 模式磁盘读写均衡，说明读写的都是修改页面。请点击输入图片描述full-scan模式磁盘读写差别很大，说明读了很多未修改的页面。请点击输入图片描述

5，有什么可以把网站数据库COPY下来的小马

登陆后台先去上传个小马，提升权限，然后就可以获取源码。。。。源码里有链接数据库的配置信息，里面有用户名密码之类的。。。。。

关键你要搞清楚后台数据库的用户名/密码以及表结构，然后可以通过循环遍历的方式获取数据单纯的copy文件只能针对Access这种简单的单文件数据库，对于MSSQL Oracle这样的数据库是不起作用的

6，mysql能不能通过直接拷贝mysql文件夹的方式

每当我们讨论一项（新的）领域技术的时候，最好的方式通常是首先抛出一些问题，这些问题大致分为三类：诶？这项技术又是什么玩意（What）?这项技术为什么会存在？我们已经有那么多解决方案（Method）了，我们为什么要用它（Why）？如果这项技术那么好且我们正好有场景可以用到这项技术，且能使我们的系统得到很乐观的优化，那么我们怎么用呢（How）？大概已经有同学觉得这些问题很熟悉了，是的，这就是黄金全法则提出的三个问题，对于每种新鲜事物我们首先基于这三个问题去了解，更有利于弄清楚事情的本质，端正态度去了解，而不是因为新，因为大家都说好，才要去了解……。说了那么多前奏，我们可以开始了，今天我们就带着黄金圈法则提出的三个问题去看看MySQL数据库复制这项领域技术，然后再结合实际应用扩展一些问题，本文也仅仅是结合自己了解的皮毛以抛砖引玉的态度和大家一起分享。WHAT？MySQL复制使得一台MySQL数据库服务器的数据被拷贝到其他一台或者多台数据库服务器，前者通常被叫做Master，后者通常被叫做Slave。MySQL复制示意图复制的结果是集群（Cluster）中的所有数据库服务器得到的数据理论上都是一样的，都是同一份数据，只是有多个copy。MySQL默认内建的复制策略是异步的，基于不同的配置，Slave不一定要一直和Master保持连接不断的复制或等待复制，我们指定复制所有的数据库，一部分数据库，甚至是某个数据库的某部分的表。MySQL复制支持多种不同的复制策略，包括同步、半同步、异步和延迟策略等。同步策略：Master要等待所有Slave应答之后才会提交（MySql对DB操作的提交通常是先对操作事件进行二进制日志文件写入然后再进行提交）。半同步策略：Master等待至少一个Slave应答就可以提交。异步策略：Master不需要等待Slave应答就可以提交。延迟策略：Slave要至少落后Master指定的时间。MySQL复制同时支持多种不同的复制模式：基于语句的复制，Statement Based Replication（SBR）。基于行的复制Row Based Replication（RBR）。混合复制（Mixed）。WHY?这个问题其实也就是MySQL复制有什么好处，我们可以将复制的好处归结于下面几类：性能方面：MySQL复制是一种Scale-out方案，也即“水平扩展”，将原来的单点负载扩散到多台Slave机器中去，从而提高总体的服务性能。在这种方式下，所有的写操作，当然包括UPDATE操作，都要发生在Master服务器上。读操作发生在一台或者多台Slave机器上。这种模型可以在一定程度上提高总体的服务性能，Master服务器专注于写和更新操作，Slave服务器专注于读操作，我们同时可以通过增加Slave服务器的数量来提高读服务的性能。防腐化：由于数据被复制到了Slave，Slave可以暂停复制进程，进行数据备份，因此可以防止数据腐化。故障恢复：同时多台Slave如果有一台Slave挂掉之后我们还可以从其他Slave读取，如果配置了主从切换的话，当Master挂掉之后我们还可以选择一台Slave作为Master继续提供写服务，这大大增加了应用的可靠性。数据分析：实时数据可以存储在Master，而数据分析可以从Slave读取，这样不会影响Master的性能。HOW?这里我们只介绍一下MySQL的复制是如何工作的，至于配置，网上也有很多相关的介绍，读者具体应用的时候可以再去查阅。我们拿最常用的基于二进制文件的复制来看看。MySQL复制工作示意图请点击输入图片描述请点击输入图片描述MySQL的复制过程大概如下：首先，主库在每次准备提交事务完成数据更新操作之前都会将数据更改操作记录到二进制日志中，这些日志是以二进制的方式记录数据更改的事件。值得一提的是二进制日志中记录的顺序实际上是事务的提交顺序，而非SQL执行语句的顺序。在记录二进制日志之后，主库会告诉存储引擎事务可以提交了。然后，备库会启动一个IO线程，之所以叫做IO线程是因为这个线程专门做IO相关的工作，包括和主库建立连接，然后在主库上启动一个特殊的二进制转储线程，这个转储线程会不断的读取二进制日志中的事件，发送给备库的IO线程，备库的IO线程会将事件记录到中继日志中。备库会有一个叫做SQL的线程被开启，这个线程做的事情是读取中继日志中的DB操作事件在备库执行，从而实现数据更新。总的来说，在发生复制的主库服务器和备库服务器中，一共有三个线程在工作。上面我们已经大概了解的什么是复制？为什么要复制？如何复制？这三个问题了，接下来我们基于上面的介绍，提出一些实际应用可能会发生的问题来思考如何解决。博主自问自答的方式-。-问答环节问题一：通过复制模型虽然读能力可以通过扩展slave机器来达到提高，而写能力却不能，如果写达到瓶颈我们应该怎么做呢？答：我们首先会得出结论，这种复制模型对于写少读多型应用是非常有优势的，其次，当遇到这种问题的时候我们可以对数据库进行分库操作，所谓分库，就是将业务相关性比较大的表放在同一个数据库中，例如之前数据库有A，B，C，D四张表，A表和B表关系比较大，而C表和D表关系比较大，这样我们把C表和D表分离出去成为一个单独的数据库，通过这种方式，我们可以将原有的单点写变成双点写或多点些，从而降低原有主库的写负载。问题二：因为复制是有延迟的，肯定会发生主库写了，但是从库还没有读到的情况，遇到这种问题怎么办？答：MySQL支持不同的复制策略，基于不同的复制策略达到的效果也是不一样的，如果是异步复制，MySQL不能保证从库立马能够读到主库实时写入的数据，这个时候我们要权衡选择不同复制策略的利弊来进行取舍。所谓利弊，就是我们是否对从库的读有那么高的实时性要求，如果真的有，我们可以考虑使用同步复制策略，但是这种策略相比于异步复制策略会大大降低主库的响应时间和性能。我们是否可以在应用的设计层面去避开这个问题？问题三：复制的不同模式有什么优缺点？我们如何选择？答：基于语句的复制实际上是把主库上执行的SQL在从库上重新执行一遍，这么做的好处是实现起来简单，当前也有缺点，比如我们SQL里面使用了NOW()，当同一条SQL在从库中执行的时候显然和在主库中执行的结果是不一样的，注入此类问题可以类推。其次问题就是这种复制必须是串行的，为了保证串行执行，就需要更多的锁。基于行的复制的时候二进制日志中记录的实际上是数据本身，这样从库可以得到正确的数据，这种方式缺点很明显，数据必须要存储在二进制日志文件中，这无疑增加的二进制日志文件的大小，同时增加的IO线程的负载和网络带宽消耗。而相比于基于语句的复制还有一个优点就是基于行的复制无需重放查询，省去了很多性能消耗。无论哪种复制模式都不是完美的，日志如何选择，这个问题可以在理解他们的优缺点之后进行权衡。问题四：复制的工作过程只有三个线程来完成，对于Master来说，写是并发的，也就出现了一个IO线程要把所有并发的数据变更事件记录，这个IO线程会不会累死？当一个Master对应多个Slave的时候，其实在Master中会唤起多个IO线程，这无疑会增加Master的资源开销，如果出现事件堆积，也就是事件太多，来不及及时发送出去怎么办？另外就是Slave那边的IO线程和SQL线程也会有对应主库并发数据变更事件，而Slave方单个线程处理的问题，这个时候Slave线程会不会累死？答：上面的问题确实会发生，上面第一个问题和第二个问题其实是写负载的问题，当事件堆积太多，从库时延就会变大，Slave单SQL线程问题据说有参数可以开启并行操作，这个大家可以确认一下。问题五：针对复制工作过程可能会出现的问题，主库写完二进制日志文件同时都会保存二进制日志的偏移量，但是当断电的时候，二进制日志文件没有刷新到磁盘，主库重新启动之后，从库尝试读该偏移量的二进制日志，会出现读不到的情况，这个问题应该怎么解决？答：首先如果开启了sync_binlog选项，对于innodb同时设置innodb_flush_log_at_trx_commot=1，则可以保证二进制日志文件会被写入磁盘，但MyISAM引擎可能会导致数据损坏。如果没有开启这个选项，则可以通过制定从库的二进制偏移量为下一个二进制日志文件的开头，但是不能解决事件丢失问题。问题六：从库在非计划的关闭或重启时，回去读master.info文件去找上次停止复制的位置，这同样会有一个问题，如果master.info不正确，就会导致复制数据不一致的情况，遇到这个问题怎么办？答：这个问题可以通过两种方式解决，一是控制master.info在从库非计划关闭或重启的时候让master.info能够同步到磁盘，这样下次启动的时候就不会读取错误的信息，这有助于减少错误的发生概率。另外想要找到正确的复制位置是困难的，我们也可以选择忽略错误。请点击输入图片描述