首页
/ OpenMetadata企业级部署与运维指南

OpenMetadata企业级部署与运维指南

2026-03-08 04:05:51作者：明树来
OpenMetadata
OpenMetadata is a unified metadata platform for data discovery, data observability, and data governance powered by a central metadata repository, in-depth column level lineage, and seamless team collaboration.
项目地址：https://gitcode.com/GitHub_Trending/op/OpenMetadata

部署指南

1.1 容器化部署架构设计

挑战：如何快速搭建一套包含所有依赖组件的标准化OpenMetadata环境，确保开发、测试和生产环境的一致性？

方案：采用Docker Compose多容器架构，整合元数据服务、数据库、搜索引擎等核心组件，实现一键部署。

OpenMetadata容器化部署架构包含以下关键组件：

  • 元数据服务器：提供API和Web UI访问（默认端口8585）
  • 数据库服务：支持MySQL或PostgreSQL（默认端口3306/5432）
  • 搜索服务：Elasticsearch用于元数据搜索和索引（默认端口9200/9300）
  • 迁移服务：负责数据库模式迁移和数据初始化
  • 采集框架：与Airflow集成，管理元数据采集任务

OpenMetadata采集框架架构

适用场景：

  • 开发测试环境快速搭建
  • 中小型生产环境部署
  • 演示环境快速启动

部署步骤：

  1. 克隆项目代码库

    git clone https://gitcode.com/GitHub_Trending/op/OpenMetadata
cd OpenMetadata

  2. 使用快速启动脚本部署

    # 使用MySQL后端启动完整环境（包含UI）
./docker/run_local_docker.sh -m ui -d mysql

# 使用PostgreSQL后端启动仅后端服务
./docker/run_local_docker.sh -m no-ui -d postgresql

  3. 验证部署状态

    # 检查容器状态
docker ps --filter "name=openmetadata"

# 验证API可用性
curl http://localhost:8585/api/v1/health-check

1.2 自定义部署配置

挑战：默认部署配置无法满足特定环境需求，如何根据实际情况调整资源分配、网络设置和存储策略？

方案：通过环境变量和自定义Docker Compose文件实现灵活配置，优化资源利用和安全性。

核心配置参数对比：

配置类别 开发环境 测试环境 生产环境
CPU资源 2核 4核 8核+
内存分配 4GB 8GB 16GB+
数据库连接池 10-20 20-50 50-100
日志级别 DEBUG INFO WARN
持久化策略 临时存储 单节点存储 分布式存储

自定义配置示例：

# docker-compose-custom.yml
version: '3.8'

services:
  openmetadata-server:
    container_name: openmetadata_server
    restart: always
    image: docker.getcollate.io/openmetadata/server:1.10.0-SNAPSHOT
    environment:
      # 基础配置
      SERVER_PORT: 8585
      LOG_LEVEL: INFO
      OPENMETADATA_HEAP_OPTS: "-Xmx8G -Xms4G"
      
      # 数据库配置
      DB_DRIVER_CLASS: com.mysql.cj.jdbc.Driver
      DB_USER: production_user
      DB_USER_PASSWORD: ${PROD_DB_PASSWORD}
      DB_HOST: mysql-prod.example.com
      DB_PORT: 3306
      OM_DATABASE: openmetadata_prod
      
      # 搜索服务配置
      ELASTICSEARCH_HOST: es-cluster.example.com
      ELASTICSEARCH_PORT: 9200
    ports:
      - "8585:8585"
    volumes:
      - ./conf:/opt/openmetadata/conf
      - logs-volume:/opt/openmetadata/logs
    depends_on:
      mysql:
        condition: service_healthy
      elasticsearch:
        condition: service_healthy
    networks:
      - app_net

networks:
  app_net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/16

volumes:
  logs-volume:

验证方法：

  1. 检查自定义配置是否生效

    docker exec -it openmetadata_server env | grep DB_

  2. 查看应用日志确认启动状态

    docker logs -f openmetadata_server | grep "Started Application"

1.3 多环境部署策略

挑战：企业通常需要开发、测试、预生产和生产等多个环境，如何实现环境间配置隔离和快速复制？

方案：采用环境变量文件和配置模板，结合CI/CD流程实现多环境自动化部署。

环境配置隔离实践：

  1. 创建环境专用配置文件

    # 环境配置文件结构
