Sunday, January 26, 2020

MariaDB Galera Cluster with Arbitrator


https://github.com/auntaru/vagrantfiles.git



[root@garb3 ~]# cat /etc/my.cnf.d/server.cnf
[mariadb]
wsrep_provider='/usr/lib64/galera/libgalera_smm.so'
wsrep_cluster_address=gcomm://192.168.33.11,192.168.33.12,192.168.33.13
wsrep_node_address=192.168.33.13
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_doublewrite=1
wsrep_on=ON
wsrep_cluster_name="auntaru_mariadb"
log-error = /var/lib/mysql/error.log
[root@garb3 ~]#


starting the cluster , adding one DB node and the arbitrator : 
 - galera_new_cluster
 - systemctl start mariadb.service
 - garbd -a gcomm://192.168.33.11,192.168.33.12,192.168.33.13 -g auntaru_mariadb

https://github.com/auntaru/vagrantfiles/blob/master/provision.sh


The Vagrant script downloads the official centos/7 box from :
https://cloud.centos.org/centos/7/vagrant/x86_64/images/


Friday, January 3, 2020

GiT clone Workspace add Index commit Repository push fetch Remote pull



How to understand Git: an intro to basic commands, tips, and tricks
https://www.freecodecamp.org/news/understanding-git-basics-commands-tips-tricks/






10 insanely useful git commands for common git tasks
https://www.datree.io/resources/git-commands


Git Cheatsheet
https://gist.github.com/hofmannsven/6814451


Git for beginners: 12 commands you need to know
https://blog.prototypr.io/git-for-beginners-12-commands-you-need-to-know-e084cce9cc94

Basic Workflow Commands:

1. git clone
You’ll need to do this just once for each repository you work with. You can use SSH or HTTPS. It makes an exact copy of the entire repository on your local machine.

2. git status
This is the most important Git command for beginners (arguably for all Git users). It can prevent you from getting into a lot of trouble. It will also help you gain a deeper understanding of how Git works, because it allows you to see what is happening behind the scenes.
What does git status do? It shows you everything you need to know about your current branch.


3. git diff
This will show you all the unstaged changes you have made. It’s different from git status which just shows you the names of the unstaged files you have changed.


4. git checkout -b
This is how you make a new branch and switch to that new branch, all in one command. Your branch names should be short but meaningful.
If you made a typo in your branch name, or otherwise just want to rename it, you can do git branch -m and that will rename your current branch.

5. git add and git add .
Warning: use git add . with caution! Never run git add . without looking at your git status first.
How does git add work? It adds your modified file to your staging index. If you have modified more than one file, git add . will add all the files your have edited to your staging index.
With some twisted kind of Git sorcery, I have in the past accidentally added a whole bunch of files, including a whole bunch of changes that I didn’t actually make, to my staging index. This was terrifying. It’s not a huge deal, because you can unstage them with git reset HEAD , but it is avoidable by running git status before adding anything to your staging index.
What the hell is a staging index? It’s where Git stores all your changes that are ready to be committed. If you’re into baseball, you can think of your staging index as being “on deck” and all your unstaged changes as being “in the hole” (if you’re not into baseball, forget I said that).

6. git commit -m ""
After running git add or git add ., you must run git commit -m "" (or you can unstage your changes if you don’t want to commit them, see above). Most likely, you’re going to want to commit your changes.


7. git push
This will push all your changes to the remote repository. You can think of this as uploading your changes.
After you git push, you will probably (depending on your workflow) have to submit a pull request, get approval, and merge your changes to a master branch. This can all be done in a web browser with a program like GitHub or Bitbucket.

8. git pull
If you think of git push as uploading your changes, you can think of git pull as downloading everyone else’s changes. Remember: you always pull down (download) before pushing up (upload).
After you have pushed your changes, it’s probably a good idea to hop on the master branch (you do this by running git checkout master) and doing a quick git pull, so you can develop on the most current version of master.
Tip: you can do both of these in one command by running git checkout master && git pull. This will execute both commands in that order.

Workflow Summary:
You now have everything you need to successfully clone a repository,
create a branch, make changes, and push those changes up to a master branch.






Hibernate in Eclipse with PostgreSQL Example
https://examples.javacodegeeks.com/enterprise-java/hibernate/hibernate-eclipse-postgresql-example/

Spring Boot Microservices , Docker and Kubernetes workshop – part3
https://www.javacodegeeks.com/2019/11/spring-boot-microservices-docker-and-kubernetes-workshop-part3.html

10 Things Java Programmers Should Learn in 2020
https://javarevisited.blogspot.com/2017/12/10-things-java-programmers-should-learn.html


How To Check Disk Space Usage In Linux Using Ncdu
https://www.ostechnix.com/check-disk-space-usage-linux-using-ncdu/