ইনোডব_ফিল_ফর্ম্যাট বারাকুদা


25

আরও পরিচিতদের জন্য আমার কয়েকটি প্রশ্ন রয়েছে। আমার বেশিরভাগ উদাহরণ ব্যারাকুডার পক্ষে সমর্থন থাকা সত্ত্বেও অ্যান্টেলোপ চালাচ্ছে।

আমি কিছু সংক্ষেপে ইনডোডব টেবিলগুলি নিয়ে চারপাশে খেলতে দেখছিলাম। আমার বোধগম্যতা এটি কেবল ব্যারাকুডা বিন্যাসের অধীনে উপলব্ধ।

  1. আমি দেখছি ইনোডোবি_ফিল_ফর্ম্যাটটি গতিশীল তাই আমি কেবল একটি বাউন্স আউট নিয়ে স্যুইচ করতে পারি। এটি করার কোনও প্রভাব আছে কি তা সম্পর্কে আমার সচেতন হওয়া উচিত। আমি কেবল এটিই বলতে পারি যে নতুন ফর্ম্যাটগুলি বা পরবর্তীকালে পরিবর্তিত সেই বিন্যাসের সাহায্যে তৈরি করা হবে। সব কি ঠিক আছে?
  2. আমি আশা করছিলাম যে আমার সমস্ত টেবিলগুলির মধ্যে দিয়ে গিয়ে রূপান্তর করতে হবে না। কোশার কি হরিণ এবং ব্যারাকুড টেবিল একই টেবিল স্পেসে সহাবস্থান রাখতে পারে? এমনকি যদি এটি কাজ করে তবে কি কোনও খোঁজখবর আছে?

আমি আমার পরীক্ষাগুলি থেকে যা পড়েছি এবং সংগ্রহ করেছি সেগুলি থেকে উত্তরগুলি হ্যাঁ। হ্যাঁ। আমি নিশ্চিত নই.

হালনাগাদ

প্রকাশিত সমস্যা ছাড়াই এই পোস্টের পরে আমি বিভিন্ন পরিস্থিতিতে ডাব্লু / কিছু ডায়নামিক এবং কিছু সংক্ষেপিত টেবিল চালিয়ে যাচ্ছি। আরও আমি সেই সময়ে http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-phanfying.html পড়তে অবহেলা করেছি ।

আপনি প্রদত্ত ইনোডোবি_ফাইলে_ফর্ম্যাটটি সক্ষম করার পরে, এই পরিবর্তনটি বিদ্যমান বিদ্যমানগুলির চেয়ে কেবল নতুন নির্মিত টেবিলগুলিতেই প্রযোজ্য। আপনি যদি কোনও নতুন সারণী তৈরি করেন, সারণীর বৈশিষ্ট্যযুক্ত টেবিলস্পেসটি "প্রথম দিকের" বা "সর্বাধিক" ফাইল বিন্যাসের সাথে ট্যাগযুক্ত যা টেবিলের বৈশিষ্ট্যগুলির জন্য প্রয়োজনীয়। উদাহরণস্বরূপ, যদি আপনি ফাইল ফর্ম্যাট ব্যারাকুডা সক্ষম করে থাকেন এবং একটি নতুন টেবিল তৈরি করেন যা সংকুচিত হয় না এবং ROW_FORMAT = DYNAMIC ব্যবহার না করে, সারণীতে থাকা নতুন টেবিল স্পেসটি ফাইল বিন্যাসটি অ্যান্টেলিপ ব্যবহার করে ট্যাগ করা হয়।

সুতরাং আপনি বারাকুডাকে অনুমতি দিলেও সারণীগুলি হরিণ হিসাবে তৈরি করা হবে। মিশ্রণটি অনিবার্য নয় যতক্ষণ না আপনি প্রতিটি টেবিলটিকে সারি_ফর্ম্যাট গতিশীল বা সংকোচিত টেবিল হিসাবে উল্লেখ করেন।

আপনার প্রথম ব্যারাকুডা টেবিলটি প্রবর্তন করার সময় আপনার একটি সম্পূর্ণ ডাম্প এবং পুনরায় লোড করার কোনও ইঙ্গিত নেই (যেমন mysql এর বড় সংস্করণগুলি আপগ্রেড করার সময় প্রস্তাবিত )

উত্তর:


18