env/
├── dev.env
├── test.env
├── staging.env
└── prod.env

  2. 使用环境变量文件启动容器

    # 启动测试环境
docker compose --env-file env/test.env -f docker/development/docker-compose.yml up -d

  3. CI/CD集成示例（GitLab CI配置）

    # .gitlab-ci.yml
deploy_staging:
  stage: deploy
  script:
    - docker compose --env-file env/staging.env -f docker/development/docker-compose.yml up -d
  only:
    - develop

deploy_production:
  stage: deploy
  script:
    - docker compose --env-file env/prod.env -f docker/production/docker-compose.yml up -d
  only:
    - main
  when: manual

适用场景：

  • 企业级多环境管理
  • 需要严格隔离的开发测试流程
  • 自动化部署流水线

验证方法：

  1. 检查环境变量是否正确加载

    docker exec -it openmetadata_server printenv | grep ENVIRONMENT

  2. 验证不同环境连接的后端服务

    # 检查数据库连接
docker exec -it openmetadata_server curl -I http://mysql:3306

配置策略

2.1 数据库配置与优化

挑战：OpenMetadata支持多种数据库后端，如何根据业务规模选择合适的数据库并进行性能优化？

方案：根据数据量和并发需求选择MySQL或PostgreSQL，优化连接池配置和数据库参数。

数据库选择对比：

特性 MySQL PostgreSQL 适用场景
JSON支持 基础JSON支持 高级JSONB类型 复杂元数据结构
全文搜索 有限支持 内置全文搜索 复杂查询场景
并发性能 优秀 优秀 高并发环境
扩展性 较好 优秀 大规模部署
社区支持 广泛 活跃 长期维护

数据库连接池配置：

# conf/openmetadata.yaml 片段
database:
  driverClass: com.mysql.cj.jdbc.Driver
  url: jdbc:mysql://mysql:3306/openmetadata_db?useSSL=true&serverTimezone=UTC
  user: openmetadata_user
  password: openmetadata_password
  maxSize: 50          # 最大连接数
  minSize: 10          # 最小连接数
  initialSize: 10      # 初始连接数
  checkConnectionWhileIdle: true
  evictionInterval: 5 minutes
  minIdleTime: 1 minute

数据库性能优化建议：

  • MySQL优化

    -- 增加连接数
SET GLOBAL max_connections = 500;

-- 优化InnoDB缓冲池
SET GLOBAL innodb_buffer_pool_size = 2G;

-- 启用查询缓存
SET GLOBAL query_cache_size = 128M;

  • PostgreSQL优化

    -- 调整共享缓冲区
ALTER SYSTEM SET shared_buffers = '2GB';

-- 设置工作内存
ALTER SYSTEM SET work_mem = '32MB';

-- 重启生效
SELECT pg_reload_conf();

验证方法：

  1. 监控数据库连接状态

    # MySQL连接状态
docker exec -it openmetadata_mysql mysql -u root -p -e "SHOW STATUS LIKE 'Threads_connected'"

# PostgreSQL连接状态
docker exec -it openmetadata_postgres psql -U postgres -c "SELECT count(*) FROM pg_stat_activity"

  2. 检查慢查询日志

    # MySQL慢查询日志
docker exec -it openmetadata_mysql tail -f /var/log/mysql/slow.log

2.2 认证与安全配置

挑战：企业环境中如何确保OpenMetadata的访问安全，实现细粒度的权限控制？

方案：配置多因素认证、SSL加密和基于角色的访问控制，保护敏感元数据。

认证配置示例：

# 基础认证配置
authentication:
  provider: basic
  publicKeyPath: "./conf/public_key.der"
  privateKeyPath: "./conf/private_key.der"
  jwtIssuer: "open-metadata.org"
  jwtExpiryDuration: 86400

OIDC认证集成：

authentication:
  provider: oidc
  oidcClientId: "openmetadata-client"
  oidcClientSecret: "${OIDC_CLIENT_SECRET}"
  oidcDiscoveryUri: "https://auth.example.com/.well-known/openid-configuration"
  oidcJwksUri: "https://auth.example.com/.well-known/jwks.json"
  oidcScope: "openid email profile"

安全最佳实践：

  1. 启用HTTPS

    server:
  enableSecureSocket: true
  sslPort: 8443
  keyStorePath: "./conf/keystore.jks"
  keyStorePassword: "${KEYSTORE_PASSWORD}"

  2. 配置内容安全策略

    web:
  conf:
    xss:
      cspEnabled: true
      cspPolicy: "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'"
    hstsEnabled: true
    hstsMaxAge: "365 days"

