mysql中,一次性删除多少数据会出现性能问题?

MySQL中删除数据的性能问题是因多种因素决定的,包括数据库设计、索引、数据量、硬件配置等。因此,不能确定一次性删除多少数据会出现性能问题。

如果数据量比较小,一次删除数据不会对性能造成太大影响。但如果数据量很大,删除操作可能会导致长时间的锁定和大量的磁盘 IO,从而对整个数据库性能产生影响。

因此,建议通过拆分数据,删除操作分批进行,以减少单次删除数据量,并避免性能问题的出现。此外,也可以考虑在删除数据之前对数据进行优化,以提高删除效率。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
FlockDB是一个存储图数据数据库,但是它并没有优化遍历图的操作。它优化的操作包括:超大规模邻接矩阵查询,快速读写和可分页查询。FlockDB将图存储为一个边的集合,每边用两个代表顶点的64位整数表示。对于一个社化网络图,这些顶点ID即用户ID,但是对于“收藏”推文这 样的边,其目标顶点(destination id)则是一推文的ID。每一边都被一个64位的位置信息标识,用于排序。(Twitter在“关注”类的边上用了时间戳标识,所以你的关注者列表时 按时间排序的,最新的在最前面。) 当一边被“删除”,这记录并没有从MySQL真正删除,而是标记为“删除”状态,这影响到主键值(一个由源ID-source id,状态-position,位置-position构成的组合键)。类似的,用户账户被删除时,他们所有的边都改为存档(archive)状态,允 许之后被恢复(但是根据服务协议,我们只保留一段时间)。我们只保留了一个组合主键和一个辅助索引来完成所有的查询。这种表结构优化使得MySQL大放 异彩,并提供给我们可预测的性能。一复杂的查询例如“我关注的人里面哪些关注了奥巴马总统”能分解成一些单用户查询(谁在关注奥巴马总统),并很快响应。数据根据节点分块,所以这些查询能分别在各自的数据块,通过一个索引过的范围查询得到结果。类似的,遍历一个长结果集是用位置作为游标,而不是用LIMIT/OFFSET,所有页的数据均被索引,访问一样快。基于进入系统的时间,写操作具有幂等性(不管操作多少次结果都不变的性质,比如取绝对值的函数就具有幂等性)和交换性(操作顺序不影响结果,比如加法就具 有交换性)。因为能交换操作顺序而不影响最终结果,所以我们才能在网络或者硬件临时故障的时候记录下所有操作或者恢复几分钟甚至几小时之前丢失的数据。这 种性质在初次部署是尤其有用。可交换的写操作简化了新数据块的创建流程。一个新数据块能在即时处理写请求的同时,在后台慢慢从旧数据块导入数据。导入完成时,该数据块即处于“激活”状态,并准备处理读操作。应用服务器(昵称flapps)用Scala编写,无状态,可水平伸缩。flapps与数据库独立,随着查询负载增加,我们可以增加更多的flapps。Flapps暴露了很少的thrift API给客户端,我们写的Ruby客户端包含更丰富的接口。 我们使用Gizzard库来处理数据分块层。该层将一段源ID映射到物理数据库,对于同一个物理地址的表,通过建立树来处理。写操作在本地登记后即返回,这样数据库崩溃或者出现性能问题能有效跟网站相应时间解耦。图的每一边都被存储了两次:一次正向存储(根据源ID做索引和分块),一次反向存储(根据目的ID做索引和分块)。这样类似于“谁在关注我”这样的查询可以跟查询“我在关注谁”一样高效,并且所有结果数据都分布在同一块。结果是我们拥有了一个可以按需扩展的一般服务器集群。在这个冬天,我们不知不觉已经增加了50%的数据库容量。现在我这个数据库里存储了130亿边,峰值可承受负载达到每秒2万次写和10万次读。介绍内容来自 http://article.yeeyan.org/view/yangxiao/136627 标签:FlockDB
[client] port = 3306 socket=/home/mysql/data/mysql.sock [mysqld] lower_case_table_names=1 user = mysql #--- 表示MySQL的管理用户 port = 3306 #--- 端口 #basedir=/usr/local/mysql socket=/home/mysql/data/mysql.sock #-- 启动的sock文件 datadir=/home/mysql/data log-bin=/home/mysql/mysql-bin log-error=/home/mysql/log/mysqld.log pid-file =/home/mysql/mysqld.pid bind-address = 0.0.0.0 server-id = 1 #表示是本机的序号为1,一般来讲就是master的意思 skip-grant-tables skip-name-resolve # 禁止MySQL对外部连接进行DNS解析,使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意,如果开启该选项, # 则所有远程主机连接授权都要使用IP地址方式,否则MySQL将无法正常处理连接请求 #skip-networking back_log = 600 # MySQL能有的连接数量。当主要MySQL线程在一个很短时间内得到非常多的连接请求,这就起作用, # 然后主线程花些时间(尽管很短)检查连接并且启动一个新线程。back_log值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈。 # 如果期望在一个短时间内有很多连接,你需要增加它。也就是说,如果MySQL的连接数据达到max_connections时,新来的请求将被存在堆栈, # 以等待某一连接释放资源,该堆栈的数量即back_log,如果等待连接的数量超过back_log,将不被授予连接资源。 # 另外,这值(back_log)限于您的操作系统对到来的TCP/IP连接的侦听队列的大小。 # 你的操作系统在这个队列大小上有它自己的限制(可以检查你的OS文档找出这个变量的最大值),试图设定back_log高于你的操作系统的限制将是无效的。 max_connections = 500 # MySQL的最大连接数,如果服务器的并发连接请求量比较大,建议调高此值,以增加并行连接数量,当然这建立在机器能支撑的情况下,因为如果连接数越多,介于MySQL为每个连接提供连接缓冲区,就开销越多的内存,所以要适当调整该值,不能盲目提高设值。可以过'conn%'通配符查看当前状态的连接数量,以定夺该值的大小。 max_connect_errors = 6000 # 对于同一主机,如果有超出该参数值个数的断错误连接,则该主机将被禁止连接。如需对该主机进行解禁,执行:FLUSH HOST。 open_files_limit = 65535 # MySQL打开的文件描述符限制,默认最小1024;当open_files_limit没有被配置的时候,比较max_connections*5和ulimit -n的值,哪个大用哪个, # 当open_file_limit被配置的时候,比较open_files_limit和max_connections*5的值,哪个大用哪个. table_open_cache = 128 # MySQL每打开一个表,都读入一些数据到table_open_cache缓存,当MySQL在这个缓存找不到相应信息时,才去磁盘上读取。默认值64 # 假定系统有200个并发连接,则需将此参数设置为200*N(N为每个连接所需的文件描述符数目); # 当把table_open_cache设置为很大时,如果系统处理不了那么多文件描述符,那么就出现客户端失效,连接不上 max_allowed_packet = 1000000000 # 接受的数据包大小;增加该变量的值十分安全,这是因为仅当需要时才分配额外内存。例如,仅当你发出长查询或MySQLd必须返回大的结果行时MySQLd才分配更多内存。 # 该变量之所以取较小默认值是一种预防措施,以捕获客户端和服务器之间的错误信息包,并确保不因偶然使用大的信息包而导致内存溢出。 binlog_cache_size = 1M # 一个事务,在没有提交的时候,产生的日志,记录到Cache;等到事务提交需要提交的时候,则把日志持久化到磁盘。默认binlog_cache_size大小32K max_heap_table_size = 67108864 # 定义了用户可以创建的内存表(memory table)的大小。这个值用来计算内存表的最大行数值。这个变量支持动态改变 tmp_table_size = 67108864 # MySQL的heap(堆积)表缓冲大小。所有联合在一个DML指令内完成,并且大多数联合甚至可以不用临时表即可以完成。 # 大多数临时表是基于内存的(HEAP)表。具有大的记录长度的临时表 (所有列的长度的和)或包含BLOB列的表存储在硬盘上。 # 如果某个内部heap(堆积)表大小超过tmp_table_size,MySQL可以根据需要自动将内存的heap表改为基于硬盘的MyISAM表。还可以通过设置tmp_table_size选项来增加临时表的大小。也就是说,如果调高该值,MySQL同时将增加heap表的大小,可达到提高联接查询速度的效果 read_buffer_size = 4194304 # MySQL读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区,MySQL为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。 # 如果对表的顺序扫描请求非常频繁,并且你认为频繁扫描进行得太慢,可以通过增加该变量值以及内存缓冲区大小提高其性能 read_rnd_buffer_size = 4194304 # MySQL的随机读缓冲区大小。当按任意顺序读取行时(例如,按照排序顺序),将分配一个随机读缓存区。进行排序查询时, # MySQL首先扫描一遍该缓冲,以避免磁盘搜索,提高查询速度,如果需要排序大量数据,可适当调高该值。但MySQL为每个客户连接发放该缓冲空间,所以应尽量适当设置该值,以避免内存开销过大 sort_buffer_size = 4194304 # MySQL执行排序使用的缓冲大小。如果想要增加ORDER BY的速度,首先看是否可以让MySQL使用索引而不是额外的排序阶段。 # 如果不能,可以尝试增加sort_buffer_size变量的大小 join_buffer_size = 8388608 # 联合查询操作所能使用的缓冲区大小,和sort_buffer_size一样,该参数对应的分配内存也是每连接独享 thread_cache_size = 8 # 这个值(默认8)表示可以重新利用保存在缓存线程的数量,当断开连接时如果缓存还有空间,那么客户端的线程将被放到缓存, # 如果线程重新被请求,那么请求将从缓存读取,如果缓存是空的或者是新的请求,那么这个线程将被重新创建,如果有很多新的线程, # 增加这个值可以改善系统性能.通过比较Connections和Threads_created状态的变量,可以看到这个变量的作用。(–>表示要调整的值) # 根据物理内存设置规则如下: # 1G —> 8 # 2G —> 16 # 3G —> 32 # 大于3G —> 64 #query_cache_size = 8M #MySQL的查询缓冲大小(从4.0.1开始,MySQL提供了查询缓冲机制)使用查询缓冲,MySQL将SELECT语句和查询结果存放在缓冲区, # 今后对于同样的SELECT语句(区分大小写),将直接从缓冲区读取结果。根据MySQL用户手册,使用查询缓冲最多可以达到238%的效率。 # 通过检查状态值'Qcache_%',可以知道query_cache_size设置是否合理:如果Qcache_lowmem_prunes的值非常大,则表明经常出现缓冲不够的情况, # 如果Qcache_hits的值也非常大,则表明查询缓冲使用非常频繁,此时需要增加缓冲大小;如果Qcache_hits的值不大,则表明你的查询重复率很低, # 这种情况下使用查询缓冲反而影响效率,那么可以考虑不用查询缓冲。此外,在SELECT语句加入SQL_NO_CACHE可以明确表示不使用查询缓冲 #query_cache_limit = 2M #指定单个查询能够使用的缓冲区大小,默认1M key_buffer_size = 1048576 #指定用于索引的缓冲区大小,增加它可得到更好处理的索引(对所有读和多重写),到你能负担得起那样多。如果你使它太大, # 系统将开始换页并且真的变慢了。对于内存在4GB左右的服务器该参数可设置为384M或512M。通过检查状态值Key_read_requests和Key_reads, # 可以知道key_buffer_size设置是否合理。比例key_reads/key_read_requests应该尽可能的低, # 至少是1:100,1:1000更好(上述状态值可以使用SHOW STATUS LIKE 'key_read%'获得)。注意:该参数值设置的过大反而是服务器整体效率降低 ft_min_word_len = 4 # 分词词汇最小长度,默认4 transaction_isolation = REPEATABLE-READ # MySQL支持4种事务隔离级别,他们分别是: # READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE. # 如没有指定,MySQL默认采用的是REPEATABLE-READ,ORACLE默认的是READ-COMMITTED log_bin = mysql-bin binlog_format = mixed expire_logs_days = 30 #超过30天的binlog删除 slow_query_log = 1 long_query_time = 1 #慢查询时间 超过1秒则为慢查询 slow_query_log_file = /home/mysql/data/mysql-slow.log performance_schema = 0 explicit_defaults_for_timestamp #lower_case_table_names = 1 #不区分大小写 skip-external-locking #MySQL选项以避免外部锁定。该选项默认开启 default-storage-engine = InnoDB #默认存储引擎 innodb_file_per_table = 1 # InnoDB为独立表空间模式,每个数据库的每个表都生成一个数据空间 # 独立表空间优点: # 1.每个表都有自已独立的表空间。 # 2.每个表的数据和索引都存在自已的表空间。 # 3.可以实现单表在不同的数据移动。 # 4.空间可以回收(除drop table操作处,表空不能自已回收) # 缺点: # 单表增加过大,如超过100G # 结论: # 共享表空间在Insert操作上少有优势。其它都没独立表空间表现好。当启用独立表空间时,请合理调整:innodb_open_files innodb_open_files = 500 # 限制Innodb能打开的表的数据,如果库里的表特别多的情况,请增加这个。这个值默认是300 innodb_buffer_pool_size = 1048576 # InnoDB使用一个缓冲池来保存索引和原始数据, 不像MyISAM. # 这里你设置越大,你在存取表里面数据时所需要的磁盘I/O越少. # 在一个独立使用的数据库服务器上,你可以设置这个变量到服务器物理内存大小的80% # 不要设置过大,否则,由于物理内存的竞争可能导致操作系统的换页颠簸. # 注意在32位系统上你每个进程可能被限制在 2-3.5G 用户层面内存限制, # 所以不要设置的太高. innodb_write_io_threads = 4 innodb_read_io_threads = 4 # innodb使用后台线程处理数据页上的读写 I/O(输入输出)请求,根据你的 CPU 核数来更改,默认是4 # 注:这两个参数不支持动态改变,需要把该参数加入到my.cnf里,修改完后重启MySQL服务,允许值的范围从 1-64 innodb_thread_concurrency = 0 # 默认设置为 0,表示不限制并发数,这里推荐设置为0,更好去发挥CPU多核处理能力,提高并发量 innodb_purge_threads = 1 # InnoDB的清除操作是一类定期回收无用数据的操作。在之前的几个版本,清除操作是主线程的一部分,这意味着运行时它可能堵塞其它的数据库操作。 # 从MySQL5.5.X版本开始,该操作运行于独立的线程,并支持更多的并发数。用户可通过设置innodb_purge_threads配置参数来选择清除操作是否使用单 # 独线程,默认情况下参数设置为0(不使用单独线程),设置为 1 时表示使用单独的清除线程。建议为1 innodb_flush_log_at_trx_commit = 2 # 0:如果innodb_flush_log_at_trx_commit的值为0,log buffer每秒就被刷写日志文件到磁盘,提交事务的时候不做任何操作(执行是由mysql的master thread线程来执行的。 # 主线程每秒将重做日志缓冲写入磁盘的重做日志文件(REDO LOG)。不论事务是否已经提交)默认的日志文件是ib_logfile0,ib_logfile1 # 1:当设为默认值1的时候,每次提交事务的时候,都将log buffer刷写到日志。 # 2:如果设为2,每次提交事务都写日志,但并不执行刷的操作。每秒定时刷到日志文件。要注意的是,并不能保证100%每秒一定都刷到磁盘,这要取决于进程的调度。 # 每次事务提交的时候将数据写入事务日志,而这里的写入仅是调用了文件系统的写入操作,而文件系统是有 缓存的,所以这个写入并不能保证数据已经写入到物理磁盘 # 默认值1是为了保证完整的ACID。当然,你可以将这个配置项设为1以外的值来换取更高的性能,但是在系统崩溃的时候,你将丢失1秒的数据。 # 设为0的话,mysqld进程崩溃的时候,就丢失最后1秒的事务。设为2,只有在操作系统崩溃或者断电的时候才丢失最后1秒的数据。InnoDB在做恢复的时候忽略这个值。 # 总结 # 设为1当然是最安全的,但性能页是最差的(相对其他两个参数而言,但不是不能接受)。如果对数据一致性和完整性要求不高,完全可以设为2,如果只最求性能,例如高并发写的日志服务器,设为0来获得更高性能 innodb-buffer-pool-size = 128M innodb_log_buffer_size = 4194304 # 此参数确定些日志文件所用的内存大小,以M为单位。缓冲区更大能提高性能,但意外的故障将丢失数据MySQL开发人员建议设置为1-8M之间 innodb_log_file_size = 268435456 # 此参数确定数据日志文件的大小,更大的设置可以提高性能,但也增加恢复故障数据库所需的时间 innodb_log_files_in_group = 3 # 为提高性能MySQL可以以循环方式将日志文件写到多个文件。推荐设置为3 innodb_max_dirty_pages_pct = 90 # innodb主线程刷新缓存池数据,使脏数据比例小于90% innodb_lock_wait_timeout = 120 # InnoDB事务在被回滚之前可以等待一个锁定的超时秒数。InnoDB在它自己的锁定表自动检测事务死锁并且回滚事务。InnoDB用LOCK TABLES语句注意到锁定设置。默认值是50秒 bulk_insert_buffer_size = 1024M # 批量插入缓存大小, 这个参数是针对MyISAM存储引擎来说的。适用于在一次性插入100-1000+记录时, 提高效率。默认值是8M。可以针对数据量的大小,翻倍增加。 myisam_sort_buffer_size = 1024M # MyISAM设置恢复表之时使用的缓冲区的尺寸,当在REPAIR TABLE或用CREATE INDEX创建索引或ALTER TABLE过程排序 MyISAM索引分配的缓冲区 myisam_max_sort_file_size = 10G # 如果临时文件变得超过索引,不要使用快速排序索引方法来创建一个索引。注释:这个参数以字节的形式给出 myisam_repair_threads = 1 # 如果该值大于1,在Repair by sorting过程并行创建MyISAM表索引(每个索引在自己的线程内) interactive_timeout = 28800 # 服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()使用CLIENT_INTERACTIVE选项的客户端。默认值:28800秒(8小时) wait_timeout = 28800 # 服务器关闭非交互连接之前等待活动的秒数。在线程启动时,根据全局wait_timeout值或全局interactive_timeout值初始化话wait_timeout值, # 取决于客户端类型(由mysql_real_connect()的连接选项CLIENT_INTERACTIVE定义)。参数默认值:28800秒(8小时) # MySQL服务器所支持的最大连接数是有上限的,因为每个连接的建立都消耗内存,因此我们希望客户端在连接到MySQL Server处理完相应的操作后, # 应该断开连接并释放占用的内存。如果你的MySQL Server有大量的闲置连接,他们不仅白白消耗内存,而且如果连接一直在累加而不断开, # 最终肯定达到MySQL Server的连接上限数,这报'too many connections'的错误。对于wait_timeout的值设定,应该根据系统的运行情况来判断。 # 在系统运行一段时间后,可以通过show processlist命令查看当前系统的连接状态,如果发现有大量的sleep状态的连接进程,则说明该参数设置的过大, # 可以进行适当的调整小些。要同时设置interactive_timeout和wait_timeout才生效。 [mysqldump] quick max_allowed_packet = 16M #服务器发送和接受的最大包长度 [myisamchk] key_buffer_size = 8M sort_buffer_size = 8M read_buffer = 4M write_buffer = 4M
目录 摘要 3 ABSTRACT 3 1. 灾难类型 4 2. 恢复类型 4 3. 恢复的级别 4 4. 需要防止的故障级别 4 4.1 可接受的数据丢失量 5 4.2 允许用于恢复的时间量 5 4.3 备份和恢复 5 5. 灾难恢复方案 5 5.1 简单备份 6 5.2 备份和日志保留 7 6. 高级存储备份 8 7. 数据库恢复 9 摘要 随着数据库技术在各个行业和各个领域大量广泛的应用,在对数据库应用的过程,人为误操作、人为恶意破坏、系统的不稳定、存储介质的损坏等等原因,都有可能造成重要数据的丢失。一旦数据出现丢失或者损坏,都将给企业和个人带来巨大的损失。这就需要进行数据库恢复。 关键词:数据库技术;灾难性;恢复;数据备份 ABSTRACT With the database technology in various industries and a large number of wide application in various fields, in the process of database applications, artificial misuse, human vandalism, system instability, damage to storage media and other reasons may have resulted in important data lost. Once the data appears lost or damaged, both businesses and individuals will give enormous losses. This need for database recovery. Abstract: Database technology; catastrophic; recovery; Data BackupDevice Driver; Data Backup; Logical Block Address; 数据库灾难性恢复 1. 灾难类型 为了使数据库损失降低到最小程度,需要一个恢复策略,确保它起作用,并经常实行策略,一些灾难类型包括: 1. 系统故障。电源故障、硬件故障或软件故障都能够使数据库处于不一致状态。 2. 事务故障。用户无意用错误数据修改数据库,从而毁坏数据库。 3. 介质故障。如果磁盘驱动器变得不能使用,那么可能丢失所有或部分数据。 4. 自然灾难。系统所在的设施可能遭受火灾、洪水或其它类似灾难的损坏。 2. 恢复类型 DB2 考虑到了下列恢复类型: 1. 崩溃恢复。这种类型的恢复通过撤销(回滚)未提交的事务来防止数据库处于不一致状态。 2. 版本恢复。这种类型的恢复通过使用从 BACKUP 命令获取的备份映像来恢复先前的数据库版本。恢复的数据库将包含在执行 BACKUP 命令时所处状态的信息。如果在执行备份之后针对数据库执行进一步操作,那么该信息将丢失。 3. 前滚恢复。这种类型的恢复通过使用完全数据库备份,结合日志文件来扩展版本恢复。必须先恢复备份以用作基线;然后在该备份之上应用日志。该过程数据库或表空间恢复到某个特定时间点。前滚恢复要求启用归档日志记录。 3. 恢复的级别 建立灾难恢复计划对于现代企业至关重要。企业数据的信息对于进行业务活动是极其重要的。保护该数据以及在灾难之后确保其“生命”是很重要的活动。当构建 DR计划时,有三个关键级别问题。 4. 需要防止的故障级别 要防止的故障级别通常是近似性问题。原始数据与其备份之间在物理上有多紧密?备份数据可以在不同的驱动器上、在独立的机器上、在独立的楼层上或在不同的建筑物里。不可能预测所有可能的灾难。火灾、水灾或甚至用户的恶作剧都可能是企业必须面对的问题。解决方案的设计应该包括公司希望防止最坏情况的方案。 4.1 可接受的数据丢失量 所有企业都不希望在故障之后丢失任何数据。虽然不丢失数据是可能的,但由于可能需要的复杂性和费用(尤其是如果所防止的故障级别非常高),这通常是不实际的。可接受的数据丢失量取决于数据对公司有多重要以及有什么资源可用于确保其生命。 4.2 允许用于恢复的时间量 恢复所需的时间量类似于高可用性的目标。它与高可用性解决方案之间的差异在于所防止的故障类型以及通常认为合理的时间长度。HA 故障转移通常以秒和分钟来衡量,而灾难恢复则可能以小时和天来进行衡量。不过并非总是这样,但这个差异区分了对这些解决方案的相对期望。 4.3 备份和恢复 数据库备份创建了数据库的时间点映象,它是灾难恢复解决方案的基本组件。DB2 提供了几种备份,包括脱机备份、联机备份和增量备份。从备份恢复所需的时间取决于数据库的大小和可用于执行恢复的硬件资源。 由于数据库备份只捕获时间点的数据,因此无法通过一个简单恢复来恢复备份之后发生的任何数据更改。要恢复备份之后完成的事务,就需要应用日志文件。可以从备份和日志文件(通过在日志文件进行“前滚”来应用)来恢复数据库。这允许恢复到某个时间点或恢复到日志文件结束。 因此,如果 DR 解决方案必须恢复自上次备份以来的事务,那么保留日志文件是非常关键的。有两个提高日志保留的 DB2 特性:双日志记录和用户出口工具,已在关于数据库复制 HA 选项的部分进行了讨论。 5. 灾难恢复方案 灾难恢复方案可以分成三类:简单备份、备份和日志保留、高级存储备份 。 虽然不是每个解决方案都清晰地被划入这三类的某一类,但它们确实为您理解灾难恢复选项提供了合理的框架。 5.1 简单备份 MySQL表保存为文件方式,很容易备份。要想保持备份的一致性,对相关表执行LOCK TABLES操作,然后对表执行FLUSH TABLES。你只需要读锁定;这样当你复制数据库目录的文件时,允许其它客户继续查询表。需要FLUSH TABLES语句来确保开始备份前将所有激活的索引页写入硬盘。 备份数据库的另一个技术是使用mysqldump程序或mysqlhotcopy脚本。 1. 完全备份数据库: 2. shell> mysqldump --tab=/path/to/some/dir --opt db_name 或: shell> mysqlhotcopy db_name /path/to/some/dir 只要服务器不再进行更新,还可以只复制所有表文件(*.frm、*.MYD和*.MYI文件)。mysqlhotcopy脚本使用该方法。(但请注意如果数据库包含InnoDB表,这些方法不工作。InnoDB不将表的内容保存到数据库目录mysqlhotcopy只适合MyISAM表)。 3. 如果mysqld在运行则停止,然后用--log-bin[=file_name]选项来启动。二进制日志文件提供了 执行mysqldump之后对数据库的更改进行复制所需要的信息。 对于InnoDB表,可以进行在线备份,不需要对表进行锁定; MySQL支持增量备份:需要用--log-bin选项来启动服务器以便启用二进制日志;当想要进行增量备份时(包含上一次完全备份或增量备份之后的所有更改),应使用FLUSH LOGS回滚二进制日志。然后,你需要将从最后的完全或增量备份的某个时刻到最后某个点的所有二进制日志复制到备份位置。这些二进制日志为增量备份;恢复时,按照下面的解释应用。下次进行完全备份时,还应使用FLUSH LOGS或mysqlhotcopy --flushlogs回滚二进制日志。如果MySQL服务器为从复制服务器,则无论选择什么备份方法,当备份从机数据时,还应备份master.info和relay-log.info文件。恢复了从机数据后,需要这些文件来继续复制。如果从机执行复制LOAD DATA INFILE命令,你应还备份--slave-load-tmpdir选项指定的目录的SQL_LOAD-*文件。(如果未指定,该位置默认为tmpdir变量值)。从机需要这些文件来继续复制断的LOAD DATA INFILE操作。 如果必须恢复MyISAM表,先使用REPAIR TABLE或myisamchk -r来恢复。99.9%的情况下该方法可以工作。如果myisamchk失败,试试下面的方法。请注意只有用--log-bin选项启动了MySQL从而启用二进制日志它才工作; 1. 恢复原mysqldump备份,或二进制备份。 2. 执行下面的命令重新更新二进制日志: 3. shell> mysqlbinlog hostname-bin.[0-9]* | mysql 在某些情况下,你可能只想要从某个位置重新运行某些二进制日志。(通常你想要从恢复备份的日期重新运行所有二进制日志,查询不正确时例外)。 还可以对具体文件进行选择备份: • 要想复制表,使用SELECT * INTO OUTFILE 'file_name' FROM tbl_name。 要想重载表,使用LOAD DATA INFILE 'file_name' REPLACE ...并恢复。要避免复制记录,表必须有PRIMARY KEY或一个UNIQUE索引。当新记录复制唯一键值的旧记录时,REPLACE关键字可以将旧记录替换为新记录。 如果备份时遇到服务器性能问题,可以有帮助的一个策略是在从服务器而不是主服务器上建立复制并执行备份。如果使用Veritas文件系统,可以这样备份: 1. 从客户端程序执行FLUSH TABLES WITH READ LOCK。 2. 从另一个shell执行mount vxfs snapshot。 3. 从第一个客户端执行UNLOCK TABLES。 4. 从快照复制文件。 5. 卸载快照。 只创建数据库备份确实创建了一个 DR 解决方案。它也许是非常有限的,这取决于您的环境。通过从“活动”的系统上移走所创建的备份,可以提高保护的级别。增加数据库备份的频率也降低了数据丢失的风险。备份软件对于创建和维护 DB2 备份可能非常有帮助。例如,IBM 的 Tivoli Storage Manager 和 Veritas 的 Net Backup® 都提供了允许在其软件控制的设备上直接备份和维护 DB2 数据库的解决方案。这些设备可以是磁带库或另一种存储设备。 简单备份适合于只读数据库或由能轻松重新创建的批处理作业填充的数据库,或者在备份之间不必维护数据库更改的情况下。 表 1.简单备份的优缺点 优点: 缺点: 保护级别: 数据库备份可以转移到外部位置,以提高保护级别 数据丢失的风险: 备份之间的数据更改可能丢失(运行增量备份来降低风险的影响) 恢复所需的时间: 数据库恢复需要很长时间 5.2 备份和日志保留 保留数据库日志文件与数据库备份一起创建了更完善的 DR 解决方案。日志文件允许恢复备份之间发生的数据更改。该解决方案的真正复杂性在于保护日志文件以确保它们在恢复期间的可用性。如果选择实现双日志记录,DB2 可以将日志文件放在不同的位置,如果确保这些位置在不同的存储器阵列上,那么保护级别就得到提高。但是,日志文件仍面临存储子系统故障。如在高可用性的日志传送选项所提到的,用户出口程序可以提供重定位日志文件的替代方法。 用户出口可以将已关闭的日志文件移到当前系统可用存储阵列之外的位置,从而提高保护级别。这里的告诫是它只移动已关闭的日志文件。即使已实现了双日志记录,包含活动事务的日志文件仍面临因阵列丢失或存储设备故障而产生的丢失。该解决方案适合于大多数面向商业事务的环境。 它均衡了最小化数据丢失风险的需要和维护 DR 解决方案所需的成本。 表 2.备份加日志保留的优缺点 优点: 缺点: 保护级别: 数据库备份可以转移到外部位置,以提高保护级别 数据丢失的风险: 如果使用适当的步骤来维护日志文件,大大降低数据丢失的风险 恢复所需的时间: 数据库恢复需要时间,应用日志文件将增加恢复时间 6. 高级存储备份 我们在高可用性下的高级存储选项部分讨论过这个主题,相同的原则在这里也适用。正如在那部分所见的,STANDBY方法允许当数据库副本处于暂挂状态时在辅助系统上执行数据库备份。 创建数据库副本已经创建了 DR解决方案的一部分。备份副本提高了保护级别。如果用双日志记录和用户出口程序正确实现了这个高级存储备份,那么它就为核心企业数据库生成了最好的 DR解决方案。 该解决方案最适合处于企业活动核心的数据库系统。示例可能包含了供应链管理和在线代理系统。 表 3.用于灾难恢复的高级存储备份优缺点 优点: 缺点: 保护级别: 保护级别本来就很高,而且可以通过耦合存储子系统来提高保护级别。 数据丢失的风险: 如果采用双日志记录和用户出口程序,大大降低数据丢失的风险 恢复所需的时间: 恢复所需的时间非常短。 7. 数据库恢复 数据库恢复心理解为: (1)当数据出现损伤或由于人员误操作、操作系统本身故障所造成的数据看不见、无法读取、丢失。工程师通过技术手段读取将数据都恢复为可以读的数据数据恢复不是靠一两种软件就可以完成,往往需要数个工程师靠经验不同的方式才能恢复数据,当然数据库恢复还包括各种操作系统:除普通的WINDOWS外,还有Unix、Linux、APPLE机,而以UNIX为多。 (2)数据数据已经存在,但是无法正常使用,提示错误,都应归属为数据修复,举例说明:SQL SERVER文件打开提示LDF文件损坏,或错误823等等。 数据库恢复实际上就是利用技术手段把不可见或不可正常运行的数据文件恢复成正常运行的过程。 方法一 如何附加数据库(企业管理器) 1、展开服务器组,然后展开服务器。 2、右击"数据库",然后选择"所有任务"/"附加数据库"。 3、输入要附加的数据库的 MDF(master 数据文件)名称。如果不确定文件位于何处,单击浏览("...")搜索。最多可以指定16个文件名。 4、若要确保指定的MDF文件正确,请单击"验证"。"原文件名"列列出了数据的所有文件(数据文件和日志文件)。"当前文件位置"列列出了文件的名称和路径。如果Microsoft? SQL Server? 找不到指定位置的文件,则附加操作将失败。可以对"当前文件位置"列进行编辑,并且文件的当前位置必须在该列才能使附加操作得以进行。例如,如果在分离操作前改变了文件的默认位置,则必须指定当前位置才能使附加操作顺利进行。 5、在"附加为"框内,输入数据库的名称。数据库名称不能与任何现有数据库名称相匹配 6、指定数据库的所有者。 7、单击"确定"按钮。新附加的数据库的数据库节点即创建在"数据库"文件夹。 方法二 sp_attach_db 将数据库附加到服务器。 语法 sp_attach_db [ @dbname = ] 'dbname' , [ @filename1 = ] 'filename_n' [ ,...16 ] 参数 [@dbname =] 'dbname' 要附加到服务器的数据库的名称。该名称必须是唯一的。dbname 的数据类型为 sysname,默认值为 NULL。 [@filename1 =] 'filename_n' 数据库文件的物理名称,包括路径。filename_n 的数据类型为 nvarchar(260),默认值为 NULL。最多可以指定 16 个文件名。参数名称以 @filename1 开始,递增到 @filename16。文件名列表至少必须包括主文件,主文件包含指向数据其它文件的系统表。该列表还必须包括数据库分离后所有被移动的文件。 返回代码值 0(成功)或 1(失败) 结果集 无 注释 只应对以前使用显式 sp_detach_db 操作从数据库服务器分离的数据库执行 sp_attach_db。如果必须指定多于 16 个文件,请使用带有 FOR ATTACH 子句的 CREATE DATABASE。 如果将数据库附加到的服务器不是该数据库从分离的服务器,并且启用了分离的数据库以进行复制,则应该运行 sp_removedbreplication 从数据删除复制。 权限 只有 sysadmin 和 dbcreator 固定服务器角色的成员才能执行本过程。 示例 下面的示例将 pubs 的两个文件附加到当前服务器。 EXEC sp_attach_db @dbname = N'pubs', @filename1 = N'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf', @filename2 = N'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs_log.ldf' 请参见 CREATE DATABASE sp_attach_single_file_db sp_detach_db sp_helpfile sp_removedbreplication 系统存储过程

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值