热门标签 | HotTags
当前位置:  开发笔记 > 数据库 > 正文

验证DG最大性能模式下使用ARCH/LGWR及STANDBYLOG的不同情况

总结:--两台单实例数据库做DG,数据库版本10.2.0.1.01.主库配置为:archasync,备库无STANDBYLOG。日志中会有:RFS[4]:Nostandbyredologfilescreated2.主库配置为:archasync,备库有STANDBYLOG,日志中未显示使用。特殊情况:主库配置为:arc

总结: --两台单实例数据库做DG,数据库版本10.2.0.1.0 1.主库配置为:arch async,备库无STANDBY LOG。 日志中会有:RFS[4]: No standby redo logfiles created 2.主库配置为:arch async,备库有STANDBY LOG,日志中未显示使用。 特殊情况:主库配置为:arc

总结: --两台单实例数据库做DG,数据库版本10.2.0.1.0
1.主库配置为:arch async,备库无STANDBY LOG。
日志中会有:RFS[4]: No standby redo logfiles created
2.主库配置为:arch async,备库有STANDBY LOG,日志中未显示使用。
特殊情况:主库配置为:arch async,备库有STANDBY LOG,备库未打开日志应用 ,日志中有:RFS[8]: Successfully opened standby log 4: '/u01/app/oracle/prod/disk1/standbylog1.log'
3.主库修改参数为:lgwr async,备库有STANDBY LOG,日志如下:

RFS[10]: Successfully opened standby log 4: '/u01/app/oracle/prod/disk1/standbylog1.log'

4.主库修改参数为:log_archive_dest_2 == SERVICE=PROD,只写SERVICE=PROD主库归档不能传送到备库。

实验1:主库配置为:arch async,备库无STANDBY LOG。

1.主库配置及日志:
主库:
SQL> select protection_mode,database_role,protection_level from v$database;
PROTECTION_MODE DATABASE_ROLE PROTECTION_LEVEL
-------------------- ---------------- --------------------
MAXIMUM PERFORMANCE PRIMARY MAXIMUM PERFORMANCE
15:47:43 SQL> show parameter log_archive_dest_2
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=prod1 arch async VALI
D_FOR=(ONLINE_LOGFILES,PRIMARY
_ROLE) DB_UNIQUE_NAME=prod1
15:47:49 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
27
备库:
SQL> select protection_mode,database_role,protection_level from v$database;
PROTECTION_MODE DATABASE_ROLE PROTECTION_LEVEL
-------------------- ---------------- --------------------
MAXIMUM PERFORMANCE PHYSICAL STANDBY MAXIMUM PERFORMANCE

03:48:02 SQL> select group#,thread#,bytes/1024/1024 mb,status from v$standby_log;
no rows selected

03:48:05 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
27
####################
2.主库做REDO日志切换并查看日志:
15:48:18 SQL> alter system switch logfile;
System altered.
15:49:33 SQL> alter system switch logfile;
System altered.
15:50:11 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
29
备库已经接收:
03:49:48 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
29
主库日志:
[oracle@ocm1 ~]$ tail -f alert_PROD.log

Sun Apr 20 15:49:33 2014
Thread 1 advanced to log sequence 29
Current log# 2 seq# 29 mem# 0: /u01/app/oracle/prod/disk1/redo02.log
Current log# 2 seq# 29 mem# 1: /u01/app/oracle/prod/disk2/log2b.log
Sun Apr 20 15:50:11 2014
Thread 1 advanced to log sequence 30
Current log# 3 seq# 30 mem# 0: /u01/app/oracle/prod/disk1/redo03.log
Current log# 3 seq# 30 mem# 1: /u01/app/oracle/prod/disk2/log3b.log
备库日志:
[oracle@ocm2 ~]$ tail -f alert_PROD1.log
RFS[4]: Archived Log: '/u01/app/oracle/prod/arch/1_28_844894247.arc'
Sun Apr 20 03:49:30 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_28_844894247.arc
Media Recovery Waiting for thread 1 sequence 29
Sun Apr 20 03:50:07 2014
RFS[4]: No standby redo logfiles created
RFS[4]: Archived Log: '/u01/app/oracle/prod/arch/1_29_844894247.arc'
Sun Apr 20 03:50:10 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_29_844894247.arc
Media Recovery Waiting for thread 1 sequence 30
##########################################################