适用场景：

  • 企业内部多团队协作
  • 包含敏感数据的元数据管理
  • 合规性要求高的行业（金融、医疗等）

验证方法：

  1. 验证HTTPS配置

    curl -I https://localhost:8443/api/v1/health-check

  2. 测试权限控制

    # 使用不同角色令牌测试API访问
curl -H "Authorization: Bearer <user_token>" http://localhost:8585/api/v1/tables
curl -H "Authorization: Bearer <admin_token>" http://localhost:8585/api/v1/users

2.3 元数据采集配置

挑战：如何配置元数据采集任务，实现不同数据源的自动化元数据抽取和同步？

方案：使用OpenMetadata采集框架，配置数据源连接和采集工作流，实现元数据的增量同步。

数据源配置示例：

# 数据库元数据采集配置
source:
  type: mysql
  serviceName: "local_mysql"
  serviceConnection:
    config:
      type: Mysql
      username: "metadata_user"
      password: "metadata_password"
      hostPort: "mysql:3306"
      databaseName: "sample_db"
  sourceConfig:
    config:
      type: DatabaseMetadata
      includeTables: true
      includeViews: true
      includeStoredProcedures: false

sink:
  type: metadata-rest
  config:
    hostPort: "http://openmetadata-server:8585/api"
    authProvider: "openmetadata"
    securityConfig:
      jwtToken: "${JWT_TOKEN}"

workflowConfig:
  openMetadataServerConfig:
    hostPort: "http://openmetadata-server:8585/api"
    authProvider: "openmetadata"
    securityConfig:
      jwtToken: "${JWT_TOKEN}"

元数据过滤配置： 通过UI界面配置元数据过滤规则，精确控制需要采集的数据库对象：

元数据过滤配置界面

采集调度策略：

# 调度配置
scheduleInterval: "0 0 * * *"  # 每天午夜执行
retries: 3
retryDelay: 30s

适用场景：

  • 多数据源统一元数据管理
  • 定期元数据更新
  • 数据血缘分析

验证方法：

  1. 检查采集任务状态

    # 查看Airflow DAG状态
curl -X GET "http://airflow:8080/api/v1/dags/metadata_ingestion_dag" \
  -H "Authorization: Basic YWRtaW46YWRtaW4="

  2. 验证元数据是否成功采集

    curl -H "Authorization: Bearer ${JWT_TOKEN}" \
  "http://localhost:8585/api/v1/tables?service=local_mysql"

运维实践

3.1 监控体系搭建

挑战：如何实时掌握OpenMetadata服务运行状态，及时发现并解决性能问题？

方案：构建包含应用性能、数据库状态和基础设施的全方位监控体系，配置关键指标告警。

核心监控指标：

指标类别 关键指标 正常范围 告警阈值
应用性能 API响应时间 < 500ms > 2s
应用性能 错误率 < 1% > 5%
JVM状态 堆内存使用率 < 70% > 85%
数据库 连接池使用率 < 70% > 90%
数据库 查询执行时间 < 100ms > 500ms
搜索服务 索引延迟 < 1s > 5s

Prometheus监控配置：

# prometheus.yml
scrape_configs:
  - job_name: 'openmetadata'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['openmetadata-server:8586']
    relabel_configs:
      - source_labels: [__address__]
        target_label: instance

Grafana仪表盘配置： 创建包含以下面板的监控仪表盘：

  • 应用健康状态概览
  • API性能指标
  • 数据库连接池状态
  • JVM内存使用趋势
  • 搜索服务性能

告警规则示例：

groups:
- name: openmetadata_alerts
  rules:
  - alert: HighMemoryUsage
    expr: jvm_memory_used_bytes{area="heap"} / jvm_memory_max_bytes{area="heap"} > 0.85
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "高内存使用率告警"
      description: "OpenMetadata服务堆内存使用率超过85%，当前值: {{ $value | humanizePercentage }}"
  
  - alert: ApiErrorRate
    expr: sum(rate(http_server_requests_seconds_count{status=~"5.."}[5m])) / sum(rate(http_server_requests_seconds_count[5m])) > 0.05
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "API错误率过高"
      description: "API错误率超过5%，当前值: {{ $value | humanizePercentage }}"

