원문 보기: https://dawoum.duckdns.org/wiki/PowerDNS Original article: w:PowerDNS PowerDNS 는 C++ 로 작성되고 GPL 에 따라 라이선스가 부여된 DNS 서버 프로그램입니다. 그것은 대부분의 유닉스 파생 제품에서 실행됩니다. PowerDNS는 단순한 BIND 스타일 영역-파일에서 관계형 데이터베이스 , 및 로드 밸런싱 / 장애 조치 알고리듬 에 이르기까지 다양한 백엔드를 제공합니다. DNS recursor 는 별도의 프로그램으로 제공됩니다. Installation 마리아디비 를 사용할 예정이기 때문에, 해당 기사로 가셔서 먼저 설치하고 설정하십시오. 그런-다음 패키지를 설치하기 위해 필요한 패키지를 먼저 설치합니다: sudo apt install software-properties-common gnupg2 -y 저장소를 /etc/apt/sources.list.d/pdns.list에 추가합니다: deb [arch=amd64] http: //repo.powerdns.com/debian bullseye-auth-45 main 우선 순위를 /etc/apt/preferences.d/pdns에 지정합니다: Package: pdns-* Pin: origin repo.powerdns.com Pin-Priority: 600 키를 얻고, 패키지를 설치합니다: wget -qO- https://repo.powerdns.com/FD380FBB-pub.asc | gpg --dearmor > pdns.gpg sudo mv pdns.gpg /etc/apt/trusted.gpg.d/ sudo apt update sudo apt install pdns-server sudo apt install pdns-backend-mysql Create PowerDNS Database 데이터베이스를 생성합니다: sudo mysql -u root -p MariaDB [( none )]> create d...
원문 보기: https://dawoum.duckdns.org/wiki/Sync_(Unix)
sync는 커널 파일시스템의 모든 데이터를 비휘발성 저장소 버퍼, 즉, 저수준 I/O 시스템 호출을 통해 쓰기로 예약된 데이터에 커밋하는 유닉스 운영 시스템의 표준 시스템 호출입니다. stdio와 같은 상위 레벨 I/O 계층은 자체 버퍼를 별도로 유지할 수 있습니다.
C에서 함수로서, sync() 호출은 전형적으로 <unistd.h>에서 void sync(void)로 선언됩니다. 시스템 호출은 sync라고도 하는 명령줄 유틸리티와 Perl 및 Node.js (fs 모듈에 있음)와 같은 다른 언어에서 유사한 이름-지어진 함수를 통해서도 사용할 수 있습니다.
관련된 시스템 호출 fsync()는 지정된 파일 설명자와 관련된 버퍼링된 데이터만 커밋합니다. fdatasync()는 파일에서 데이터에 대한 변경 사항만 기록하기 위해 사용할 수 있고, 반드시 파일의 관련 메타데이터는 아닙니다.
일부 유닉스 시스템은 정기적으로 sync 함수를 호출하는 일종의 flush 또는 update 데몬을 실행합니다. 일부 시스템에서, cron 데몬이 이것을 수행하고, 리눅스에서 그것은 pdflush 데몬에 의해 처리되며 이 데몬은 새로운 구현으로 대체되고 2012년에 리눅스 커널에서 최종적으로 제거되었습니다. 버퍼는 역시 예를 들어 시스템 종료 전에 파일 시스템이 마운트 해제되거나 읽기-전용으로 다시 마운트될 때 플러시됩니다.
Database use
적절한 내구성을 제공하기 위해, 데이터베이스는 기록된 정보가 정전 시 손실되는 메모리-기반 쓰기 캐시에 저장되는 것이 아니라 비-휘발성 저장소에 저장되었는지 확인하기 위해 어떤 형식의 동기화를 사용해야 합니다. PostgreSQL은 예를 들어 커밋을 지속하기 위해 fsync()와 fdatasync()를 비롯한 다양한 다른 sync 호출을 사용할 수 있습니다. 불행히도, 일련의 레코드를 쓰는 임의의 단일 클라이언트에 대해, 회전하는 하드 드라이브는 회전당 오직 한 번만 커밋할 수 있으며, 초당 최대 수백 개의 커밋이 가능합니다. 따라서 fsync 요구 사항을 끄면 커밋 성능을 크게 개선하지만, 충돌 후 잠재적으로 데이터베이스 손상이 발생할 수 있습니다.
데이터베이스는 역시 최근 변경 사항에 대한 정보가 있는 트랜잭션 로그 파일 (전형적으로 주요 데이터 파일보다 훨씬 작음)을 사용하며, 충돌의 경우에서 그러한 해당 변경 사항이 안정적으로 다시 실행될 수 있습니다; 그런-다음 주요 데이터 파일은 덜 자주 동기화될 수 있습니다.
Error reporting and checking
라이브러리 또는 커널에 의해 버퍼링되는 I/O 작업을 수행할 때, write() 시스템 호출 또는 fflush() 호출을 사용하는 시기에 오류가 보고되지 않을 수 있으므로, 데이터 손실을 방지하려면 fsync()의 반환 값이 확인되어야 하는데, 왜냐하면 데이터가 비휘발성 저장소에 기록되지 않고 메모리 페이지 캐시에만 기록될 수 있기 때문입니다. 쓰기로부터 오류는 fsync(), msync() 또는 close()에 대한 시스템 호출 동안 대신 종종 보고됩니다. 2018년 이전에는, 특정 상황 아래에서 리눅스의 fsync() 동작이 오류 상태를 보고하지 못했으며, 2018년 4월 23일에 동작 변경이 제안되었습니다.
Performance controversies
하드 디스크는 쓰기를 버퍼링하기 위해 자체 휘발성 쓰기 캐시를 사용하도록 기본 설정되어 있을 수 있으며, 이것은 쓰기 손실 가능성을 도입하면서 성능을 크게 향상시킵니다. hdparm -F와 같은 도구는 HDD 컨트롤러에 온드라이브 쓰기 캐시 버퍼를 플러시하도록 지시합니다. 캐싱을 끄면 성능에 미치는 영향이 너무 커서 통상적으로 보수적인 FreeBSD 커뮤니티조차도 FreeBSD 4.3에서 기본적으로 쓰기 캐싱을 비활성화하는 것을 거부했습니다.
SCSI 및 네이티브 명령 대기열을 갖는 SATA (일반 ATA는 아님, 심지어 TCQ 포함)에서, 호스트는 데이터가 디스크 플래터에 도달하거나 디스크 버퍼 (온보드 캐시)에 도달할 때 완료 알림을 받을지 여부를 지정할 수 있습니다. 올바른 하드웨어 구현을 가정하면, 이 기능은 fsync와 같은 시스템 호출에 대한 올바른 의미를 보장하면서 디스크의 온보드 캐시를 사용되는 것을 허용합니다. 이 하드웨어 기능은 Force Unit Access (FUA)라고 하고 그것은 ATA (또는 SATA 비-NCQ) 디스크에 대해 수행되는 것처럼 전체 캐시를 플러시하는 것보다 적은 오버헤드로 일관성을 허용합니다. 비록 리눅스는 2007년경에 NCQ를 활성화했지만, 초기 드라이브에 대한 지원 부족을 이유로, 2012년까지 SATA/NCQ FUA를 활성화하지 않았습니다.
2008년에 출시된 Firefox 3.0은 성능을 저하시키는 fsync 시스템 호출을 도입했습니다; 그 호출은 삽입된 SQLite 데이터베이스의 무결성을 보장하기 위해 도입되었습니다. 리눅스 재단 최고 기술 책임자 Theodore Ts'o는 "fsync를 두려워"할 필요가 없고, Firefox 3 속도 저하의 진정한 원인은 fsync의 과도한 사용이라고 주장합니다. 어쨌든 그는 역시 (Mike Shaver를 인용하여) "일부 일반적인 리눅스 구성에서, 특히 "data=ordered" 모드에서 ext3 파일 시스템을 사용하면, fsync를 호출하는 것이 호출된 파일의 데이터에 대해 바로 플러시되는 것이 아니라, 오히려 해당 파일 시스템에 대해 버퍼링된 모든 데이터에서 플러시된다"고 인정했습니다.
External links
댓글
댓글 쓰기