সুতরাং আমি প্রায় 4 বছর দেরীতে এই প্রশ্নের উত্তর দিচ্ছি:

  • ইনোডিবি ফাইল ফর্ম্যাটগুলি এমন এক সময়ে কল্পনা করা হয়েছিল যখন ইনোডিবি মাইএসকিউএল সার্ভার থেকে স্বতন্ত্র ছিল (উদাহরণস্বরূপ: মাইএসকিউএল 5.1 ইনোডিবি-র দুটি ভিন্ন সংস্করণ চালাতে পারে)।

  • আপনি কেন বারাকুডা চালাতে চান না (2012 সালে) এটি মাইএসকিউএলকে ডাউনগ্রেড করার ক্ষেত্রে নমনীয়তা হ্রাস করতে পারে (অর্থাত্ ব্যর্থ আপগ্রেড হওয়ার পরে আপনি এমন সংস্করণে ফিরে যেতে চান যা নতুন ফর্ম্যাটটি পড়তে পারে না)। উদাহরণস্বরূপ, অ্যান্টেলোপ আরও ভাল হওয়ার কোনও প্রযুক্তিগত কারণ থাকতে হবে না।

  • মাইএসকিউএল ৫.7 এ innodb_file_formatবিকল্পটি হ্রাস করা হয়েছে। যেহেতু মাইএসকিউএল এবং ইনোডিবি আর স্বতন্ত্র নয় এবং সুতরাং ইনোডিবি মাইএসকিউএল বিধিগুলি আপগ্রেডগুলি ব্যবহার করতে পারে এবং কী পিছনে সামঞ্জস্যতা প্রয়োজন। কোন বিভ্রান্তিকর সেটিং প্রয়োজন!

  • মাইএসকিউএল 5.7-এ, ডিফল্টটি স্যুইচ করে Barracuda/DYNAMIC। যেহেতু বর্তমানে মাইএসকিউএল-র সমস্ত সমর্থিত রিলিজ এই ফর্ম্যাটটি পড়তে পারে, তাই এটি অ্যান্টেলোপ থেকে সরে যাওয়া এবং এখনও ডাউনগ্রেড অফার করা নিরাপদ।

  • মাইএসকিউএল ৫.7 সার্ভারে, Barracuda/DYNAMICঅ্যান্টেলোপ টেবিলগুলি পরবর্তী টেবিলটি পুনর্নির্মাণের (অপ্টিমাইজ টেবিল ইত্যাদি) এ আপগ্রেড করা হবে । যে যতক্ষণ না তারা বিশেষভাবে সঙ্গে তৈরি করা হয়েছে ROW_FORMAT=oldrowformat

  • মাইএসকিউএল 8.0 এ, বিকল্পটি innodb_file_formatসরানো হয়েছে।


মাইএসকিউএল ৫.7 অপশনটিও ডায়নামিকের কাছে ডিফল্ট হিসাবে উপস্থাপন করেছেinnodb_default_row_format । এটি আপনার আপডেটের পয়েন্টটিকে সম্বোধন করে।


11
Just give a try!!!

mysql> select version();
+------------+
| version()  |
+------------+
| 5.5.21-log |
+------------+
1 row in set (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+----------+
| Variable_name            | Value    |
+--------------------------+----------+
| innodb_file_format       | Antelope |
| innodb_file_format_check | ON       |
| innodb_file_format_max   | Antelope |
| innodb_file_per_table    | ON       |
+--------------------------+----------+
4 rows in set (0.00 sec)

mysql> SET GLOBAL innodb_file_format = barracuda;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| innodb_file_format       | Barracuda |
| innodb_file_format_check | ON        |
| innodb_file_format_max   | Antelope  |
| innodb_file_per_table    | ON        |
+--------------------------+-----------+
4 rows in set (0.00 sec)

mysql> SET GLOBAL innodb_file_format_max = barracuda;
Query OK, 0 rows affected (0.00 sec)

mysql> show variables like "%innodb_file%";
+--------------------------+-----------+
| Variable_name            | Value     |
+--------------------------+-----------+
| innodb_file_format       | Barracuda |
| innodb_file_format_check | ON        |
| innodb_file_format_max   | Barracuda |
| innodb_file_per_table    | ON        |
+--------------------------+-----------+
4 rows in set (0.00 sec)

I had observed a single line logged in Error Log file :

[root@dhcppc0 Desktop]# tail -1 /usr/local/mysql/data/dhcppc0.err
120402 11:26:52 [Info] InnoDB: the file format in the system tablespace is
now set to Barracuda.

After switching to barracuda file format, I could also access my Database
and tables without any error :

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| opentaps1          |
| performance_schema |
| test               |
+--------------------+
5 rows in set (0.00 sec)

mysql> use opentaps1;
Database changed
mysql> select count(*) from product;
+----------+
| count(*) |
+----------+
|     3244 |
+----------+
1 row in set (0.42 sec)

mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)