验证方法：

  1. 检查监控指标是否正常采集

    curl http://localhost:9090/api/v1/query?query=jvm_memory_used_bytes

  2. 测试告警规则

    # 临时增加内存压力触发告警测试
docker exec -it openmetadata_server java -jar /opt/stress-test.jar

3.2 性能优化实践

挑战：随着元数据量增长，OpenMetadata性能逐渐下降，如何进行系统优化提升吞吐量？

方案：从JVM配置、数据库优化、缓存策略和索引设计四个维度进行性能调优。

JVM优化配置：

# 不同规模环境的JVM配置
# 开发环境
export OPENMETADATA_HEAP_OPTS="-Xms2g -Xmx4g -XX:MaxMetaspaceSize=512m"

# 生产环境（中等规模）
export OPENMETADATA_HEAP_OPTS="-Xms4g -Xmx8g -XX:MaxMetaspaceSize=1g -XX:+UseG1GC -XX:MaxGCPauseMillis=200"

# 生产环境（大规模）
export OPENMETADATA_HEAP_OPTS="-Xms8g -Xmx16g -XX:MaxMetaspaceSize=2g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:InitiatingHeapOccupancyPercent=45"

数据库优化策略：

  1. 索引优化

    -- MySQL关键表索引优化
CREATE INDEX idx_table_entity_id ON tables(entity_id);
CREATE INDEX idx_table_updated_at ON tables(updated_at);

-- PostgreSQL JSONB字段索引
CREATE INDEX idx_json_name ON tables USING GIN (json -> 'name');

  2. 查询优化

    -- 优化元数据查询
EXPLAIN ANALYZE SELECT * FROM tables WHERE json ->> 'name' = 'customer_data';

缓存配置：

# 缓存配置
cacheConfig:
  type: redis
  redisHost: "redis:6379"
  redisPort: 6379
  redisPassword: "${REDIS_PASSWORD}"
  ttl: 3600  # 缓存过期时间（秒）
  maxSize: 10000  # 最大缓存条目

适用场景：

  • 元数据量超过10万条
  • API响应延迟增加
  • 数据库负载过高

验证方法：

  1. 性能基准测试

    # 使用Apache Bench进行API性能测试
ab -n 1000 -c 10 http://localhost:8585/api/v1/tables

  2. 监控优化效果

    # 比较优化前后的响应时间
curl http://localhost:9090/api/v1/query?query=avg(http_server_requests_seconds_sum{endpoint="/api/v1/tables"}/http_server_requests_seconds_count{endpoint="/api/v1/tables"})

3.3 常见故障排查

挑战：OpenMetadata服务运行中出现各种异常，如何快速定位问题根源并恢复服务？

方案：建立系统化的故障排查流程，针对常见故障场景制定解决方案。

故障案例1：服务启动失败

  • 症状：openmetadata-server容器反复重启或无法启动
  • 排查流程：
    1. 查看容器日志
      docker logs -f openmetadata_server
    2. 检查数据库连接
      docker exec -it openmetadata_server telnet mysql 3306
    3. 验证数据库迁移状态
      docker exec -it openmetadata_server cat /opt/openmetadata/logs/application.log | grep "Migration completed"
  • 解决方案：
    • 检查数据库服务是否正常运行
    • 验证数据库连接参数是否正确
    • 清理损坏的数据库迁移状态
      docker exec -it openmetadata_mysql mysql -u root -p -e "DELETE FROM flyway_schema_history WHERE success=0"

故障案例2：元数据搜索无结果

  • 症状：搜索功能返回空结果或不准确
  • 排查流程：
    1. 检查Elasticsearch服务状态
      curl http://elasticsearch:9200/_cluster/health
    2. 验证索引状态
    curl http://elasticsearch:9200/_cat/indices
    1. 检查索引重建任务
    curl http://localhost:8585/api/v1/apps/status/SearchIndexingApplication
  • 解决方案：
    • 重启Elasticsearch服务
    • 手动触发索引重建
      curl -X POST http://localhost:8585/api/v1/apps/trigger/SearchIndexingApplication \
  -H "Authorization: Bearer ${JWT_TOKEN}"

