SQL: AlwaysOn: Cloud witness: The client and server cannot communicate

2021-03-28

Podczas dodawania do quorum świadka „Cloud Witness” dostałem błąd:

An error was encountered while modifying the quorum settings.
Your cluster quorum settings have not been changed.
The client and server cannot communicate, because they do not possess a common algorithm.

Dodajmy, że Always On był konfigurowany na Windows 2016.

Przyczyną jest to, że Azure Storage Account pozwala na połąćzenie za pomocą TLS 1.0 1.1 i 1.2, tymczasem na moich serwerach miałem wyższą wersję. Nie wiem, jak obniżyć wykorzystywaną wersję w interfejsie graficznym, ale z powershella robi się to tak:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Set-ClusterQuorum -Cluster Cluster_Name -CloudWitness -AccountName Storage_Account_Name -AccessKey "Storage Access Key 1 or 2"

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Set-ClusterQuorum -Cluster Cluster_Name -CloudWitness -AccountName Storage_Account_Name -AccessKey "Storage Access Key 1 or 2"

Pierwsze polecenie obniża wersję TLS, a drugie dodaje cloud witness.

Przy okazji pojawił się też problem podczas samego konfigurowania availability group:

The local node is not part of quorum and is therefore unable to process this operation. This may be due to one of the following reasons:

• The local node is not able to communicate with the WSFC cluster.

• No quorum set across the WSFC cluster.

For more information on recovering from quorum loss, refer to SQL Server Books Online.

(Microsoft.SqlServer.Management.HadrTasks)

Zazwyczaj ten błąd oznacza rzeczywiście problem z clustrem, względnie przyczyną jest to, że we właściwościach usługi SQL w Configuration Managerze nie jest zaznaczona opcja Enable AlwaysOn Availability Groups:

Istotne jest jednak żeby ta opcja została zaznaczona PO utworzeniu clustra. Jeśli w między czasie cluster został odinstalowany i zainstalowany na nowo, to trzeba tę opcję wyłączyć (restart SQL) i włączyć (restart SQL)

https://docs.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/availability-group-clusterless-workgroup-configure

Komentarze (0)

Więcej

By Rafał Kraik in SQL

Python: args i kwargs

2021-02-08

Python jest fajny, bo jest dynamiczny. Napiszesz sobie funkcję, a potem ni z tego ni z owego można ją wywoływać na wiele sposobów. Popatrz na ten przykład:

def show_args(arg_1, arg_2):
   print(arg_1)
   print(arg_2)
 
show_args('one','two')

def show_args(arg_1, arg_2):

print(arg_1)

print(arg_2)

show_args('one','two')

Proste? No pewnie, że proste! Funkcja ma dwa argumenty i wywołujemy ją z dwoma argumentami i już!

Ale może by tak, mając listę dwóch elementów przekazać ją do tej funkcji? Może funkcja będzie na tyle sprytna, żeby zrozumieć o co chodzi? Niestety będzie błąd:

show_args(['one','two'])
TypeError: show_args() missing 1 required positional argument: 'arg_2'

1 2	show_args(['one','two']) TypeError: show_args() missing 1 required positional argument: 'arg_2'

… ale gdyby tak, przed listą dodać gwiazdkę, to Python „wyłuska z listy jej elementy i przekaże je do funkcji:

show_args(*['one','two'])
one
two

show_args(*['one','two'])

one

two

Wow! Dobre!

No a jeśli nie mamy listy argumentów, tylko słownik? I jeśli jeszcze w tym słowniku elementy są „przypadkowo” nazwane tak, jak argumenty testowanej funkcji? Przy pierwszym podejściu – niestety klapa:

show_args({'arg_2':'two', 'arg_1':'one'})
TypeError: show_args() missing 1 required positional argument: 'arg_2'

1 2	show_args({'arg_2':'two', 'arg_1':'one'}) TypeError: show_args() missing 1 required positional argument: 'arg_2'

Ale my już wiemy, jak sobie z tym poradzić:

show_args(*{'arg_2':'two', 'arg_1':'one'})
arg_2
arg_1

show_args(*{'arg_2':'two', 'arg_1':'one'})

