글

(엘라스틱 서치) FORBIDDEN/12/index read-only / allow delete 이슈

이미지
이유는 디스크 용량이 5%이하인 경우 자동으로 false처리하게 된다. 그러므로 두가지 방법이 있는데 첫 번째, elasticsearch.yml파일 안에 cluster.routing.allocation.disk.threshold_enabled: false 처리한다. 해당 인덱스 정보를 확인한 결과 GET activitylog-index/_settings read_only_allow_delete : true인 것을 볼 수 있다. 이를 해결하려면, PUT activitylog-index/_settings {   "index": {     "blocks" : {       "read_only_allow_delete": "false"     }   } }

(kafka) configued broker.id 1 doesn`t match store broker.id 0 이슈 문제 해결

한 호스트에서 여러 브로커를 생성하여 테스트 할 시 위와같은 에러가 발생할 수 있는데 이는 server-0.properties server-1.properties server-2.properties  각 파일에서 카프카가 저장시킬 로그 디렉토리를 분리해야한다. log.dirs = /tmp/kafka-logs-1 log.dirs = /tmp/kafka-logs-2 log.dirs = /tmp/kafka-logs-3

(zookeeper) systemd 등록 및 설명

리눅스 서버를 운영하거나 애플리케이션 서비스를 운영하는 경우에는 여러 종류의 프로세스들을 잘 관리하는 것도 매우 중요하다. 예를들어, 예기치 않게 서버의 오작동으로 인해 리부팅된 경우 어떤 프로세스는 반드시 자동으로 시작돼야 하는 경우도 있고, 반대로 어떤 프로세스는 반드시 관리자가 수동으로 시작해줘야 하는 경우가 있습니다. 이렇게 다양한 상황에 따라 효율적으로 프로세스들을 관리하기 위한 방법으로 여러 프로세스들을 systemd에 등록해 운영할 수 있다. ========================================================== 주키퍼에서는 zookeeper-server.service라는 파일명으로 만든다. <zookeeper-server.service> [Unit] Description=zookeeper-server After=network.target [Service] Type=forking User=root Group=root SyslogIdentifier=zookeeper-server WorkingDirectory=/usr/local/zookeeper Restart=always RestartSec=0s ExecStart=/usr/local/zookeeper/bin/zkServer.sh start ExecStop=/usr/local/zookeeper/bin/zkServer.sh stop ========================================================== 1. [Unit] 일반적인 옵션을 나타낸다. 가장 많이 사용하는 옵션은 실행 순서를조정하는 After, Before이다. - Description : 해당 유닛에 대한 상세한 설명을 나타내며 이 내용은 systemctl status 명령어에 표시된다. - After : 유닛이 시작되는 순서를 조정하며 After에 저장된 유닛이 실행된 이후 시작된다. - Before : 유닛이 시작되는 ...

(안드로이드) Handler post 메소드에 대한 설명

Handler 객체가 Post 메소드 안에 Runnable객체를 넣는 의미가 직접적으로 이해 되지 않아 문서를 본 결과. The  post  versions allow you to enqueue Runnable objects to be called by the message queue when they are received 상대방 측에서 메시지 큐로 부터 수신 했을 떄, 해당 Runnable 즉, 쓰레드 안에서 정의된 로직을 호출한다는 것이다.

(스칼라) build.sbt 설명

1. name : 프로젝트 이름 2. version : 프로젝트 버전 3. scalaVersion : 스칼라 버전 4. libraryDependencies : 의존하는 라이브러리 들을 설정한다. 또한 해당 라이브러리가 빌드 시점 중 어느 시점에 의존할지 설정한다. (예를들어 컴파일할 떄, 패키징 할 때) 5. assemblyOption in assembly : set-assembly  플러그인의 옵션 libraryDependencies에는 sbt가 관리하는 프로젝트가 의존하는 라이브러리를 설정하는데, Seq형식으로 설정한다. 여러개가 존재하는 경우 쉼표를 통해 구분하며, 하나의 의존라이브러리는 "<groupId> % <artifactId> % <version>" % "<configuration>" 형식으로 지정한다. <configuration>은 해당 라이브러리가 어느 의존 단계에 포함되어야 할지를 의미한다. provided 인 경우는 컴파일 단계에는 클래스패스에 포함되고, 패키지 단계에서는 포함되지 않는 것이다.

(하둡) core-site.xml 파일이란?

로그 파일, 네트워크 튜닝, I/O튜닝, 파일 시스템 튜닝, 압축 등 하부 시스템 설정 파일 core-site.xml 파일은 HDFS와 맵리듀스에서 공통적으로 사용할 환경정보를 설정한다. core-site.xml파일이 없을 경우 core-default.xml을 오버라이드 한다. 참고 :  http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-common/core-default.xml

(Git) reset과 revert의 차이 및 설명

이미지
1. reset은 그 이전으로 이력을 다시 돌리는 것이고 2. revert는 이전 이력은 그대로 두고, 그 되돌릴 커밋의 코드만 원복시키는 것 ========================================================== 1.  Reset  1. git reset <옵션> <돌아가고싶은 커밋> 옵션의 종류는 hard, mixed, soft 세가지 존재 예) 해당 커밋이후의 이력은 표를 예매하고, 팝콘과 사이다를 구매 1) hard 돌아가려는 이력이후의 모든 내용을 지워버린다. 이렇게 하면 표를 예매하고, 팝콘과 사이다를 구매했던 모든 것들이 지워지고 모든것이 초기화 $ git reset --hard a3bbb3c 2) soft 돌아가려 했던 이력으로 되돌아 갔지만, 이후의 내용이 지워지지 않고, 해당 내용의 인덱스(또는 스테이지)도 그대로 있는 상태. 즉, 바로 다시 커밋할 수 있는 상태로 남은 것이다. 기억은 되돌렸지만, 표와 팝콘과 사이다는 손에 들려 있는 상태 $ git reset --soft a3bbb3c 3) mixed(옵션을 적지 않으면 mixed 로 동작) 역시 이력은 되돌려진다. 이후에 변경된 내용에 대해서는 남아있지만, 인덱스는 초기화된다. 커밋을 하려면 다시 변경된 내용은 추가해야하는 상태 $ git reset --mixed a3bbb3c 또는 되돌아가는 커밋을 커밋 해쉬를 통해서 직접 지정할 수도 있고, 현재부터 몇개의 커밋을 되돌릴 수 있다. $ git reset HEAD~6 위는 현재부터 6개 이전 이력으로 돌아가라고 상대적으로 지정 2. Revert Revert는 상태를 되돌린다고 볼 수 있다. 스포를 당한 커밋을  revert하고 현재 작성중인 코드만 본다면 reset과 동일한 (hard옵션 준거만 뺴고) 결과를 가집니다. 하지만 이력은 같지 않습니다. 이전...