Closed hycsam closed 3 years ago
Related Issue #12356 .
@hycsam Thanks for opening this issue. This is potentially linked to #12356 .
identified issue in embedded journal. let's aim to fix this issue in the next release @calvinjia
@gpang @LuQQiu will https://github.com/Alluxio/alluxio/pull/12650 resolve this issue?
This issue is similar to #12356 and may be solved by #12658 I am now validating the #12658 and see if any further changes are needed
PR #12649 helps Alluxio log the correct Ratis error that helps to debug the related journal issues.
PR #12650 expose Ratis journal size related configuration to Alluxio configuration and enlarge those values to support journaling entries larger than 3MB. Note that this is mainly helping the Ratis journal write path. Ratis journal read path has a hard limit of 30MB per entry.
PR #12658 change from logging a table with all its partitions to logging a table entry and multiple partitions entries based on alluxio.table.journal.partitions.chunk.size (=500 by default, a single entry only contains up to 500 partitions). In the future, Journal restore or restart will not be crashed by large table entries anymore.
PR #12695 helps resolve or prevents unexpected large journal entries coming from other places of Alluxio by flushing journal entries bigger than MASTER_EMBEDDED_JOURNAL_ENTRY_SIZE_MAX / 3 and log error when journal entries bigger than the MASTER_EMBEDDED_JOURNAL_ENTRY_SIZE_MAX.
@hycsam The latest Alluxio master github branch contains the fixes. Could you help validate if the fixes are enough to solve the issue? Appreciate, if you help any questions regarding the fixes and validation, feel free to contact us on slack or directly in this ticket.
@LuQQiu Thanks for the fix, validated the issue has been resolved! Closing the ticket
Alluxio Env Version: 2.4.0 Master:
-Xms96g -Xmx96g
, Single master (no secondary, no standby), with embedded Journal server Worker: 10 worker nodes, each with-Xms4g -Xmx4g
AWS Instance type: i3.4xlarge, 16cores, 120GB memDescribe the bug I'm exploring Alluxio as a caching layer for our Presto cluster. All our files currently live in S3 and we are running Hive cluster upon those files. I'm using Alluxio Catalog Service solution to sync our Hive databases thru HMS to Alluxio master. It worked for small databases with 5 tables and a small number of partitions, but failed when I'm attaching a big DB with 20+ tables and nearly half of them have >20k partitions.
From the log I see Alluxio successfully attached small tables, then both RaftServer and AlluxioMasterProcess lost leadership, causing journal failed to flush. Alluxio then keeps retrying to flush the journal till timeout (or retry max reached), and then shutdown itself.
Here are the logs:
To Reproduce
./bin/alluxio table attachdb hive thrift://HMS_HOST:HMS_PORT DB_NAME --ignore-sync-errors -o catalog.db.ignore.udb.tables=TABLES_TO_IGNORE -o catalog.db.sync.threads=10
Expected behavior The command line prompt will stuck there for ~5min and whole Alluxio cluster shutdown
Urgency The DB I tried attaching is of medium size among all our Hive databases, and we need to migrate ~250 databases. This is blocking us from testing Presto queries with Alluxio catalog.