实验2:主库配置为:arch async,备库有STANDBY LOG,此时会自动使用备库的STANDBY LOG。

主库配置不变。
备库增加STANDBY LOG:
03:55:04 SQL> alter database recover managed standby database cancel;
Database altered.
03:56:39 SQL> alter database add standby logfile '/u01/app/oracle/prod/disk1/standbylog1.log' size 100m;
Database altered.
03:56:50 SQL> alter database add standby logfile '/u01/app/oracle/prod/disk1/standbylog2.log' size 100m;
Database altered.
03:56:55 SQL> alter database add standby logfile '/u01/app/oracle/prod/disk1/standbylog3.log' size 100m;
Database altered.
03:57:00 SQL> alter database add standby logfile '/u01/app/oracle/prod/disk1/standbylog4.log' size 100m;
Database altered.
03:57:05 SQL> select group#,thread#,bytes/1024/1024 mb,status from v$standby_log;
GROUP# THREAD# MB STATUS
---------- ---------- ---------- ----------
4 0 100 UNASSIGNED
5 0 100 UNASSIGNED
6 0 100 UNASSIGNED
7 0 100 UNASSIGNED
04:13:33 SQL> alter database recover managed standby database disconnect from session;
Database altered.
04:14:12 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
38
###在主库切换日志:
16:15:40 SQL> alter system switch logfile;
System altered.
16:15:53 SQL> alter system switch logfile;
System altered.
16:16:10 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
40
备库查询:
04:02:47 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
32
04:02:49 SQL>

############################
第二次正常时的日志:
[oracle@ocm1 ~]$ tail -f alert_PROD.log

Sun Apr 20 16:18:21 2014
Thread 1 cannot allocate new log, sequence 42
Checkpoint not complete
Current log# 2 seq# 41 mem# 0: /u01/app/oracle/prod/disk1/redo02.log
Current log# 2 seq# 41 mem# 1: /u01/app/oracle/prod/disk2/log2b.log
Thread 1 advanced to log sequence 42
Current log# 3 seq# 42 mem# 0: /u01/app/oracle/prod/disk1/redo03.log
Current log# 3 seq# 42 mem# 1: /u01/app/oracle/prod/disk2/log3b.log
Sun Apr 20 16:19:08 2014
Thread 1 cannot allocate new log, sequence 43
Checkpoint not complete
Current log# 3 seq# 42 mem# 0: /u01/app/oracle/prod/disk1/redo03.log
Current log# 3 seq# 42 mem# 1: /u01/app/oracle/prod/disk2/log3b.log
Thread 1 advanced to log sequence 43
Current log# 1 seq# 43 mem# 0: /u01/app/oracle/prod/disk1/redo01.log
Current log# 1 seq# 43 mem# 1: /u01/app/oracle/prod/disk2/log1b.log
Sun Apr 20 16:20:41 2014
Expanded controlfile section 11 from 56 to 112 records
Requested to grow by 56 records; added 2 blocks of records
备库:
[oracle@ocm2 ~]$ tail -f alert_PROD1.log
Sun Apr 20 04:20:36 2014
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[8]: Assigned to RFS process 16069
RFS[8]: Identified database type as 'physical standby'
RFS[8]: Archived Log: '/u01/app/oracle/prod/arch/1_40_844894247.arc'
RFS[8]: Archived Log: '/u01/app/oracle/prod/arch/1_41_844894247.arc'
RFS[8]: Archived Log: '/u01/app/oracle/prod/arch/1_42_844894247.arc'
Sun Apr 20 04:20:37 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_40_844894247.arc
Media Recovery Log /u01/app/oracle/prod/arch/1_41_844894247.arc
Media Recovery Log /u01/app/oracle/prod/arch/1_42_844894247.arc
Media Recovery Waiting for thread 1 sequence 43

实验4:接上一步,备库关闭日志应用 :