mysql> show engine innodb status\G
*************************** 1. row ***************************
Type: InnoDB
Name:
Status: 
=====================================
120402 11:36:29 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 18446744073709534037 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 12 1_second, 12 sleeps, 1 10_second, 2 background,
2 flush
srv_master_thread log flush and writes: 12
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 5, signal count 5
Mutex spin waits 2, rounds 60, OS waits 2
RW-shared spins 3, rounds 90, OS waits 3
RW-excl spins 0, rounds 0, OS waits 0
Spin rounds per wait: 30.00 mutex, 30.00 RW-shared, 0.00 RW-excl
------------
TRANSACTIONS
------------
Trx id counter F01
Purge done for trx's n:o < 0 undo n:o < 0
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION F00, not started
MySQL thread id 1, OS thread handle 0x7f38309f9710, query id 28 localhost
root
show engine innodb status
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer
thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
554 OS file reads, 7 OS file writes, 7 OS fsyncs
-0.01 reads/s, 16384 avg bytes/read, -0.00 writes/s, -0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 276707, node heap has 15 buffer(s)
-0.15 hash searches/s, -0.12 non-hash searches/s
---
LOG
---
Log sequence number 221536390
Log flushed up to   221536390
Last checkpoint at  221536390
0 pending log writes, 0 pending chkp writes
10 log i/o's done, -0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137363456; in additional pool allocated 0
Dictionary memory allocated 3476070
Buffer pool size   8192
Free buffers       7635
Database pages     542
Old database pages 220
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
-0.00 youngs/s, -0.00 non-youngs/s
Pages read 542, created 0, written 1
-0.01 reads/s, -0.00 creates/s, -0.00 writes/s
Buffer pool hit rate 980 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead -0.00/s, evicted without access -0.00/s, Random read ahead
-0.00/s
LRU len: 542, unzip_LRU len: 0
I/O sum[0]:cur[238], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 2937, id 139879303665424, state: waiting for server
activity
Number of rows inserted 0, updated 0, deleted 0, read 3244
-0.00 inserts/s, -0.00 updates/s, -0.00 deletes/s, -0.18 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
1 row in set (0.00 sec)

9

আপনি যদি সত্যিই ব্যারাকুডা ফর্ম্যাটটি ব্যবহার করে InnoDB এর সাথে খেলতে চান তবে আপনার /root/MySQLData.sql এর মতো কিছুতে ম্যাক্সক্লাম্প করা উচিত। এটি ডেটা ফাইল ফর্ম্যাটকে স্বাধীন করে তোলে।

নতুন মাইএসকিউএল উদাহরণটি একটি তাজা আইবডাটা 1 এবং ইনোডাব_ফিল_পিটার_ট্যাবল (alচ্ছিক, আমার ব্যক্তিগত পছন্দ) সহ ব্যবহার করুন। খালি খালি ibdata1 দিয়ে ফাইল ফর্ম্যাট পরিবর্তন করুন। তারপরে, /root/MySQLData.sql পুনরায় লোড করুন এবং ডেটা দিয়ে খেলুন।

আমি পোস্টগ্র্রেএসকিউএলকে 9.0.1 বাইনারিগুলির সাথে কাজ করার জন্য একটি 8.2.4 ডাটাবেস পেতে টুইটার সেটিংসে টুইটারে সামান্য ভয়াবহ গল্প শুনেছি। আমরা যদি উভয় ফাইল ফর্ম্যাট একই সিস্টেম টেবিল স্পেসে (আইবডাটা 1) এবং / অথবা .ibdফাইলের মধ্যে থাকার চেষ্টা করি তবে আমরা যদি এই ধরনের সেটিংস সম্পর্কে অবগত থাকি তবে একই গল্পটি প্রয়োগ করতে পারে ।