故障案例3：元数据采集失败

  • 症状：Airflow采集DAG失败或元数据未更新
  • 排查流程：
    1. 查看Airflow DAG日志
      docker exec -it airflow-webserver airflow tasks logs metadata_ingestion_dag
    2. 验证数据源连接
      docker exec -it openmetadata_ingestion python -m metadata.ingestion.sources.mysql -c config.yaml
    3. 检查API权限
      curl -H "Authorization: Bearer ${JWT_TOKEN}" http://localhost:8585/api/v1/health-check
  • 解决方案：
    • 检查数据源凭据是否有效
    • 验证JWT令牌是否过期
    • 增加采集任务超时时间
      workflowConfig:
  timeout: 3600

验证方法：

  1. 确认服务恢复正常

    curl http://localhost:8585/api/v1/health-check

  2. 验证功能恢复

    # 测试搜索功能
curl -H "Authorization: Bearer ${JWT_TOKEN}" "http://localhost:8585/api/v1/search/query?q=customer"

容灾方案

4.1 数据备份策略

挑战：如何确保OpenMetadata元数据的安全性和可恢复性，防止数据丢失？

方案：实施多维度备份策略，包括数据库定期备份、配置文件版本控制和元数据导出。

备份策略矩阵：

数据类型 备份方式 频率 保留策略 恢复方式
数据库 全量+增量备份 全量:每日
增量:每小时		 全量:30天
增量:7天		 数据库恢复
配置文件 Git版本控制 变更时 永久 文件恢复
元数据 JSON导出 每周 90天 API导入
搜索索引 快照 每日 14天 索引恢复

数据库备份脚本：

#!/bin/bash
# 数据库全量备份脚本 backup_db.sh

# 环境变量
DB_CONTAINER="openmetadata_mysql"
BACKUP_DIR="/backup"
DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="openmetadata_db"
DB_USER="root"
DB_PASSWORD="password"

# 创建备份目录
mkdir -p ${BACKUP_DIR}

# 执行备份
docker exec ${DB_CONTAINER} mysqldump -u${DB_USER} -p${DB_PASSWORD} \
  --single-transaction \
  --routines \
  --triggers \
  ${DB_NAME} | gzip > ${BACKUP_DIR}/om_db_full_${DATE}.sql.gz

# 保留最近30天备份
find ${BACKUP_DIR} -name "om_db_full_*.sql.gz" -type f -mtime +30 -delete

元数据导出：

#!/bin/bash
# 元数据导出脚本 export_metadata.sh

JWT_TOKEN="your_jwt_token"
OUTPUT_DIR="/backup/metadata"
DATE=$(date +%Y%m%d)

mkdir -p ${OUTPUT_DIR}

# 导出关键元数据
curl -H "Authorization: Bearer ${JWT_TOKEN}" \
  "http://localhost:8585/api/v1/tables?limit=1000" > ${OUTPUT_DIR}/tables_${DATE}.json

curl -H "Authorization: Bearer ${JWT_TOKEN}" \
  "http://localhost:8585/api/v1/databases?limit=1000" > ${OUTPUT_DIR}/databases_${DATE}.json

curl -H "Authorization: Bearer ${JWT_TOKEN}" \
  "http://localhost:8585/api/v1/services?limit=1000" > ${OUTPUT_DIR}/services_${DATE}.json

适用场景：

  • 日常数据保护
  • 版本升级前备份
  • 数据迁移准备

验证方法：

  1. 检查备份文件

    ls -lh /backup/om_db_full_*.sql.gz

  2. 测试备份恢复

    # 测试恢复到临时数据库
gunzip -c /backup/om_db_full_20230510.sql.gz | docker exec -i test_mysql mysql -u root -p test_db

4.2 高可用架构设计

挑战：如何设计OpenMetadata高可用架构，确保服务不中断和数据一致性？

方案：部署多实例集群，实现服务冗余和自动故障转移，结合数据库主从复制保障数据可靠性。

高可用架构图：

flowchart TD
    A[负载均衡器] --> B[OpenMetadata Server 实例1]
    A --> C[OpenMetadata Server 实例2]
    A --> D[OpenMetadata Server 实例3]
    
    B --> E[数据库集群<br/>主从复制]
    C --> E
    D --> E
    
    B --> F[Elasticsearch集群<br/>3节点]
    C --> F
    D --> F
    
    B --> G[共享存储]
    C --> G
    D --> G

Kubernetes部署配置：

