【问题标题】:Import huge data from MySQL to Elasticsearch将大量数据从 MySQL 导入 Elasticsearch
【发布时间】:2019-01-22 01:46:07
【问题描述】:

我正在尝试使用 Logstash 将 32m 行从 MySQL 导入 Elasticsearch,它工作正常,但在达到 3.5m 时会中断。检查了 MySQL,Logstash 运行正常,Elasticsearch 的问题请看日志:

[2018-08-14T23:06:44,299][WARN ][o.e.x.s.a.s.m.NativeRoleMappingStore] [4OtmyM2] Failed to clear cache for realms [[]]
[2018-08-14T23:06:44,345][INFO ][o.e.l.LicenseService     ] [4OtmyM2] license [23fbbbff-0ba9-44f5-be52-7f5a6498dbd1] mode [basic] - valid
[2018-08-14T23:06:44,368][INFO ][o.e.g.GatewayService     ] [4OtmyM2] recovered [1] indices into cluster_state
[2018-08-14T23:06:46,120][INFO ][o.e.c.r.a.AllocationService] [4OtmyM2] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[clustername][2]] ...]).
[2018-08-14T23:55:55,780][INFO ][o.e.m.j.JvmGcMonitorService] [4OtmyM2] [gc][2953] overhead, spent [378ms] collecting in the last [1s]

我已将堆大小增加到 2GB,但仍然无法处理。迁移配置文件如下:

input {
    jdbc {
        jdbc_connection_string => "jdbc:mysql://localhost:3306/clustername?useCursorFetch=true"
        jdbc_user => "USER"
        jdbc_password => "PSWD"
        jdbc_validate_connection => true
        jdbc_driver_library => "/usr/share/java/mysql-connector-java-5.1.42.jar"
        jdbc_driver_class => "com.mysql.jdbc.Driver"
        jdbc_paging_enabled => "true"
        #jdbc_fetch_size => "50000"
        jdbc_page_size => 100000
        statement => "SELECT * FROM `video` ORDER by `id` ASC LIMIT 100000 OFFSET 3552984"
    }
}

感谢您的任何建议。

【问题讨论】:

  • 你有没有试过在ES中禁用refresh_interval然后导入数据。
  • 是的,禁用了它,但它仍然无法正常工作。 ES Index 存储数据有限制吗?
  • 不,我实际上已经通过logstash从sql server一次导入了多达8000万条记录,ES运行的机器配置是什么。并且可以在索引时检查你的CPU利用率。
  • 我猜 CPU 很好,因为它可以快速导入 3.5m,当我尝试仅在输出中测试时,它很容易在 Logstash 中处理它。 4CPU XEON、12GB RAM、200GB SSD 磁盘可用。

标签: mysql elasticsearch logstash


【解决方案1】:

您没有提供足够的数据来帮助诊断问题。要正确索引大量数据,您必须真正了解数据是什么以及它将占用多少存储空间以及将使用多少内存。

Elasticsearch 并不神奇。如果您要超越简单的概念证明,则必须了解一些事情。当您看到诸如 gc 开销之类的事情需要花费大量时间时,您必须假设您没有正确调整 Elasticsearch 集群的大小。

您需要考虑的事项:

  • 我需要多少个分片?
    • elasticsearch配置文件中默认的#5可能有效,也可能太多 或太少。
    • 分片过多会导致 elasticsearch 内存不足。分片太少会导致性能不佳。
    • 为了帮助集群恢复,您的分片不应太大 - 2 GB 到 4GB 范围内的某个位置应被视为“大”
    • Elasticsearch 提供 API 来查看您正在使用多少分片以及它们有多大
  • elasticsearch 需要多少内存?

    • 对于数据节点,建议使用系统 RAM 的 50%
    • 50% 建议与允许操作系统将另外 50% 用于磁盘缓存有关
    • 如果您在节点上运行其他东西,您可能需要重新架构或在性能允许的情况下进行调整
    • 如果您的数据是基于时间序列的,您可能应该使用时间序列命名索引(频率为每年/每月/每周/每天,具体取决于每天生成的记录数
  • 你需要多少个节点

    • 如果没有第二个节点,就不能有副本。
    • 没有副本,您最终会丢失数据
    • 您需要有奇数个符合条件的主节点(否则您可能会陷入集群被分区的脑裂情况)
    • 节点越多越好——尤其是当您需要大量分片时
  • 您的数据有多大
    • 您可以通过将字段配置为仅关键字字段来减小大小(即如果您不需要搜索某些字段,或者只需要基于_all进行搜索)
    • 每条记录使用多少个字段 - 更多字段 = 每行更多内存

您需要考虑更多的事情,但作为一般规则,请尝试找出您的错误所在 - 即通过生成一些看起来像您真实数据,以便您可以收集适当调整集群大小所需的指标。

【讨论】:

    猜你喜欢
    • 2018-01-10
    • 1970-01-01
    • 2020-02-18
    • 1970-01-01
    • 2017-06-15
    • 2020-08-20
    • 2021-11-30
    • 2011-03-07
    • 1970-01-01
    相关资源
    最近更新 更多