04:23:03 SQL> alter database recover managed standby database cancel;
Database altered.
04:23:17 SQL>
主库切换日志:
16:20:17 SQL> alter system switch logfile;
System altered.
16:23:25 SQL> alter system switch logfile;
System altered.
16:25:06 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
44
备库查询:
04:26:21 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
44
此期间主库日志:
Sun Apr 20 16:23:25 2014
Thread 1 advanced to log sequence 44
Current log# 2 seq# 44 mem# 0: /u01/app/oracle/prod/disk1/redo02.log
Current log# 2 seq# 44 mem# 1: /u01/app/oracle/prod/disk2/log2b.log
Sun Apr 20 16:23:25 2014
ARC0: Standby redo logfile selected for thread 1 sequence 43 for destination LOG_ARCHIVE_DEST_2
Sun Apr 20 16:25:06 2014
Thread 1 advanced to log sequence 45
Current log# 3 seq# 45 mem# 0: /u01/app/oracle/prod/disk1/redo03.log
Current log# 3 seq# 45 mem# 1: /u01/app/oracle/prod/disk2/log3b.log
Sun Apr 20 16:25:06 2014
ARC0: Standby redo logfile selected for thread 1 sequence 44 for destination LOG_ARCHIVE_DEST_2
##此期间备库日志:
Managed Standby Recovery Canceled (PROD1)
Sun Apr 20 04:23:17 2014
Completed: alter database recover managed standby database cancel
Sun Apr 20 04:23:20 2014
RFS[8]: Successfully opened standby log 4: '/u01/app/oracle/prod/disk1/standbylog1.log'
Sun Apr 20 04:25:01 2014
RFS[8]: Successfully opened standby log 4: '/u01/app/oracle/prod/disk1/standbylog1.log'

实验5:主库修改参数为:lgwr async,备库有STANDBY LOG

总结:此时
主库上操作:
16:28:46 SQL> show parameter log_archive_dest_2
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2 string SERVICE=prod1 lgwr async VALI
D_FOR=(ONLINE_LOGFILES,PRIMARY
_ROLE) DB_UNIQUE_NAME=prod1
16:28:47 SQL> alter system switch logfile;
System altered.
16:30:06 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
45
16:30:36 SQL> alter system switch logfile;
System altered.
16:30:45 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
46
16:33:08 SQL> alter system switch logfile;
System altered.
16:33:09 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
47
备库上查询:
04:29:17 SQL> alter database recover managed standby database disconnect from session;
Database altered.
04:29:32 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
46
04:30:44 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
46
04:33:09 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
47
############
此期间主库日志:
Sun Apr 20 16:28:25 2014
ALTER SYSTEM SET log_archive_dest_2='SERVICE=prod1 lgwr async VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=prod1' SCOPE=BOTH;

LNS1 started with pid=16, OS id=12273
Sun Apr 20 16:30:06 2014
Thread 1 advanced to log sequence 46
Current log# 1 seq# 46 mem# 0: /u01/app/oracle/prod/disk1/redo01.log
Current log# 1 seq# 46 mem# 1: /u01/app/oracle/prod/disk2/log1b.log
Sun Apr 20 16:30:06 2014
ARC0: Standby redo logfile selected for thread 1 sequence 45 for destination LOG_ARCHIVE_DEST_2
Sun Apr 20 16:30:07 2014
******************************************************************
LGWR: Setting 'active' archival for destination LOG_ARCHIVE_DEST_2
******************************************************************
LNS: Standby redo logfile selected for thread 1 sequence 46 for destination LOG_ARCHIVE_DEST_2
Sun Apr 20 16:30:42 2014
Thread 1 cannot allocate new log, sequence 47
Checkpoint not complete
Current log# 1 seq# 46 mem# 0: /u01/app/oracle/prod/disk1/redo01.log
Current log# 1 seq# 46 mem# 1: /u01/app/oracle/prod/disk2/log1b.log
Thread 1 advanced to log sequence 47
Current log# 2 seq# 47 mem# 0: /u01/app/oracle/prod/disk1/redo02.log
Current log# 2 seq# 47 mem# 1: /u01/app/oracle/prod/disk2/log2b.log
Sun Apr 20 16:30:45 2014
LNS: Standby redo logfile selected for thread 1 sequence 47 for destination LOG_ARCHIVE_DEST_2
###
Sun Apr 20 16:33:09 2014
Thread 1 advanced to log sequence 48
Current log# 3 seq# 48 mem# 0: /u01/app/oracle/prod/disk1/redo03.log
Current log# 3 seq# 48 mem# 1: /u01/app/oracle/prod/disk2/log3b.log
Sun Apr 20 16:33:10 2014
LNS: Standby redo logfile selected for thread 1 sequence 48 for destination LOG_ARCHIVE_DEST_2