# openmetadata-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: openmetadata-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: openmetadata-server
  template:
    metadata:
      labels:
        app: openmetadata-server
    spec:
      containers:
      - name: openmetadata-server
        image: docker.getcollate.io/openmetadata/server:1.10.0-SNAPSHOT
        ports:
        - containerPort: 8585
        env:
        - name: DB_HOST
          value: "mysql-cluster"
        - name: ELASTICSEARCH_HOST
          value: "elasticsearch-cluster"
        resources:
          requests:
            memory: "4Gi"
            cpu: "2"
          limits:
            memory: "8Gi"
            cpu: "4"
        readinessProbe:
          httpGet:
            path: /api/v1/system/health
            port: 8585
          initialDelaySeconds: 30
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /api/v1/system/health
            port: 8585
          initialDelaySeconds: 60
          periodSeconds: 30

数据库高可用配置：

# MySQL主从复制配置
apiVersion: kubernetes.client.io/v1
kind: MySqlCluster
metadata:
  name: openmetadata-mysql
spec:
  replicas: 3
  version: "5.7"
  master:
    resources:
      limits:
        cpu: 1000m
        memory: 2Gi
  slaves:
    resources:
      limits:
        cpu: 500m
        memory: 1Gi
  volumeClaimTemplate:
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 50Gi

适用场景：

  • 生产环境关键业务
  • 对服务可用性要求高的场景
  • 数据量和访问量较大的部署

验证方法：

  1. 检查服务冗余

    kubectl get pods | grep openmetadata-server

  2. 测试故障转移

    # 手动删除主实例
kubectl delete pod openmetadata-server-7f9658b7c4-2xr5z

# 验证服务仍可访问
curl http://load-balancer:8585/api/v1/health-check

4.3 灾难恢复流程

挑战：当发生严重故障导致服务中断时，如何快速恢复OpenMetadata服务并确保数据一致性？

方案：建立完善的灾难恢复流程，明确恢复步骤、责任分工和验证方法，定期进行恢复演练。

灾难恢复流程：

  1. 故障评估

    • 确定故障范围和影响程度
    • 判断是部分恢复还是完全恢复
    • 记录故障现象和时间点

  2. 恢复决策

    • 根据故障类型选择恢复策略
    • 确定恢复时间目标(RTO)和恢复点目标(RPO)
    • 获得恢复操作授权

  3. 系统恢复

    flowchart TD
  A[停止所有服务] --> B[恢复数据库]
  B --> C[恢复Elasticsearch索引]
  C --> D[启动核心服务]
  D --> E[验证数据一致性]
  E --> F[启动所有服务]
  F --> G[验证服务功能]

  4. 数据验证

    • 检查关键元数据完整性
    • 验证数据血缘关系
    • 确认用户权限设置

恢复操作手册：

# 灾难恢复脚本示例 restore.sh

# 1. 停止现有服务
docker compose down

# 2. 恢复数据库
gunzip -c /backup/om_db_full_20230510.sql.gz | docker exec -i openmetadata_mysql mysql -u root -p openmetadata_db

# 3. 恢复Elasticsearch索引
curl -X POST "elasticsearch:9200/_snapshot/backup_repo/snapshot_20230510/_restore" -H "Content-Type: application/json" -d '
{
  "indices": "*",
  "ignore_unavailable": true,
  "include_global_state": true
}'

# 4. 启动服务
docker compose up -d

# 5. 验证服务状态
curl http://localhost:8585/api/v1/health-check

# 6. 验证元数据完整性
curl -H "Authorization: Bearer ${JWT_TOKEN}" "http://localhost:8585/api/v1/tables/count"

恢复演练计划：

  • 每季度进行一次恢复演练
  • 模拟不同故障场景（数据库损坏、索引丢失等）
  • 记录恢复时间，持续优化流程

适用场景：

  • 数据库严重损坏
  • 大规模数据丢失
  • 基础设施故障

验证方法：

  1. 全面功能测试

    # 运行自动化测试套件
./run_tests.sh --scope smoke

  2. 数据一致性检查

    # 比较恢复前后的元数据计数
curl -H "Authorization: Bearer ${JWT_TOKEN}" "http://localhost:8585/api/v1/tables/count"
curl -H "Authorization: Bearer ${JWT_TOKEN}" "http://localhost:8585/api/v1/dashboards/count"

运维检查清单

部署验证清单

  • [ ] 所有容器正常运行（docker ps检查状态）
  • [ ] API服务可访问（curl http://localhost:8585/api/v1/health-check返回200）
  • [ ] Web UI可正常访问（浏览器访问http://localhost:8585）
  • [ ] 数据库连接正常（查看应用日志确认）
  • [ ] 搜索服务健康（curl http://localhost:9200/_cluster/health状态为green）