যতদূর কোশার হচ্ছে ...

  • কারওই একই ফ্রিজে মাংস এবং দুগ্ধ সংরক্ষণ করা উচিত নয় store
  • কাউকে একই জোতের নীচে ষাঁড় এবং গাধা রাখা উচিত নয় (দ্বিতীয় বিবরণ 22:10)
  • কেউ একই আইবডটা 1 সংরক্ষণ Antelopeএবং Barracudaভিতরে রাখা উচিত নয়

আপডেট 2013-07-05 14:26 ইডিটি

আমি এই প্রশ্নের উত্তর কেবল সার্ভারফল্টে দিয়েছি: মাইএসকিউএল আইএনএনওডিবি সংক্ষেপণ KEY_BLOCK_SIZE নির্ধারণ করছি । এটি আমাকে ডিবিএ স্ট্যাকএক্সচেঞ্জে Barracudaফর্ম্যাটটি নিয়ে আলোচনা করে যে কোনও প্রশ্নের উত্তর চেয়েছিল এবং আমি আমার এই পুরানো পোস্টটি পেয়েছি। আমি এখানে একই তথ্য রাখব ...

মাইএসকিউএল ডকুমেন্টেশন অনুসারে ব্যারাকুডার জন্য ইনোডিবি সংক্ষেপণ

সংক্ষেপণ এবং InnoDB বাফার পুল

সংকুচিত InnoDB টেবিলটিতে, প্রতিটি সংকুচিত পৃষ্ঠা (1K, 2K, 4K বা 8K যাই হোক না কেন) 16 কে বাইটের একটি সঙ্কুচিত পৃষ্ঠাটির সাথে মিল রাখে। কোনও পৃষ্ঠায় ডেটা অ্যাক্সেস করতে, InnoDB ডিস্ক থেকে সংক্ষেপিত পৃষ্ঠাটি পড়েন যদি এটি ইতিমধ্যে বাফার পুলে না থাকে, তবে পৃষ্ঠাটিকে তার মূল 16 কে বাইট ফর্মটি সঙ্কুচিত করে। এই বিভাগটি বর্ণনা করে যে কীভাবে InnoDB সংকুচিত টেবিলের পৃষ্ঠাগুলির সাথে বাফার পুল পরিচালনা করে।

আই / ও হ্রাস করতে এবং কোনও পৃষ্ঠা সঙ্কুচিত করার প্রয়োজনীয়তা কমাতে, মাঝে মাঝে বাফার পুলে একটি ডাটাবেস পৃষ্ঠার সংকুচিত এবং সঙ্কুচিত উভয় ফর্ম থাকে। অন্যান্য প্রয়োজনীয় ডাটাবেস পৃষ্ঠাগুলির জন্য জায়গা তৈরি করতে, InnoDB বাফার পুল থেকে একটি সঙ্কোচিত পৃষ্ঠাটি মেমরির মধ্যে রেখে, একটি সঙ্কোচিত পৃষ্ঠা থেকে "উচ্ছেদ" করতে পারে। অথবা, যদি কোনও পৃষ্ঠায় কিছুক্ষণের মধ্যে অ্যাক্সেস না করা হয়, তবে অন্য ডেটার জন্য স্থান ফাঁকা করার জন্য, পৃষ্ঠার সংকুচিত ফর্মটি ডিস্কে লিখিত হতে পারে। সুতরাং, যে কোনও সময়, বাফার পুলটিতে পৃষ্ঠার সংকুচিত এবং সঙ্কুচিত উভয় ফর্ম থাকতে পারে, বা কেবল পৃষ্ঠার সংকুচিত ফর্ম, বা নাও থাকতে পারে।