arg_2

arg_1

Jedna gwiazdka jakoś już pomogła, niestety, pewnie wolelibyśmy nie zobaczyć w wyniku funkcji nazw kluczy, tylko ich wartości! Z pomocą przyjdą dwie gwiazdki, które konwertują słownik na nazwane wartości przekazywane do funkcji:

show_args(**{'arg_2':'two', 'arg_1':'one'})
one
two

show_args(**{'arg_2':'two', 'arg_1':'one'})

one

two

I to już działa idealnie. Funkcja domyśliła się, co to jest arg_1 mimo tego, że ta wartość w słowniku była dopiero na drugim miejscu.

Fajnie, ale te „chwyty” można też wykorzystać definiując funkcję:

def clever_function(*args):
   for a in args:
      print(a)

clever_function(1,2,3)

def clever_function(*args):

for a in args:

print(a)

clever_function(1,2,3)

Kiedy chcesz, aby funkcja mogła przyjąć dowolną liczbę parametrów przekazywanych po prostu przez pozycję, to wystarczy zadeklarować argumenty jako *args. W ciele funkcji można wtedy skorzystać ze zmiennej args, która jest listą. Bardzo to elastyczne!

Jeśli z kolei chcesz, aby funkcja miała przyjmować dowolną liczbę argumentów ze słownika, to argument poprzedź dwoma gwiazdkami. Zazwyczaj ten parametr nazywamy kwargs (key-word argument):

def clever_function(**kwargs):
   for k, v in kwargs.items():
      print(k,v)

clever_function(a=1,b=2,c=3)

def clever_function(**kwargs):

for k, v in kwargs.items():

print(k,v)

clever_function(a=1,b=2,c=3)

Teraz do funkcji można przekazywać dowolną liczbę nazwanych parametrów, a funkcja w sprytny sposób zobaczy je jako słownik. To użytkownik wywołując funkcję sam decyduje o tym, jak mają się nazywać argumenty widoczne w funkcji.

Obie te metody można zresztą połączyć i zbudować funkcję tak:

def clever_function(*args, **kwargs):
   for a in args:
      print(a)
 
   for k, v in kwargs.items():
      print(k,v)

clever_function('one','two',a=1,b=2,c=3)
print('---')
clever_function(a=1,b=2,c=3)
print('---')
clever_function('one','two')

def clever_function(*args, **kwargs):

for a in args:

print(a)

for k, v in kwargs.items():

print(k,v)

clever_function('one','two',a=1,b=2,c=3)

print('---')

clever_function(a=1,b=2,c=3)

print('---')

clever_function('one','two')

Jak widać funkcję można teraz wywoływać z argumentami określanymi przez pozycję i nazwę, albo tylko przez nazwę albo tylko przez pozycję.

Oj przyda się na pewno!

Komentarze (0)

Więcej

By Rafał Kraik in Python

PANDAS: odwołanie do wiersza, czy do wartości?

2021-01-27

W Pandas, seria danych to po prostu ciąg wartości. Wartość numer 2 to po prostu element prostego typu. Bardzo podobnie na pierwszy rzut oka wygląda jednokolumnowy DataFrame, ale… pewne różnice są:

numbers=[1, 2, 3, 4]
letters=['A', 'B', 'C', 'D']

1 2	numbers=[1, 2, 3, 4] letters=['A', 'B', 'C', 'D']

Tak powstaje seria danych – dla „zmyłki” indeksem jest kolumna numbers:

ds = pd.Series(data=letters, index=numbers)
ds

1 2	ds = pd.Series(data=letters, index=numbers) ds

oto wynik:

Out[45]: 
1 A
2 B
3 C
4 D
dtype: object

Out[45]:

1 A

2 B

3 C

4 D

dtype: object

A tak wygląda to, jeśli utworzymy DataFrame, który ma jedną kolumnę i indeks zdefiniowany w oparciu o numbers:

df = pd.DataFrame(data=letters, index=numbers)
df

1 2	df = pd.DataFrame(data=letters, index=numbers) df

wynik jest na pierwszy rzut oka podobny:

  0