配置验证清单

  • [ ] 数据库连接池配置符合环境需求
  • [ ] 认证配置生效（可成功登录）
  • [ ] 权限设置正确（不同角色访问控制）
  • [ ] 元数据采集任务配置正确
  • [ ] 环境变量配置正确（敏感信息未硬编码）

监控验证清单

  • [ ] Prometheus指标采集正常
  • [ ] Grafana仪表盘显示正确
  • [ ] 关键指标告警规则已配置
  • [ ] 日志收集完整
  • [ ] 性能基准测试通过

###灾备验证清单

  • [ ] 数据库备份任务正常执行
  • [ ] 备份文件可访问且完整
  • [ ] 恢复流程文档完整
  • [ ] 最近进行过恢复演练
  • [ ] 多可用区部署验证通过

通过遵循本指南，您可以构建一个稳定、安全且高性能的OpenMetadata部署，为企业元数据管理提供可靠支持。定期回顾和更新这些最佳实践，确保系统持续满足业务需求。

OpenMetadata
OpenMetadata is a unified metadata platform for data discovery, data observability, and data governance powered by a central metadata repository, in-depth column level lineage, and seamless team collaboration.
项目地址：https://gitcode.com/GitHub_Trending/op/OpenMetadata
登录后查看全文

相关内容推荐

1 OpenMetadata企业级部署与运维实战指南：从挑战到落地2 OpenMetadata企业级部署与运维实战指南3 OpenMetadata部署运维实战指南：从环境搭建到高可用架构4 OpenMetadata部署运维技术指南：从架构决策到混合云实践5 OpenMetadata部署运维实战指南：从单节点到企业级高可用架构6 OpenMetadata企业级部署与运维实践指南：从架构到灾备的全面解决方案7 OpenMetadata企业级部署与全链路监控指南8 OpenMetadata企业级部署运维指南：从规划到保障的全流程实践9 OpenMetadata企业级部署与运维实践指南10 企业级OpenMetadata部署与运维实战：从问题到解决方案的完整路径
热门项目推荐
相关项目推荐

最新内容推荐

BongoCat性能优化：从交互卡顿到丝滑体验的技术实践OpCore Simplify技术指南：零基础构建稳定黑苹果系统的完整方案JarkViewer：多格式图片浏览与专业处理的轻量解决方案提升数字书写效率的5款必备应用：从痛点到解决方案告别云端依赖：本地语音识别的革命性解决方案VirtualApp从入门到精通：Android沙盒技术实战指南开源工具赋能老旧设备：OpenCore Legacy Patcher系统升级全指南企业内网环境下的服务器管理平台搭建：宝塔面板v7.7.0离线部署全攻略革命性突破：Dexter如何通过自主智能代理重塑金融研究效率工具当Vite遇上微前端：90%开发者都会踩的3个技术坑与vite-plugin-qiankun解决方案

项目优选

收起
kernelkernel
deepin linux kernel
C
27
13
docsdocs
OpenHarmony documentation | OpenHarmony开发者文档
Dockerfile
629
4.15 K
pytorchpytorch
Ascend Extension for PyTorch
Python
469
566
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库，实现网络在NPU上加速计算。
C++
931
826
RuoYi-Vue3RuoYi-Vue3
🎉 (RuoYi)官方仓库 基于SpringBoot，Spring Security，JWT，Vue3 & Vite、Element Plus 的前后端分离权限管理系统
Vue
1.51 K
855
MindSpeed-LLMMindSpeed-LLM
昇腾LLM分布式训练框架
Python
138
162
MindSpeed-MMMindSpeed-MM
华为昇腾面向大规模分布式训练的多模态大模型套件，支撑多模态生成、多模态理解。
Python
131
191
flutter_flutterflutter_flutter
暂无简介
Dart
877
209
kernelkernel
openEuler内核是openEuler操作系统的核心，既是系统性能与稳定性的基石，也是连接处理器、设备与服务的桥梁。
C
382
266
AscendNPU-IRAscendNPU-IR
AscendNPU-IR是基于MLIR（Multi-Level Intermediate Representation）构建的，面向昇腾亲和算子编译时使用的中间表示，提供昇腾完备表达能力，通过编译优化提升昇腾AI处理器计算效率，支持通过生态框架使能昇腾AI处理器与深度调优
C++
114
186