ইনোডিবি কোন পৃষ্ঠাগুলিকে স্মৃতিতে রাখতে হবে এবং কোনটি সর্বশেষ-ব্যবহৃত (এলআরইউ) তালিকা ব্যবহার করে উচ্ছেদ করতে হবে তা ট্র্যাক করে রাখে, যাতে "হট" বা ঘন ঘন অ্যাক্সেস করা ডেটা স্মৃতিতে থাকে। সংকুচিত টেবিলগুলি অ্যাক্সেস করা হলে, InnoDB মেমরিতে সংকোচিত এবং সঙ্কুচিত পৃষ্ঠাগুলির উপযুক্ত ভারসাম্য অর্জন করতে একটি অভিযোজিত LRU অ্যালগরিদম ব্যবহার করে। এই অভিযোজিত অ্যালগরিদমটি আই / ও-বাউন্ড বা সিপিইউ-বাউন্ড পদ্ধতিতে চলছে কিনা তা সম্পর্কে সংবেদনশীল। লক্ষ্যটি হ'ল সিপিইউ ব্যস্ত থাকাকালীন খুব বেশি প্রসেসিং সময় ব্যয় করা পৃষ্ঠাগুলি ব্যয় করা এবং যখন সিপিইউতে অতিরিক্ত চক্র থাকে যা সংকুচিত পৃষ্ঠাগুলি সঙ্কুচিত করার জন্য ব্যবহার করা যায় (যা ইতিমধ্যে স্মৃতিতে থাকতে পারে) অতিরিক্ত পরিমাণে করা এড়ানো। যখন সিস্টেমটি I / O- সীমাবদ্ধ তখন অ্যালগরিদম উভয় অনুলির চেয়ে কোনও পৃষ্ঠার সঙ্কুচিত কপিটি উচ্ছেদ করতে পছন্দ করে, অন্যান্য ডিস্ক পৃষ্ঠাগুলির স্মৃতি বাসিন্দা হওয়ার জন্য আরও জায়গা তৈরি করা যখন সিস্টেমটি সিপিইউ-আবদ্ধ থাকে, তখন ইনোডিবি সংকোচিত এবং সঙ্কুচিত উভয় পৃষ্ঠাকেই উচ্ছেদ করতে পছন্দ করে, যাতে আরও বেশি মেমরি "হট" পৃষ্ঠাগুলির জন্য ব্যবহার করা যায় এবং কেবল সংকুচিত আকারে মেমরিতে ডেটা সঙ্কুচিত করার প্রয়োজনীয়তা হ্রাস করতে পারে।

খেয়াল করুন যে InnoDB বাফার পুল প্রশ্নগুলি পূরণ করতে ডেটা পৃষ্ঠা এবং সূচি পাতাগুলি লোড করতে হবে। প্রথমবারের জন্য কোনও টেবিল এবং এর সূচীগুলি পড়ার সময়, সংকোচিত পৃষ্ঠাটি 16 কে-তে সঙ্কুচিত করা আবশ্যক। তার মানে আপনার বাফার পুল, সংকুচিত এবং সঙ্কুচিত ডেটা পৃষ্ঠাতে দ্বিগুণ ডেটা সামগ্রী থাকবে।

যদি বাফার পুলে ডেটা বিষয়বস্তুর এই সদৃশতা চলতে থাকে তবে আপনাকে নতুন সংক্ষেপণের হারের একটি ছোট লিনিয়ার ফ্যাক্টর দ্বারা ইনোডাব_বফার_পুল_সাইজ বাড়াতে হবে । এটি এখানে:

দৃশ্যকল্প

  • আপনার একটি 8 জি বাফার পুল সহ একটি ডিবি সার্ভার রয়েছে
  • আপনি সংক্ষেপে দৌড়েছিলেন key_block_size=8
    • 8হয় 50.00%এর16
    • 50.00%এর 8Gহয়4G
    • ( + ) innodb_buffer_pool_sizeপর্যন্ত বাড়ান12G8G4G
  • আপনি সংক্ষেপে দৌড়েছিলেন key_block_size=4
    • 4হয় 25.00%এর16
    • 25.00%এর 8Gহয়2G
    • ( + ) innodb_buffer_pool_sizeপর্যন্ত বাড়ান10G8G2G
  • আপনি সংক্ষেপে দৌড়েছিলেন key_block_size=2
    • 2হয় 12.50%এর16
    • 12.50%এর 8Gহয়1G
    • ( + ) innodb_buffer_pool_sizeপর্যন্ত বাড়ান9G8G1G
  • আপনি সংক্ষেপে দৌড়েছিলেন key_block_size=1
    • 1হয় 06.25%এর16
    • 06.25%এর 8Gহয় 0.5G( 512M)
    • বাড়াতে innodb_buffer_pool_sizeকরার 8704M( 8G( 8192M) + + 512M)

গল্পটির মোরাল : সংকুচিত ডেটা এবং সূচী পৃষ্ঠাগুলি পরিচালনা করার সময় ইনোডিবি বাফার পুলের জন্য অতিরিক্ত শ্বাসকষ্ট দরকার।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.