此期间备库日志:
Sun Apr 20 04:29:32 2014
Completed: alter database recover managed standby database disconnect from session
Sun Apr 20 04:30:01 2014
RFS[9]: Successfully opened standby log 4: '/u01/app/oracle/prod/disk1/standbylog1.log'
Sun Apr 20 04:30:01 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_45_844894247.arc
Media Recovery Waiting for thread 1 sequence 46
Sun Apr 20 04:30:01 2014
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[10]: Assigned to RFS process 12480
RFS[10]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[10]: Successfully opened standby log 4: '/u01/app/oracle/prod/disk1/standbylog1.log'
Sun Apr 20 04:30:36 2014
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[11]: Assigned to RFS process 12574
RFS[11]: Identified database type as 'physical standby'
Sun Apr 20 04:30:40 2014
Primary database is in MAXIMUM PERFORMANCE mode
RFS[10]: Successfully opened standby log 5: '/u01/app/oracle/prod/disk1/standbylog2.log'
Sun Apr 20 04:30:40 2014
Expanded controlfile section 11 from 28 to 280 records
Requested to grow by 252 records; added 9 blocks of records
Sun Apr 20 04:30:41 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_46_844894247.arc
Media Recovery Waiting for thread 1 sequence 47 (in transit)
###
Sun Apr 20 04:33:04 2014
Primary database is in MAXIMUM PERFORMANCE mode
RFS[10]: Successfully opened standby log 4: '/u01/app/oracle/prod/disk1/standbylog1.log'
Sun Apr 20 04:33:06 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_47_844894247.arc
Media Recovery Waiting for thread 1 sequence 48 (in transit)
#########################

实验6:接上一步,模拟网络中断:--备库上SERVICE NETWORK STOP

主库做归档
16:35:19 SQL>
16:37:37 SQL> alter system switch logfile;
System altered.
16:37:38 SQL> alter system switch logfile;
System altered.
16:39:46 SQL>
16:43:34 SQL> alter system switch logfile;
System altered.
16:43:38 SQL>
16:44:18 SQL> alter system switch logfile;
System altered.
16:44:19 SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
51
备库网络中断期间主库归档时日志:
[oracle@ocm1 ~]$ tail -f alert_PROD.log

