라즈베리파이 4 Mongo DB 설치과정..

 

라즈베리파이 4(Arm Cpu)에 mongo를 설치하려고 하니.. 
cpu<>os<> mongo version을 신경쓸게 상당히 많더라구요.

- Mongo에서는 ubuntu와 데미안만 지원함 
- Mongo Version 5.0미만을 깔아야함 ( 스토리지 엔진과의 호환 문제 ) 
- mongo 공식에서 안내하고있는 라즈베리파이에 local설치하는 것은 4.4버전을 안내하고있음 ( 근데 안되었습니다..... Link: https://www.mongodb.com/developer/products/mongodb/mongodb-on-raspberry-pi/ )

안내대로, 4.4 을 설치하면  cpu dump라는 error 가 발생하고 mongo가 정상적으로 작동하지 않게 됩니다.
구글링을 통해 4.4.18을 설치하면 되는 것을 확인했으나 왜 안되는 것 인지에 대한 확인의 과정입니다.

 

아래와 같이 에러가 발생하게 됩니다.

> mongo 
Illegal instruction (core dumped)
~~
WARNING: MongoDB requires ARMv8.2-A or higher, and your current system does not appear to implement any of the common features for that!
  applies to all versions ≥5.0, any of 4.4 ≥4.4.19
  see https://jira.mongodb.org/browse/SERVER-71772
  see https://jira.mongodb.org/browse/SERVER-55178
  see also https://en.wikichip.org/wiki/arm/armv8#ARMv8_Extensions_and_Processor_Features
  see also https://github.com/docker-library/mongo/issues/485#issuecomment-970864306

(*4.4.18을 설치하면 동작은 되나 보안적인 이슈가 존재함: https://www.mongodb.com/community/forums/t/core-dump-on-mongodb-4-4-19-on-rpi-4/215223 )

어떤 연관관계가 더 있나 궁금해서.. 찾아보니..

 

- 몽고의 버젼 티켓 https://jira.mongodb.org/browse/SERVER-71772에서  해당 이슈가 업로드 된 것을 확인했습니다. 

아마 CPU<>Kernel의 인터페이스 상에서 메모리와의 연관 관계가 있는 듯 합니다.

 " This request is to update v4.2 and v4.4 builds to explicitly target armv8.2-a as we do with 5.0+. WiredTiger expects certain behavior that is not provided on non-LSE ARM platforms.  =  WiredTiger는 LSE가 아닌 ARM 플랫폼에서는 제공되지 않는 특정 동작을 예상한다 

 

*  WiredTiger는 Mongo의 4.x 스토리지 엔진 입니다.

 

 

- 디테일한 내용의 티켓을 확인해보았더니. ( Link: https://jira.mongodb.org/browse/WT-9256 )

조사가 필요하다는 내용과 함께 어떤 부분에 영향이 미치는 지에 대해 적은 티켓입니다.

꽤나 core한 api영역에 영향을 끼치고 있는 것 같습니다.

__atomic 작업이 필요하다. LSE가 아닌 ARM64에 대한 조사가 필요하다. 
---
WiredTiger abstracts out the platform-dependent atomic code using some macros. The usage of the macros assumes a full barrier and hence is incorrect on the non-LSE ARM platforms. These macros are frequently used in the concurrent code that is sensitive to both the performance and correctness.

WiredTiger는 일부 매크로를 사용하여 플랫폼 종속 원자 코드를 추상화합니다. 매크로 사용은 전체 장벽을 가정하므로 LSE가 아닌 ARM 플랫폼에서는 올바르지 않습니다. 이러한 매크로는 성능과 정확성 모두에 민감한 동시 코드에서 자주 사용됩니다.

 

 

 

- 조사한 티켓을 확인했습니다. ( Link: https://jira.mongodb.org/browse/WT-8959 )

 

 

MotivationThe lock-free algorithms in use by WiredTiger rely on the instructions not getting re-ordered across the atomics. On GCC WiredTiger uses the __atomic builtins to implement its atomic operations. The __atomic builtins provided by the compiler could potentially not be utilizing a full memory barrier instruction on some platforms with a relaxed memory model like AArch64 (ARM64). This could leave WiredTiger exposed to a data corruption possibility on such platforms. WiredTiger should make sure the underlying primitives it uses include a full memory sync each time they are used.
For reference:A thread on GCC discussing why __atomic builtins might not be strong enough for the older __sync builtins.
Another thread discussing how AArch64 atomics might allow subtle re-orders.
Does this affect any team outside of WT?No
How likely is it that this use case or problem will occur?Arguably possible on x86-64. Very rare, but possible on AArch64 (ARM64).
If the problem does occur, what are the consequences and how severe are they?On the platforms like ARM64 that have a relaxed memory model for the SMP architecture, it could result in subtle data corruption bugs.
Is this issue urgent?Yes
Acceptance Criteria (Definition of Done)All the atomic operations have been guaranteed to provide a full memory barrier on the various platforms WiredTiger supports. The performance impact has been evaluated and found to be acceptable. WiredTiger stress testing and MongoDB patch testing has been successfully completed.
TestingWiredTiger stress tests, MongoDB patch tests, WiredTiger and MongoDB performance tests.
Documentation updateChange the documentation on building on the POSIX systems to ensure the build provides a full barrier that WiredTiger needs.
Updated ScopeThe scope for this ticket has been limited to an investigation into the atomic operations on the ARM platform. New tickets will be created for any follow on work.
[Optional] Suggested SolutionA possible way is to use __sync builtins instead of __atomic builtins as they are meant to provide a full barrier. The modern __sync builtins are implemented using the __atomic builtins, so we have to be careful about doing so. Newer versions of GCC should handle this correctly since a change went into GCC 5.0 to provide __atomic builtins with a full barrier to support the __sync builtins.
Another possibility could be to directly use the MEMMODEL_SYNC with __atomic builtins that was introduced to fix the __sync builtins.
We will have to investigate the facilities provided by the MSVC compiler.

 

 

- (?) WiredTiger가 사용하는 Lock 없는 알고리즘은 atomic 전체에 걸쳐 재정렬되지 않는 지침에 의존함.

- 컴파일러에서 제공하는 __atomic 내장 기능은 AArch64(ARM64)와 같은 완화된 메모리 모델을 사용하는 일부 플랫폼에서 잠재적으로 전체 메모리 장벽 명령을 활용하지 못할 수 있음. ( 메모리 장벽 해제를 못하니, 메모리를 사용하며 최적화하는 DB입장에서는 다소 힘든입장이 아닐까 합니다. ) 

- 이로 인해 WiredTiger가 해당 플랫폼에서 데이터 손상 가능성에 노출될 수 있다고 합니다.

- WiredTiger는 사용하는 기본 primitive가 사용될 때마다 전체 메모리 동기화를 포함하는지 확인한다고 해요.

 

- __atomic 내장 대신 __sync call 사용하는 것 으로 한다고 하고, atomic의 interface에 의존하고 있는 상태였는데, __sync call에는 필요한 내용이 다 없을 수도 있습니다.

 

 

---

- LSE나 atomic의 과정이 무엇인지 궁금해서 주변에 여쭈어보면서 아래 내용을 추가적으로 정리했습니다.

 

데이터의 atomic을 보장하기 위해. 과정을 좀 알아야 하더라구요.

- 내가 db에 write하다가 서비스가 종료된다면?의 관점에서 생각해보면 좋을 것 같습니다.

 

1. 하드디스크에 데이터 write할 때 1byte씩 쓰진 않음 -> 4byte 단위로 씀 
2. 만약 100byte까지 써야하는데, stream중 64byte에서 서버가 종료되었다면? 

 - db에서는 데이터를 어떻게 해야할지 판단하고, 정해야함 ( rdb기준  redo, undo 등등같이.. ) 
 - 이 때 atomic filesystem operations?? 이란 기법을 사용해서 보장함.
 - data에는 Flag는 여러 종류가 있습니다.

  ( 예시: [ 다 쓰인 데이터, 안쓰인 데이터, 최적화필요한데이터] 를 flag등으로 구분함..)

  ( 다쓰이긴 했지만 사용하지 않는 데이터 -> dirty flag )

- 데이터의 안정성을 위해, 데이터의 최적화등을 위해 필요한 interface가 미 지원 되었다고 추정이 됩니다.