1 A
2 B
3 C
4 D

1 A

2 B

3 C

4 D

Duże różnice pojawią się jednak przy odwołaniu do konkretnej pozycji:

ds.loc[1]
Out[47]: 'A'

1 2	ds.loc[1] Out[47]: 'A'

a dla DataFrame:

df.loc[1]
Out[48]: 
0 A
Name: 1, dtype: object

df.loc[1]

Out[48]:

0 A

Name: 1, dtype: object

Komentarze (0)

Więcej

By Rafał Kraik in Python

Postgres: Role i SUPERUSER

2021-01-24

Żeby uzyskać dostęp do PostgreSQL, to należy mieć dostęp do tzw. Login role (dawniej user). Jeśli taka rola jest oznaczona jako superuser, to ta rola uzyskuje nieograniczone uprawnienia do serwera bazy danych. Podczas instalacji serwera, taka rola jest tworzona automatycznie i nazywa się postgres. Role mogą też służyć do nadawania uprawnień nie nadając bezpośrednio dostępu do serwera. Role można w sobie zagnieżdżać. Rola, której członkiem są inne role nosi nazwę group role, a jeśli ta rola pozwala też na korzystanie z serwera to jest to group login name. W sumie logiczne 😊

Poniższa komenda tworzy rolę camila z dodatkowym uprawnieniem do tworzenia nowych baz danych

CREATE ROLE camila LOGIN PASSWORD ‚Passw0rd’ VALID UNTIL ‚infinity’ CREATEDB;

Słowo superuser dodane na końcu polecenia powoduje, że użytkownik staje się pełnoprawnym i „wszechmocnym” administratorem

CREATE ROLE adm_dagmara LOGIN PASSWORD ‚P@ssw0rd’ VALID UNTIL ‚2030-01-01 00:00’ SUPERUSER;

Jeśli rola nie ma służyć do logowania, to należy opuścić słowo LOGIN. Dodane tutaj INHERIT powoduje, że inne role dodane jako członkowie do toli adm_security będą dziedziczyć jej uprawnienia. Ta opcja jest w zasadzie domyślna, więc nie trzeba jej wpisywać jawnie.

CREATE ROLE adm_security INHERIT;

Grant pozwala dodać jedną rolę do innej roli jako członka. W ten sposób camila otrzyma wszystkie przywileje roli adm_security (bez ewentualnego przywileju superuser, bo ten jako jedyny nie podlega dziedziczeniu)

GRANT adm_security TO camila;

Do nadawania przywilejów dla ról należy posłużyć się poleceniem ALTER ROLE

ALTER ROLE adm_security SUPERUSER;

Kiedy użytkownik należy do roli, to może się przełączyć w tą rolę korzystając z SET ROLE

SET ROLE adm_security;

Po wykonaniu takich przełączeń można na bieżąco sprawdzać w jakiej tożsamości w danej chwili się pracuje. Stąd też można odwołać się do zmiennych session_user i current_user. Session_user określa nazwę roli jaka została wykorzystana do początkowego połączenia do serwera, zaś current_user to nazwa tożsamości w jakiej w danej chwili znajduje się użytkownik

SELECT session_user, current_user;

Dodatkowo superuser ma prawo wykonywać polecenie SET SESSION AUTHORIZATION, które zmieni nawet wpis dotyczący roli używanej na początku do zainicjowania połączenia

SET SESSION AUTHORIZATION ROLE adm_security;

Poprzez przełączanie się miedzy rolami może dojść do… przekrętów. Camila będąc członkiem roli adm_security może zmienić swoją rolę na adm_security. Niestety nie dziedziczy w ten sposób przywileju superuser. Jednak rola adm_security ma przywilej superuser, więc może teraz zmienić swoje konto camila nadając mu uprawnienie superuser. Od tej pory może już robić wszystko!

Komentarze (0)

Więcej

By Rafał Kraik in PostgreSQL

Postgres: Sprawdzanie aktywności na serwerze

2021-01-24

Każda poważna baza danych musi nie tylko w poprawny sposób zapisywać dane, ale także musi dawać administratorowi możliwość sprawddzania tej aktywności. W przypadku postgresa takim narzędziem jest widok