Sun Apr 20 16:37:38 2014
Thread 1 advanced to log sequence 49
Current log# 1 seq# 49 mem# 0: /u01/app/oracle/prod/disk1/redo01.log
Current log# 1 seq# 49 mem# 1: /u01/app/oracle/prod/disk2/log1b.log
Sun Apr 20 16:39:43 2014
ARC0: Controlfile enqueue unavailable
Sun Apr 20 16:39:43 2014
Errors in file /u01/app/oracle/product/10.2.0.1/dbhome_1/rdbms/log/prod_arc0_9993.trc:
ORA-16146: standby destination control file enqueue unavailable
LNS1 started with pid=16, OS id=12597
Sun Apr 20 16:39:46 2014
Thread 1 advanced to log sequence 50
Current log# 2 seq# 50 mem# 0: /u01/app/oracle/prod/disk1/redo02.log
Current log# 2 seq# 50 mem# 1: /u01/app/oracle/prod/disk2/log2b.log
Sun Apr 20 16:39:49 2014
Error 12560 received logging on to the standby
Sun Apr 20 16:39:49 2014
Errors in file /u01/app/oracle/product/10.2.0.1/dbhome_1/rdbms/log/prod_lns1_12597.trc:
ORA-12560: TNS:protocol adapter error
LGWR: Error 12560 creating archivelog file 'prod1'
LNS: Failed to archive log 2 thread 1 sequence 50 (12560)
Sun Apr 20 16:43:38 2014
Thread 1 advanced to log sequence 51
Current log# 3 seq# 51 mem# 0: /u01/app/oracle/prod/disk1/redo03.log
Current log# 3 seq# 51 mem# 1: /u01/app/oracle/prod/disk2/log3b.log
Sun Apr 20 16:44:19 2014
Thread 1 advanced to log sequence 52
Current log# 1 seq# 52 mem# 0: /u01/app/oracle/prod/disk1/redo01.log
Current log# 1 seq# 52 mem# 1: /u01/app/oracle/prod/disk2/log1b.log
Sun Apr 20 16:48:11 2014
ARC0: Standby redo logfile selected for thread 1 sequence 49 for destination LOG_ARCHIVE_DEST_2
Sun Apr 20 16:48:14 2014
ARCH: Possible network disconnect with primary database
备库网络恢复后日志:
[oracle@ocm2 ~]$ tail -f alert_PROD1.log
RFS[12]: Assigned to RFS process 14171
RFS[12]: Identified database type as 'physical standby'
RFS[12]: Archived Log: '/u01/app/oracle/prod/arch/1_48_844894247.arc'
Sun Apr 20 04:48:07 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_48_844894247.arc
Media Recovery Log /u01/app/oracle/prod/arch/1_49_844894247.arc
Media Recovery Waiting for thread 1 sequence 50
Fetching gap sequence in thread 1, gap sequence 50-50
Sun Apr 20 04:48:08 2014
RFS[12]: Archived Log: '/u01/app/oracle/prod/arch/1_50_844894247.arc'
Sun Apr 20 04:48:38 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_50_844894247.arc
Media Recovery Waiting for thread 1 sequence 51
Fetching gap sequence in thread 1, gap sequence 51-51
Sun Apr 20 04:48:38 2014
RFS[12]: Archived Log: '/u01/app/oracle/prod/arch/1_51_844894247.arc'
Sun Apr 20 04:49:08 2014
Media Recovery Log /u01/app/oracle/prod/arch/1_51_844894247.arc
Media Recovery Waiting for thread 1 sequence 52


推荐阅读
  • 本文介绍了MySQL中一些基本但重要的数学函数,包括角度与弧度之间的转换函数RADIANS(X)和DEGREES(X),以及正弦函数。RADIANS(X)用于将角度值转换为弧度值,而DEGREES(X)则将弧度值转换为角度值。这些函数在处理涉及角度和弧度的计算时非常有用,能够简化复杂的数学运算。此外,正弦函数在三角学和工程计算中也具有广泛的应用,能够帮助用户更高效地进行数据处理和分析。 ... [详细]
  • 在数据库事务处理中,InnoDB 存储引擎提供了多种隔离级别,其中 READ COMMITTED 和 REPEATABLE READ 是两个常用的选项。本文详细对比了这两种隔离级别的特点和差异,不仅从理论角度分析了它们对“脏读”和“幻读”的处理方式,还结合实际应用场景探讨了它们在并发控制和性能表现上的不同。特别关注了行锁机制在不同隔离级别下的行为,为开发者选择合适的隔离级别提供了参考。 ... [详细]
  • 在使用PFC进行数据处理时,遇到了数据列消失的问题。具体表现为,在数据窗口dw_1中,原本点击排序按钮cb_1后,会弹出一个排序窗口并显示所有字段。然而,目前点击排序按钮时,数据列却无法正常显示。为了解决这一问题,需要检查数据源的配置和按钮事件的触发逻辑,确保数据列能够正确加载和显示。 ... [详细]
  • 实现Nginx对ThinkPHP URL重写及PATHINFO支持的详细方法解析【PHP开发】
    在PHP后端开发中,实现Nginx对ThinkPHP的URL重写及PATHINFO支持是一项常见的需求。本文详细解析了经过多次尝试和研究,最终找到的一种有效配置方法,能够确保URL_MODERewrite功能正常运行,并提供稳定的服务。此外,文章还探讨了相关配置项的具体作用及其优化建议,帮助开发者更好地理解和应用这些技术。 ... [详细]
  • 开发日志:在插入数据到一张表的同时更新另一张表的技术细节与最佳实践 ... [详细]
  • 在近期的项目开发过程中,ORM层采用了MyBatis,并且需要连接多个数据库,这带来了多数据源配置的挑战。为了解决这一问题,我们可以通过巧妙运用注解来实现优雅的数据源切换,确保系统的灵活性和可维护性。这种方法不仅简化了配置,还提高了代码的可读性和扩展性。 ... [详细]
  • 如何正确获取Oracle TNS_ADMIN环境变量的值
    如何正确获取Oracle TNS_ADMIN环境变量的值?TNS_ADMIN 是 Oracle 客户端配置中的一个重要环境变量,用于指定网络配置文件(如 tnsnames.ora)的路径。本文将详细介绍如何在不同操作系统中准确获取该变量的值,并提供实用的命令和步骤,帮助用户确保 Oracle 客户端的网络连接配置正确无误。 ... [详细]
  • 如何在Android设备上通过应用程序创建浏览器书签 ... [详细]
  • 本文深入探讨了 DB2 SQL 中多列更新语句的应用与技巧,通过具体示例详细介绍了多列更新的语法和实际操作方法。例如,使用以下语法可以同时更新多个字段:```sqlUPDATE T_TableSET (字段A, 字段B) = (value_a, value_b);```文章还进一步分析了多列更新在性能优化和数据一致性方面的优势,并提供了实用的案例和最佳实践。 ... [详细]
  • 本文深入探讨了 MySQL 中 `ANALYZE TABLE` 和 `SHOW CREATE TABLE` 的语法规则及其应用。`ANALYZE TABLE` 语句用于分析并存储表的关键字分布情况,以优化查询性能。该操作在执行过程中会获取表的读锁,确保数据的一致性。而 `SHOW CREATE TABLE` 则用于显示创建表时的详细语句,包括表结构、索引和存储引擎等信息,有助于数据库管理和维护。通过这些命令,DBA 可以更好地理解和优化数据库性能。 ... [详细]
  • 在数据库设计中,谨慎使用外键至关重要。本文探讨了九个关键原因,包括数据完整性的维护、性能优化、系统复杂性的管理、数据迁移的灵活性以及对外部系统的依赖性控制。通过深入分析这些因素,可以帮助开发人员和架构师做出更明智的设计决策,确保数据库系统的高效与稳定。 ... [详细]
  • InnoDB当前仅支持一次创建一个FULLTEXT索引 ... [详细]
  • MySQL 数据备份与恢复的常见方法及其实践经验总结。物理备份涉及直接复制数据库文件,适用于大规模数据库环境,但无法在异构系统(如 Windows)中恢复。逻辑备份则侧重于导出建表语句和数据插入语句,便于跨平台迁移和部分数据恢复。此外,本文还探讨了增量备份、全量备份以及使用工具如 mysqldump 和 Percona XtraBackup 的具体应用场景和优缺点。 ... [详细]
  • 揭秘腾讯云CynosDB计算层设计优化背后的不为人知的故事与技术细节
    揭秘腾讯云CynosDB计算层设计优化背后的不为人知的故事与技术细节 ... [详细]
  • MySQL 数据变更后如何实现实时同步至 Elasticsearch
    在 MySQL 数据变更后,如何实现与 Elasticsearch 的实时同步是一个常见的需求。本文介绍了通过配置 MySQL 的 Binlog 功能,结合中间件如 Canal 或 Debezium,将数据变更事件实时捕获并同步到 Elasticsearch 中的方法。此外,还探讨了如何处理数据删除操作,确保 Elasticsearch 中的数据与 MySQL 保持一致。文章还简要对比了 VSCode 和 Dev 两种开发环境的优缺点,为开发者提供参考。 ... [详细]
author-avatar
怕疼不怕死
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有