pg_stat_activity

Dzięki niemu zobaczysz kto skąd, a nawet po co , połączył sie do serwera. Narzędzie może być przydatne podczas śledzenia przyczyn zablokowanych sesji. W kolumnach tego widoku w szczególności można znaleźć opis zakładanych locków. Przy typowym zablokowaniu rekordu na wyłączność przez 2 użytkoników znajdziesz tu np. wpis:

LOCK, transaction_id

co oznacza, że transakcja została zablokowana przez inną transakcje. Pełny wykaz możliwych locków można znaleźć w dokumentacji:

https://www.postgresql.org/docs/9.6/monitoring-stats.html#WAIT-EVENT-TABLE

Komentarze (0)

Więcej

By Rafał Kraik in PostgreSQL

Azure: Uruchamianie skryptu powershell na maszynie witrualnej poprzez extension

2020-12-22

W artykule

Azure: zdalna zmiana rejestru w celu zmiany opcji połączeń zdalnych

opisałem, jak zmodyfikować rejestr maszyny wirtualnej znajdującej się w Azure, w celu odblokowania możliwości połączenia do tej maszyny z komputerów bez uwierzytelnienia klienta. Z czasem jednak, ta metoda delikatnie się zmieniła. Teraz nie można już załadować bezpośrednio pliku skryptu do uruchomienia, tylko trzeba ten plik wybrać ze storage account. Dochodzi więc jeden dodatkowy krok – stworzenie storage account i przegranie tam pliku skryptu.

tak wygląda początkowe okno pobierania skryptu „extension”

Po kliknięciu „browse” należy wybrać storage account. Zakładając, że go nie masz, trzeba kliknąć „+Storage account”

Tutaj tworzysz storage account – najważniejsze to wymyślić unikalną nazwę i wybrać inne parametry – celuj w te tańsze 🙂

Dzięki temu można już wybrać storage account, ale…

jest on pusty. Trzeba najpierw założyć container. W tym celu kliknij „+Container”

Ten kontener można wybrać, ale…

… jeszcze nie ma na nim plików (skryptów), dlatego można kliknąć „upload” i załadować skrypt extension.

Ten skrypt należy następnie wybrać i taddam – jesteśmy w sumie w tym samym miejscu, co w poprzednim artykule!

Niestety takie ciagłe zmiany w Azure, to coś do czego musimy przywyknąć.

Komentarze (0)

Więcej

By Rafał Kraik in Azure

SQL – bląd przy restore TDP – Cannot load file or assembly

2020-12-22

Podczas odtwarzania bazy danych przy pomocy narzędzia Tivoli Data Protection pojawil się komunikat:

Failed – Error: RC: 1914
ACO5422E Received the following from the MS SQL server: Could not load file or assembly ‚Microsoft.SqlServer.Smo, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91’ or one of its dependencies. The system cannot find the file specified

No dobrze, ale to jakiego pliku konkretnie brakuje? Pliku wrpawdzie w komunikacie nie ma ale za to jest nazwa pbrakującego pakietu. Dobre i to! Smo to Shared Management Objects. SMO wchodzi w sklad pakietu SQL Features Pack wydawanego osobno dla kazdej wersji SQL. Komunikat mowi o wersji 12, czyli zgodnie z numeracją Mocrosoft SQL 2014. Można go pobrać stąd:

https://www.microsoft.com/en-us/download/details.aspx?id=42295

Ale i tak coś mi tu jeszcze spokoju nie daje. SQL na którym pracuję to SQL 2016. Baza, którą odtwarzam to 2012. Dlaczego mam instalować SMO 2014? Nie chcę śmiecić na serwerze z SQL 2016 instalajami z 2014. Dlatego zacząlem od 2016. Nie pomoglo. Potem zainstalowlem 2012. Nie pomoglo. No to w koncu uzylem 2014 – bingo! Na cale szczescie restarty nie byly potrzebne

Maly pakiet – 6-7 MB, a dal pomyśleć!

Komentarze (0)

Więcej

By Rafał Kraik in Błedy, SQL